«Il 90% delle app viene revisionato in meno di 24 ore.» Lo dice Apple, sul sito ufficiale per gli sviluppatori. Lo ripete anche lo staff sui forum, ogni volta che qualcuno chiede perché la sua app è ferma da una settimana.
Magari sono 24 ore lavorative. Ci sta. Qualcuno mi sa dire se la giornata lavorativa a Cupertino è di un paio d'ore? A questo punto è l'unica spiegazione.
L'esperienza reale di chi pubblica app
Scherzi a parte: molte revisioni arrivano davvero in tempi rapidi. Ma chi pubblica app per i clienti conosce bene l'altra faccia, quella che non finisce nelle statistiche: l'app resta «In attesa di revisione» per giorni, poi arriva il rifiuto.
E il motivo, spesso, non riguarda il funzionamento. Manca il link alla privacy policy in una sottosezione che nessuno aveva notato, o un testo non è coerente con quanto dichiarato altrove. Ah, era obbligatorio. E viene da chiedersi: se c'è un campo obbligatorio vuoto, perché non me lo dici prima dell'invio?
Post ironico, ma il disagio è reale. Soprattutto quando c'è un cliente che ha già annunciato la data di lancio.
Perché i tempi sono imprevedibili
La revisione Apple è fatta da persone, in base a linee guida lunghe e in continua evoluzione. I tempi dipendono da molti fattori: il carico del periodo (prima delle festività e dopo il rilascio di una nuova versione di iOS le code si allungano), il tipo di app, la presenza di acquisti in-app o di login, la storia dell'account.
E ogni rifiuto rimette l'app in coda. Un dettaglio sbagliato può costare non un giorno, ma una settimana.
I motivi di rifiuto più comuni
Dalla nostra esperienza, la maggior parte dei rifiuti non riguarda bug, ma completezza e conformità:
- Privacy policy e dichiarazioni sui dati: link mancante o non raggiungibile, oppure etichette sulla privacy non coerenti con quello che l'app fa davvero.
- Account demo assente: se l'app richiede un login, il revisore deve poter entrare. Senza credenziali di test, il rifiuto è quasi garantito.
- Cancellazione dell'account: se l'app permette di creare un account, deve permettere anche di eliminarlo dall'app.
- Metadati incompleti o incoerenti: screenshot che non corrispondono all'app, descrizioni con riferimenti ad altre piattaforme, testi segnaposto.
- Funzionalità minime: un'app che è solo un sito web impacchettato rischia di essere considerata priva di valore aggiunto.
- Acquisti e pagamenti: i contenuti digitali vanno gestiti secondo le regole degli acquisti in-app, e l'errore qui costa caro.
Come ridurre il rischio (e lo stress)
Non si può controllare la coda di Apple, ma si possono eliminare quasi tutti i motivi evitabili di rifiuto:
- Una checklist pre-invio con tutti i campi di App Store Connect, aggiornata a ogni nuova regola.
- Le note per il revisore compilate con cura: credenziali di test, spiegazione delle funzioni meno intuitive, eventuali hardware o condizioni particolari.
- Margine nel calendario: mai fissare una data di lancio pubblica a ridosso dell'invio. Meglio inviare per tempo e usare la pubblicazione manuale o programmata.
- TestFlight: anche il beta testing esterno passa da una revisione, ma permette di intercettare problemi prima di quella definitiva.
- La revisione accelerata: Apple permette di richiederla per correzioni urgenti. Va usata con parsimonia, ma esiste.
Pubblicare è parte del progetto
Per chi commissiona un'app, la pubblicazione sugli store sembra un passaggio burocratico finale. In realtà è una fase del progetto a tutti gli effetti, con le sue regole e i suoi tempi, e va pianificata come le altre.
Il rifiuto per il link in greco antico capiterà ancora. L'importante è che capiti in un momento in cui c'è il tempo di rimediare.
