Dopo il lancio: manutenzione e gestione delle versioni
Il lancio non è il traguardo. Come gli aggiornamenti del sistema, le regole di versione degli store e un calendario tengono in vita un'app.
Team rabbitclipPubblicato: 5 min di lettura
In breve
Un'app mobile ha bisogno di essere aggiornata qualche volta all'anno dopo il lancio; sistemi operativi, regole degli store e librerie cambiano tutti, e un'app lasciata senza manutenzione finisce per non funzionare più bene o essere rimossa dallo store.
È qui che si differenzia da un sito web. Una pagina web aggiornata per una nuova versione del browser di solito continua ad aprirsi senza problemi; un'app mobile può sfasarsi quando il sistema operativo si aggiorna, e una versione lasciata senza manutenzione può uscire dallo store non appena entra in vigore una nuova regola minima.
Cosa significa davvero la manutenzione
La manutenzione significa tenere aggiornate le librerie dell'app, la compatibilità con il sistema operativo e la conformità alle policy dello store; è un lavoro distinto dall'aggiungere nuove funzionalità e segue un calendario regolare e prevedibile.
Un'app non è un prodotto che si scrive una volta e si lascia lì; come qualsiasi software vivo, deve cambiare mentre cambia l'ambiente attorno.
Vale la pena dichiarare la distinzione con chiarezza: la manutenzione tiene in piedi l'app così com'è; il lavoro di nuove funzionalità la fa crescere. Lo stesso team può fare entrambe le cose, ma servono voci di budget separate, altrimenti la manutenzione perde silenziosamente ogni volta contro il lavoro di crescita.
Perché gli aggiornamenti del sistema creano pressione
Apple e Google rilasciano ciascuno una versione principale del sistema operativo all'anno; con ogni rilascio, alcune API vengono deprecate e alcuni comportamenti dei permessi cambiano. Un codice che funzionava bene l'anno precedente può comportarsi in modo inatteso sulla nuova versione.
Per questo l'app va testata su ogni release principale del sistema operativo non appena esce; rimandare quel test tende a tradursi in lamentele degli utenti.
Una richiesta di permesso che prima stava in una sola schermata, per esempio, può dividersi in due passaggi in una nuova release; il codice continua a funzionare, ma l'utente non vede mai la schermata che si aspettava. Cambiamenti così emergono solo con test reali, mai in una revisione del codice.
Gli aggiornamenti obbligatori lato store
Google Play alza il livello minimo di API target ogni anno; le app rimaste sotto quel livello perdono la possibilità di essere installate ex novo o aggiornate. Questo significa che l'app può di fatto sparire dallo store anche se il codice in sé non è rotto.
Dal lato Apple, in modo simile, le app compilate con un SDK vecchio a un certo punto smettono di essere accettate per l'invio; per questo un ciclo annuale di ricompilazione e test fa parte del lavoro.
Come impostare un calendario di manutenzione
Ciò che funziona nella pratica è definire due o tre finestre di manutenzione fisse all'anno: aggiornamento delle librerie, test del nuovo sistema operativo, controlli sulle policy dello store. Fuori da quelle finestre, solo un bug davvero critico fa scattare un intervento urgente.
- Test di compatibilità quando esce una nuova versione del sistema operativo
- Una ricompilazione quando cambia il requisito di API/SDK target dello store
- Aggiornamenti di sicurezza per le librerie di terze parti in uso
- Revisione regolare dei feedback degli utenti e dei report di crash
Cosa succede senza manutenzione
Nel caso più lieve, l'app rallenta gradualmente o dà errori in alcune schermate. Nel caso peggiore, lo store la chiude ai nuovi utenti, oppure la rimuove del tutto, una volta che il livello di API target diventa troppo vecchio. Entrambi i casi richiedono tempo per essere corretti.
L'app per rivenditori di un laboratorio di mobili, lasciata intatta per due anni, ha perso la possibilità di essere installata da capo quando Google Play ha alzato il proprio livello di API target; i rivenditori che cambiavano telefono non riuscivano più a reinstallarla. La correzione in sé è costata una settimana, ma accorgersi del problema ne ha richiesti quasi sei, perché nessuno controllava con regolarità.
Chi dovrebbe occuparsi della manutenzione: interno o un'agenzia
In una piccola azienda, dire a una persona 'occupati anche dell'app' sembra semplice, ma la manutenzione finisce schiacciata tra il lavoro vero di quella persona e viene rimandata ogni volta. È il modo più comune in cui la manutenzione smette silenziosamente di succedere.
Il test decisivo è questo: il carico annuale di manutenzione dell'app (test, ricompilazione, controlli sullo store) è abbastanza piccolo da essere un compito regolare e ripetibile per una sola persona, oppure richiede un proprio budget e un proprio calendario. Se vale il secondo caso, affidare la manutenzione a un team esterno con un accordo stabile evita che il lavoro si perda nelle pieghe.
Errori frequenti
L'errore più frequente è trattare la manutenzione con la logica 'ce ne occuperemo se qualcosa si rompe'; i requisiti dello store arrivano silenziosamente, senza un problema evidente prima, e l'app può uscire dallo store prima che qualcuno se ne accorga. La manutenzione va programmata, non reattiva.
Il secondo è testare una nuova versione del sistema operativo solo al rilascio ufficiale; testarla dal momento in cui esce la beta dà il tempo di individuare e correggere problemi prima che arrivi la versione pubblica.
- Ricordarsi della manutenzione solo quando qualcosa si rompe
- Testare un nuovo sistema operativo solo sulla versione ufficiale
- Lasciare la manutenzione a una sola persona senza un calendario scritto
Il lancio non è una fine; è l'inizio di un ciclo di manutenzione regolare, e quel ciclo procede senza sorprese una volta che ha dietro un calendario definito. Se la vostra app non ha ancora un calendario di manutenzione, vale la pena impostarne uno insieme.
Domande frequenti
Cosa succede se un'app non viene mai aggiornata?
Può funzionare bene per un po', ma non appena cambia il sistema operativo o una regola dello store si sfasa, e può finire chiusa alle nuove installazioni.
Quanti aggiornamenti all'anno bastano per la manutenzione?
Di solito due o tre aggiornamenti pianificati; un bug serio riceve una correzione urgente fuori da quel calendario.
L'app va testata appena esce un nuovo sistema operativo?
Testarla contro la versione beta, prima del rilascio pubblico, permette di individuare i problemi presto invece che dopo che gli utenti li segnalano.
Un'app è a rischio senza un accordo di manutenzione?
Con il tempo sì; senza qualcuno che la segua, requisiti dello store o cambi del sistema operativo possono passare inosservati finché l'app non ne risente.
