Cosa deve consegnarti lo sviluppatore quando l'app è finita

Cosa deve consegnarti lo sviluppatore quando l'app è finita: il codice sorgente completo con la sua storia di modifiche, gli account App Store Connect e Google Play Console intestati alla tua azienda, i certificati di firma e il keystore Android, le credenziali dei servizi esterni collegati, la documentazione tecnica e il manuale d'uso. Senza questi elementi l'applicazione resta pubblicata sugli store, ma non puoi aggiornarla né affidarla a qualcun altro.

La consegna di un'app non è il momento in cui ti arriva il link dello store con scritto che è tutto online. Quello è il momento in cui il lavoro diventa visibile, che è una cosa diversa. La consegna vera è il passaggio in cui tutto ciò che serve a tenere in vita quell'app negli anni successivi cambia mano, e se quel passaggio non avviene ti ritrovi con un prodotto pubblicato che però non puoi toccare.

Il momento in cui si capisce com'è andata davvero

Nei progetti che seguo ho notato che la consegna è la fase in cui vengono al pettine tutte le scelte fatte all'inizio, comprese quelle che nessuno ti aveva spiegato. Finché l'app funziona e nessuno deve modificarla, la differenza tra un passaggio di consegne fatto bene e uno fatto male semplicemente non si vede. Si vede quando Apple alza la versione minima supportata, quando ti serve una funzione nuova per una campagna, oppure quando il rapporto con chi l'ha costruita si interrompe per qualsiasi motivo: dunque nel momento peggiore possibile.

Di fatto la domanda da porsi non è se l'app funziona, ma un'altra: se domani dovessi affidarla a un altro sviluppatore, quanto lavoro andrebbe rifatto da capo? Se la risposta è "tutto", la consegna non è mai avvenuta, indipendentemente da cosa dice la fattura.

Gli account degli store: l'errore che vedo più spesso

Questo è il punto su cui insisto di più con i clienti, ed è anche quello che quasi nessuno considera prima di firmare. Per pubblicare un'app servono due account sviluppatore, uno Apple e uno Google, e quegli account devono essere intestati alla tua azienda, non a chi ti sviluppa l'applicazione.

Il motivo è semplice: l'app appartiene a chi possiede l'account su cui è pubblicata. Se il tuo fornitore la pubblica sul proprio account, quell'app è formalmente sua. Non è una questione teorica, dal momento che nel momento in cui volessi cambiare sviluppatore ti troveresti davanti a un trasferimento che richiede la collaborazione di chi stai lasciando, e in certi casi a dover ripubblicare l'app da zero perdendo recensioni, posizionamento e la base di utenti che aveva già installato.

Sono le uniche cifre che ha senso citare in un articolo del genere, dal momento che sono pubbliche e uguali per tutti: l'account Apple Developer costa 99 dollari l'anno, quello Google Play 25 dollari una tantum. Restano a carico tuo e sono indipendenti dal costo di sviluppo. Se un preventivo ti sembra comprendere anche quelli, chiedi come mai: quasi sempre significa che gli account sarebbero del fornitore.

C'è poi un dettaglio che blocca più progetti di quanto immagini. Per aprire un account Apple come azienda serve il numero D-U-N-S, un identificativo che Dun & Bradstreet assegna alle imprese e che non è immediato: la richiesta è gratuita ma può richiedere diversi giorni lavorativi, a volte più di una settimana se i dati camerali non coincidono perfettamente. Va avviata all'inizio del progetto e non alla fine, altrimenti ti ritrovi con l'app pronta e nessun posto dove pubblicarla.

Il codice sorgente, e perché "ti mando i file" non basta

Il codice ti va consegnato, ma la forma in cui te lo consegnano cambia parecchio le cose. Un archivio zip con dentro i file dell'ultima versione è meglio di niente, seppur di poco. Quello che serve davvero è il repository Git con tutta la sua storia, ossia l'elenco di ogni modifica fatta, quando è stata fatta e perché.

La differenza è concreta. Con la storia delle modifiche, uno sviluppatore nuovo capisce in poche ore come è stato costruito il progetto e può tornare indietro se un aggiornamento rompe qualcosa. Senza, si trova davanti a un blocco di codice senza contesto e nella maggior parte dei casi ti proporrà di riscrivere, che è la risposta onesta ma anche la più cara.

La cosa più semplice da fare, e ti consiglio di chiederla fin dal primo giorno, è che il repository stia su un account intestato a te (GitHub, GitLab o quello che preferisci) e che lo sviluppatore ci lavori con un accesso da collaboratore. Così la consegna del codice non è un evento a fine progetto, è una condizione permanente: quest'ultimo dettaglio ti evita per intero la conversazione imbarazzante di cui parleremo più avanti.

Le chiavi di firma, l'oggetto che vale più del codice

Se dovessi indicare la cosa che si perde più spesso e che fa più danni, direi senza esitare le chiavi di firma. Ogni app pubblicata è firmata digitalmente, e lo store accetta un aggiornamento soltanto se è firmato con la stessa chiave della versione precedente.

Su Android la chiave sta in un file chiamato keystore, protetto da password. Su iOS si parla di certificati e profili di provisioning legati all'account sviluppatore. In entrambi i casi vale la stessa regola: se quel file e quella password non ce li hai tu, non puoi aggiornare la tua app. Non è una difficoltà tecnica superabile con un po' di lavoro in più, è una porta chiusa. Google offre un servizio di gestione delle chiavi che attenua il problema, ma va attivato consapevolmente al momento della prima pubblicazione, quindi è una scelta che va fatta all'inizio.

Ho visto aziende costrette a pubblicare una seconda app identica alla prima, con un nuovo indirizzo sullo store, soltanto perché il keystore era rimasto sul computer di un collaboratore che non lavorava più lì. Tutti gli utenti già installati sono rimasti sulla vecchia versione, che nessuno poteva più aggiornare.

Gli accessi ai servizi che l'app usa senza che tu lo sappia

Un'app moderna quasi mai vive da sola. Dietro c'è un server, spesso un database, e una serie di servizi esterni che fanno funzionare le cose che dai per scontate. Le notifiche push passano da un servizio, i pagamenti da un altro, le mappe da un altro ancora, e ognuno di questi ha un account con delle credenziali.

L'elenco che chiedo di mettere per iscritto nel documento di consegna, e che ti conviene usare come lista di controllo, comprende in genere:

• accesso al server o al servizio cloud dove gira il backend, comprese le credenziali di amministrazione
• credenziali del database e un export recente dei dati
• account dei servizi di notifica (tipicamente Firebase) e delle sue chiavi
• account del sistema di pagamento, se l'app incassa qualcosa
• chiavi delle API di terze parti utilizzate: mappe, analytics, servizi di invio email, monitoraggio degli errori
• pannello di gestione del dominio e dei record DNS, se l'app usa un tuo indirizzo
• account di eventuali strumenti di analisi del comportamento degli utenti

Il criterio è uno solo: se serve a far funzionare l'app o a capire come sta andando, l'accesso principale deve essere intestato a te, con lo sviluppatore in posizione di collaboratore. Non è sfiducia verso chi lavora con te, è la stessa logica per cui il commercialista gestisce la tua contabilità ma il conto corrente resta intestato all'azienda.

La documentazione, e non intendo quella bella

La documentazione tecnica utile non è un manuale di cento pagine che nessuno leggerà. Sono poche cose scritte in modo che una persona competente ci si ritrovi: come si installa l'ambiente di sviluppo, come si genera una nuova versione da pubblicare, quali variabili di configurazione esistono e a cosa servono, quali scelte architetturali sono state prese e per quale motivo.

A questa si affianca il manuale d'uso per te e per chi userà il pannello di amministrazione, e su quello ti consiglio di chiedere una registrazione video invece di un documento. Nella mia esperienza una sessione registrata di venti minuti resta consultabile e viene guardata davvero, mentre un PDF viene aperto una volta e poi dimenticato in una cartella.

Cosa chiedere prima di firmare, non dopo

Tutto quello che hai letto fin qui ha un difetto: se lo chiedi a lavoro finito, sei in una posizione debole. La consegna va messa nel preventivo, per iscritto, come voce a sé stante con dentro l'elenco delle cose che riceverai. È una richiesta legittima e chi lavora seriamente non ha nessun motivo per rifiutarla, dal momento che quelle cose le sta già producendo per conto suo.

Quando ricevi un preventivo per un'app, quindi, guarda anche questo oltre al numero finale. Se vuoi farti un'idea preliminare dell'ordine di grandezza puoi usare il calcolatore che stima il costo di sviluppo di un'app, che ti dà una forbice in base a quello che l'applicazione deve saper fare, e se stai ancora valutando se l'app ti serve davvero ne ho parlato nell'articolo su quando conviene sviluppare un'app per la tua attività.

Se l'app ce l'hai già e di tutto questo non hai niente

Capita spesso, e non è una situazione irrecuperabile. Il primo passo è fare l'inventario di quello che possiedi davvero: prova ad accedere agli store con le tue credenziali, verifica se hai il repository, controlla a chi è intestato il dominio. Quasi sempre scoprirai di avere qualche pezzo e non altri.

Il secondo passo è chiedere il resto, con una mail cortese e un elenco preciso. Nella maggior parte dei casi non c'è nessuna cattiva volontà dall'altra parte, soltanto un passaggio che non è stato fatto perché nessuno lo aveva chiesto. Se invece la richiesta viene respinta o ignorata, è un'informazione preziosa che hai ottenuto adesso invece che tra due anni, e vale la pena pianificare per tempo come uscirne. In quel caso la strada è ricostruire il minimo indispensabile mantenendo l'app attuale online finché la nuova non è pronta, che è un lavoro fattibile ma va impostato con la testa giusta, come ho raccontato parlando dei tempi reali di sviluppo di un'app.

Se stai per commissionare un'app e vuoi che questa parte sia chiara fin dall'inizio, nel mio servizio di sviluppo di app mobile la lista di consegna è scritta dentro il preventivo, e gli account degli store li intesto alla tua azienda fin dal primo giorno. Se invece hai già un'app e non sai da che parte cominciare per riprenderne il controllo, scrivimi e ne parliamo: mezz'ora di solito basta a capire cosa manca e quanto è grave.

Domande frequenti

Cosa devo chiedere allo sviluppatore alla consegna dell'app?

Chiedi il repository Git completo con la storia delle modifiche, gli accessi agli account App Store Connect e Google Play Console intestati alla tua azienda, il keystore Android con la relativa password, i certificati di firma Apple, le credenziali di tutti i servizi collegati (server, database, notifiche, pagamenti, mappe), la documentazione tecnica e il manuale d'uso. Il criterio per capire se manca qualcosa è semplice: se un altro sviluppatore non riesce a generare una nuova versione dell'app con quello che hai in mano, la consegna non è completa.

A chi devono essere intestati gli account App Store e Google Play?

Alla tua azienda, sempre. L'app appartiene formalmente a chi possiede l'account su cui è pubblicata, quindi se sono intestati al fornitore l'applicazione è sua e per riprendertela serve un trasferimento che richiede la sua collaborazione. Lo sviluppatore va aggiunto come utente con i permessi che gli servono per lavorare, non come proprietario. Le quote annuali degli store restano a carico tuo e sono indipendenti dal costo di sviluppo.

Cosa succede se perdo il keystore Android?

Non puoi più aggiornare l'app pubblicata, dal momento che Google accetta soltanto aggiornamenti firmati con la stessa chiave della prima versione. L'unica strada resta pubblicare una nuova applicazione con un indirizzo diverso sullo store, perdendo recensioni, posizionamento e gli utenti che avevano già installato quella vecchia. Esiste un servizio di gestione delle chiavi offerto da Google che riduce il rischio, ma va attivato al momento della prima pubblicazione: è una scelta da fare all'inizio, non dopo.

Il codice dell'app è mio o dello sviluppatore?

Dipende da cosa avete concordato per iscritto, ed è il motivo per cui va messo nel preventivo prima di iniziare. Nei progetti che seguo il codice viene consegnato al cliente insieme alla documentazione, ma non è una regola universale del settore: esistono contratti di licenza in cui paghi l'uso dell'applicazione senza possederne il codice, che sono legittimi ma vanno saputi in anticipo. Se il preventivo non ne parla, chiedilo prima di firmare.

Quanto tempo serve per ottenere il numero D-U-N-S?

La richiesta a Dun & Bradstreet è gratuita e in genere richiede da pochi giorni fino a un paio di settimane, con tempi più lunghi se i dati che inserisci non coincidono esattamente con quelli della visura camerale. Serve per aprire un account Apple Developer come azienda, quindi va avviata all'inizio del progetto: è una delle cause più banali e più frequenti di ritardo nella pubblicazione, e si evita semplicemente muovendosi per tempo.