Sviluppo app mobile a Foggia

È la prima domanda che ti faccio io, prima ancora di parlare di preventivo. Un'app conviene quando l'utente torna spesso, quando servono notifiche push, quando serve la fotocamera o la posizione, oppure quando deve funzionare senza connessione. Se il tuo cliente ti cercherebbe due volte l'anno, un sito veloce e ottimizzato per il mobile risolve lo stesso problema a una frazione del costo, e in quel caso te lo dico chiaramente.

Per la stragrande maggioranza dei progetti la differenza non è percepibile dall'utente, ed è il motivo per cui è la scelta che propongo quasi sempre: una base di codice sola significa metà del lavoro di manutenzione negli anni successivi. Lo sviluppo nativo resta la scelta giusta in casi specifici, per esempio quando servono funzioni di sistema molto particolari o prestazioni grafiche estreme. Se il tuo caso ricade lì, te lo dico in fase di analisi.

Della pubblicazione mi occupo io, comprese le schede, gli screenshot e la revisione dei requisiti che gli store applicano. Gli account sviluppatore, però, vanno intestati alla tua azienda: è un punto su cui insisto, dal momento che sono l'unica cosa che ti garantisce di poter aggiornare l'app anche se un domani lavorassi con qualcun altro. Le quote annuali degli store restano a carico tuo e sono indipendenti dal mio lavoro.

Un'app pubblicata non è un'app finita. Apple e Google cambiano periodicamente i requisiti e le versioni minime supportate, e un'app ferma smette di funzionare correttamente nel giro di un paio d'anni. Per questo dopo il rilascio propongo o un piano di manutenzione con aggiornamenti programmati, o interventi a richiesta con tariffe definite. In entrambi i casi il codice è tuo e la scelta resta tua.

Sì, e nella provincia di Foggia è una richiesta ricorrente, soprattutto per chi ha operatori che lavorano in aree agricole o in capannoni dove il segnale è scarso. L'app salva i dati in locale e li sincronizza appena la connessione torna, quindi chi è sul posto non deve aspettare né rischiare di perdere quello che ha inserito. È una scelta di architettura, quindi va decisa all'inizio e non aggiunta a sviluppo avviato.

Per un primo rilascio con le funzioni essenziali si ragiona in genere in un paio di mesi, a cui va aggiunto il tempo di revisione degli store, che non dipende da me. Il percorso è a sprint settimanali con aggiornamenti costanti, quindi vedi l'app crescere invece di aspettare mesi senza notizie. La cosa più utile che puoi fare per accorciare i tempi è avere chiaro cosa deve fare l'app nella prima versione, e soprattutto cosa non deve fare.