La vostra app funzionerà ancora fra tre anni?

Il giorno del lancio va tutto bene: avete visto la vostra app funzionare. È negli store, i primi utenti la scaricano, tutto risponde. La domanda che conta davvero non si pone quel giorno.

Si pone molto più tardi, la mattina in cui qualcuno vi scrive per segnalare che qualcosa ha smesso di funzionare. Nel frattempo sono passati tre anni durante i quali non avete toccato nulla.

La vostra app non è cambiata di una virgola. Il mondo intorno a lei sì. È qui il paradosso: un'app può smettere di funzionare senza che si muova una sola riga al suo interno.

Quattro movimenti, essenzialmente. Gli store irrigidiscono le loro regole: dichiarazioni sulla privacy, versioni minime, politiche sui permessi. I sistemi operativi abbandonano funzioni per strada e ne rendono altre obbligatorie. Alcune cose hanno una scadenza: i certificati e alcune credenziali di servizio scadono — il certificato SSL di un dominio, per esempio. E i dati si accumulano, finché ciò che era istantaneo diventa lento.

Pierre-Laurent ha fatto l'inventario dettagliato di ciò che si degrada in silenzio, politiche degli store e scadenze comprese. Non lo rifarò qui. Quello che mi interessa in questo articolo è la domanda successiva: una volta che si sa tutto questo, chi se ne occupa?

Dire che una piattaforma «si occupa della manutenzione» è vago al punto di essere vuoto. Il meccanismo reale sta in una frase: il problema viene corretto una volta, a livello di piattaforma, e ogni app eredita la correzione alla sua build successiva.

Quando entra in vigore un nuovo requisito sulla privacy, non sono migliaia di creatori di app che leggono la documentazione di Apple ciascuno per conto proprio. È una squadra, una volta sola, che aggiorna il motore che costruisce le app. Quando un sistema abbandona una funzione, il componente che la usava viene riscritto una volta, nello stesso posto. Voi non avete letto nulla, non avete migrato nulla, non avete deciso nulla.

Vale la pena enunciare l'alternativa, perché è tutto l'argomento a favore del costruire su una piattaforma invece di mantenere il proprio codice. Se siete voi a dover mantenere il codice sorgente dell'app — scritto da uno sviluppatore che avete assunto, o generato da un prompt in un pomeriggio —, quella stessa frase descrive il vostro pomeriggio. Tocca a voi accorgervi che la regola è cambiata, capire cosa richiede, modificare il codice, ricompilare, ripresentare. Nessuno l'ha fatto una volta per tutti: viene fatto una volta per voi, e poi di nuovo per il cambiamento successivo, e per quello dopo. Produrre un'app è diventato notevolmente economico, ed è davvero una buona notizia. Mantenerla aggiornata non si è spostato di un millimetro. Pierre-Laurent ha analizzato questo scarto in dettaglio.

Un punto di onestà, perché conta: questa vigilanza intercetta solo ciò che qualcuno ha visto arrivare. Leggere le regole prima che si applichino, riscrivere un componente prima che un abbandono diventi un guasto, è un mestiere esercitato di continuo, non una garanzia automatica.

Tutto quello che precede vale per un'app viva, che viene ripubblicata ogni tanto. Ma la vera preoccupazione sta altrove, e nessuno la formula: ho lasciato la mia app da parte per due anni. È perduta?

No. E la ragione sta nel modo in cui il lavoro si accumula: le correzioni aspettano la vostra app, non le corrono dietro. Un'app che nessuno tocca non si ripara da sola durante la notte: mentre dorme non le arriva nulla. Ma in quei due anni ogni cambio di regola e ogni funzione abbandonata da iOS o Android è stata trattata una volta, a monte, per tutte le app della piattaforma. Quel lavoro non è evaporato perché la vostra era silenziosa. È lì, impilato, e la aspetta.

La conseguenza è molto concreta: quando tornate, non recuperate due anni a mano. Ricompilate, e la vostra app esce con gli standard del mondo di oggi, non con quelli del mondo in cui è nata. Rimettersi in pari non è un cantiere: è una build. Non dovete sapere cosa c'era dentro.

È esattamente ciò che non succede quando siete voi a mantenere il codice sorgente. Nulla si è accumulato per voi mentre dormiva. Due anni di cambiamenti restano due anni di cambiamenti, in attesa che qualcuno — voi, o qualcuno che pagate — li affronti uno a uno prima che l'app possa ripartire.

Questa è la vera risposta alla domanda del titolo, e sta in due colonne.

Dalla nostra parte: il motore che costruisce le app, tenuto aggiornato in permanenza. La lettura delle regole degli store prima che si applichino. La riscrittura dei componenti prima che un abbandono diventi un guasto. La catena che invia le vostre notifiche. Il certificato SSL del vostro dominio, rinnovato prima di ogni scadenza. Niente di tutto questo vi chiede una decisione, e nemmeno di esserne al corrente.

Dalla vostra parte, e nessuno può farlo al posto vostro:

• I vostri account sviluppatore Apple e Google. Sono a vostro nome — è ciò che rende l'app vostra — e vanno rinnovati. Un account scaduto toglie l'app dagli store, per quanto buono sia ciò che contiene.
• Le dichiarazioni che descrivono i vostri contenuti e le vostre pratiche sui dati. Parlano della vostra attività, non della nostra: possiamo prepararle a partire dalle funzioni che avete effettivamente attivato, ma non decidere al posto vostro cosa fate dei dati dei vostri utenti.
• Il gesto di inviare l'aggiornamento. Ogni nuova versione passa dalla revisione degli store: la piattaforma prepara tutto, voi premete il pulsante. Se è quest'ultimo punto a pesarvi, GoodBarber Takes Care è l'opzione in cui inviamo noi gli aggiornamenti agli store al posto vostro.

La lista è corta. È voluto, e ognuna di queste righe merita un articolo a sé: è ciò che farà questa serie.

Il vero beneficio non è tecnico: è tempo. Le ore che non passate a leggere le note di rilascio di Apple, a decifrare cos'è una dichiarazione sulla privacy o a cercare perché un certificato è scaduto, le passate sui vostri contenuti, sul vostro pubblico, sulla vostra attività.

È un beneficio difficile da mettere in vetrina, perché non si vede: quando funziona, non succede nulla. Nessuna demo può dimostrarlo; solo il tempo lo verifica. È ciò che la piattaforma fa, discretamente, dal 2011.

Se vi interessa il dettaglio tecnico, ho descritto altrove, dal lato dell'ingegneria, cosa si rompe davvero in tre anni.

Il modo più semplice per vedere com'è fatta un'app costruita su questa meccanica è iniziare la vostra: creare la mia app con GoodBarber.

La mia app funzionerà ancora fra tre anni?

Un'app lasciata rigorosamente intatta finisce per restare indietro rispetto al proprio ambiente, e questo vale ovunque. La differenza sta in quanto costa rimettersi in pari: su una piattaforma che assorbe i cambiamenti, le correzioni sono già state fatte e aspettano la vostra app. Rimetterla a norma è una ricompilazione, non un cantiere.

Ho lasciato la mia app da parte per due anni. È perduta?

No. Mentre dorme a un'app non arriva nulla, ma tutto il lavoro fatto nel frattempo a livello di piattaforma la sta aspettando: alla ricompilazione successiva esce con gli standard attuali. È tutta la differenza rispetto a un'app di cui dovete mantenere voi il codice sorgente, dove nulla si è accumulato per voi.

Chi è responsabile di cosa tra la piattaforma e me?

La piattaforma si fa carico di ciò che è comune a tutte le app: il motore che le costruisce, la conformità alle regole degli store, la sostituzione dei componenti abbandonati e l'infrastruttura delle notifiche. Voi conservate i vostri account sviluppatore Apple e Google, le dichiarazioni che descrivono i vostri contenuti e la decisione di pubblicare gli aggiornamenti.

Servono competenze tecniche per mantenere un'app nel tempo?

No, ed è proprio questo il punto: la parte che le richiede viene fatta una volta, a monte, per tutte le app. Ciò che resta dalla vostra parte è amministrativo ed editoriale — rinnovare account, descrivere i vostri contenuti, scegliere quando pubblicare — non codice.

Perché la mia app è più lenta di quando l'ho lanciata?

Nella maggior parte dei casi non si è rotto nulla: è cambiato il volume. Ciò che era istantaneo su un catalogo piccolo richiede più lavoro quando cresce per anni. È l'unico dei quattro movimenti che nasce dal vostro successo e non dall'esterno, e sarà l'argomento di un prossimo articolo di questa serie.