Checklist App Mobile per Startup: 34 Voci dall'MVP all'Approvazione degli Store (2026)

Checklist App Mobile per Startup: 34 Voci dall'MVP all'Approvazione degli Store (2026)

La linea guida 5.1.1(v) dell'App Store Review ha ucciso più date di lancio di startup di qualsiasi bug abbiamo mai rilasciato. Un pulsante per l'eliminazione dell'account mancante, inviato la sera prima di un demo day, e l'intera timeline slitta di una settimana. Questa checklist app mobile per startup esiste perché quell'errore è del tutto evitabile, e quasi nessuno si annota il numero della linea guida che lo causa.

Punti chiave:

• Apple rifiuta le app se mancano i flussi di eliminazione account e i link alla privacy policy: le linee guida 5.1.1 e 1.5 lo dicono esplicitamente.
• Google Play richiede sia un percorso di eliminazione account in-app sia uno pubblico sul web, con enforcement attivo dopo la scadenza di proroga del 31 maggio 2024.
• Le checklist di pubblicazione per iOS e Android sono diverse; trattarle come un unico elenco combinato è la causa numero uno dei ritardi di lancio dell'ultimo minuto.

Prima di scrivere codice

Prima ancora di progettare una singola schermata, vanno fissate tre cose: cos'è davvero il tuo MVP, se ti serve una privacy policy (sì, ti serve) e se ai tuoi utenti si applica il GDPR o il KVKK turco. Saltare questa fase è il motivo per cui i founder si ritrovano a scrivere le pagine legali in fretta e furia proprio nella settimana in cui volevano pubblicare.

Un MVP, in una frase, è la versione più piccola del tuo prodotto che mette alla prova la tua ipotesi centrale con utenti reali. Non è una versione ridotta della tua visione completa. Se hai ancora dubbi sul perimetro, definire bene lo scope del progetto prima di scrivere una riga di codice ti evita di tagliare funzionalità a metà sviluppo invece che prima di iniziare.

Le linee guida Apple sono dirette sul requisito della privacy policy: la linea guida 5.1.1(i) stabilisce che le app "devono includere un link alla propria privacy policy" nei metadati di App Store Connect e, in molti casi, dentro l'app stessa. Non è un suggerimento. Se manca, è un blocco alla pubblicazione.

• Definisci lo scope del tuo MVP in una frase
• Conferma che ti serve una privacy policy (quasi sempre sì)
• Prepara un Support URL (la linea guida 1.5 di Apple lo richiede)
• Verifica l'applicabilità di GDPR/KVKK se hai utenti UE o turchi
• Decidi lo stack: nativo o cross-platform

La settimana di build dell'MVP

La settimana di build dell'MVP è il momento in cui decidi cosa viene davvero rilasciato e cosa viene tagliato, e la risposta onesta è: più di quanto i founder si aspettino. Analytics e crash reporting entrano durante la build, non dopo. Aggiungerli dopo il lancio significa perdere esattamente i dati che ti servivano per validare la tua prima ipotesi.

Quello che tagliamo davvero da uno scope v1, nella maggior parte dei casi, è tutto ciò che non è l'unica cosa che stai testando. Notifiche push, social login, una schermata impostazioni con sei interruttori: tutto può aspettare. I founder resistono, ed è comprensibile; sembra di rilasciare qualcosa di incompleto. È incompleto. È proprio questo il punto.

Come ha scritto un founder che ha rilasciato diverse app in un post-checklist su dev.to, saltare un meccanismo di feedback all'inizio è un errore che ha "rimpianto ogni volta". Integralo subito, non dopo che arriva la prima recensione. Se vuoi velocizzare la conversazione stessa sullo scoping, usare l'AI per accelerare lo scoping merita una lettura prima che inizi la build.

• Strumenta le analytics prima della tua prima build TestFlight/interna
• Collega il crash reporting (Sentry o Firebase Crashlytics)
• Integra un meccanismo di feedback dentro l'app
• Taglia ogni funzionalità non centrale per l'unica cosa che stai testando
• Scrivi la tua prima stringa di versione (vedi versioning sotto)

La settimana prima della pubblicazione

Questa è la fase che ogni checklist della concorrenza salta completamente, ed è qui che succedono i ritardi più evitabili. Il versionamento semantico per le app segue lo schema MAJOR.MINOR.BUILD (1.0.0, poi 1.0.1 per una patch, 1.1.0 per una nuova funzionalità). Scegli uno schema adesso, perché numeri di versione incoerenti confondono sia gli store sia il tuo team.

Un rilascio graduale (staged rollout) distribuisce l'aggiornamento prima a una piccola percentuale di utenti (spesso 1%, poi 10%, poi 50%) prima di raggiungere tutti. Solo una delle tre checklist concorrenti che abbiamo esaminato lo menziona, e pure di sfuggita. Se un crash sfugge, un rilascio graduale limita il raggio dell'impatto invece di colpire il 100% degli utenti in una volta.

Le domande che facciamo prima di dare il via libera alla pubblicazione di un cliente sono semplici: il percorso critico funziona da cima a fondo, adesso, su un dispositivo reale? Non sul simulatore. Il tasso di sessioni senza crash è accettabile? Gli asset della scheda dello store sono davvero definitivi, non segnaposto?

• Conferma che il numero di versione segua uno schema coerente
• Testa il percorso critico da cima a fondo un'ultima volta
• Prepara la percentuale di rilascio graduale se lo store la supporta
• Conferma che il tasso di sessioni senza crash sia accettabile prima di pubblicare
• Fai screenshot e prepara tutti gli asset della scheda dello store

Giorno di pubblicazione: iOS vs. Android

Le pubblicazioni su iOS e Android falliscono per motivi diversi, e trattarle come un'unica checklist combinata è in assoluto la causa più grande di ritardi di lancio dell'ultimo minuto che vediamo. Le linee guida dell'App Store Review di Apple e le policy per sviluppatori di Google Play indicano ciascuna requisiti specifici e verificabili, e la maggior parte dei founder li scopre solo dopo un'email di rifiuto.

Nelle nostre pubblicazioni, le due cose che fanno inciampare più spesso i founder alla prima esperienza sono il requisito dell'eliminazione account e un Support URL non raggiungibile. Entrambe si risolvono con una riga, se le intercetti prima di inviare. Entrambe causano un rifiuto automatico, se non lo fai.

Le linee guida di revisione dell'App Store di Apple sono precise: la linea guida 5.1.1(v) richiede che le app che supportano la creazione di account offrano anche l'eliminazione dell'account in-app, la linea guida 1.6 copre le dichiarazioni sulla Data Security e la linea guida 1.5 richiede un Support URL funzionante. Su Android, la policy per sviluppatori di Google Play richiede sia un percorso di eliminazione in-app sia un URL web pubblico per le richieste di eliminazione account. Google ha annunciato il requisito ad aprile 2023, ha fissato una scadenza al 7 dicembre 2023 per le domande sulla cancellazione dei dati nel modulo Data safety e ha concesso proroghe fino al 31 maggio 2024, dopo le quali le app non conformi vanno incontro a enforcement. Non è una vecchia regola andata in pensione per le piccole app; si applica ancora.

I due flussi di pubblicazione divergono anche meccanicamente, non solo sulla carta. Su iOS carichi una build tramite Xcode o Transporter, App Store Connect la elabora (ci vogliono da pochi minuti a oltre un'ora) e da lì la instradi verso TestFlight per tester interni ed esterni oppure la invii direttamente all'App Review. TestFlight non è burocrazia opzionale: è il modo in cui Apple si aspetta che tu intercetti i bug per cui un revisore altrimenti ti rifiuterebbe. Su Android, Google Play Console lavora per track invece che con un invio unico: si passa dai test interni, poi ai test chiusi o aperti, poi alla produzione, ognuna con il proprio pubblico e il proprio passaggio di promozione. Un rilascio graduale compare solo quando aggiorni una release di produzione esistente. Come dice la documentazione sui rilasci di Google stessa, "se stai distribuendo la tua prima release, non vedrai l'opzione per selezionare una percentuale di rollout", quindi non pianificare il tuo primissimo lancio attorno a una rampa percentuale: arriva dopo.

Sono le scartoffie, non il codice, a bloccare davvero la maggior parte delle prime pubblicazioni. Apple richiede un privacy manifest per un elenco definito di SDK di terze parti di uso comune (ad network, analytics, crash reporter) e la sua stessa documentazione è diretta su chi ne risponde: "quando usi un SDK di terze parti con la tua app, sei responsabile di tutto il codice che l'SDK include nella tua app e devi conoscere le sue pratiche di raccolta e uso dei dati", secondo la pagina Apple sui requisiti degli SDK di terze parti. Salta il manifest per un SDK presente in elenco e la tua build non supererà App Store Connect. L'equivalente di Google Play come sbarramento documentale è il modulo Data safety, ed è obbligatorio per ogni app su ogni track, tranne le build solo per test interni: "tutti gli sviluppatori che hanno un'app pubblicata su Google Play devono compilare il modulo Data safety, incluse le app nei track di test chiuso, aperto o di produzione", secondo la documentazione Data safety di Google Play. Sbaglialo, e Google dice apertamente che "potrebbe adottare azioni appropriate, incluse azioni di enforcement" quando emerge una discrepanza tra il comportamento dichiarato e quello reale dell'app.

C'è una terza modalità di fallimento che non ha nulla a che fare con il testo delle policy: il revisore non riesce materialmente a testare la tua app. La linea guida 2.1 di Apple lo mette nero su bianco: "includi le informazioni dell'account demo (e attiva il tuo servizio di backend!) se la tua app include un login". Niente credenziali demo funzionanti, niente backend attivo durante la finestra di revisione, niente Support URL raggiungibile, e verrai rimbalzato indipendentemente da quanto sia conforme il tuo flusso di eliminazione account. Se una parte qualsiasi della tua app sta dietro un paywall o un gate di login, scrivi delle note per il revisore che spieghino esattamente come raggiungerla. È un passaggio da due minuti che i founder alla prima esperienza saltano di continuo.

Un ultimo sbarramento, solo Android, merita lo stesso discorso: il livello API target. La documentazione per sviluppatori di Android afferma che "le nuove app e gli aggiornamenti delle app devono puntare" al livello API Android attualmente richiesto "per essere inviate a Google Play" e che "le app non aggiornate non sono disponibili per i nuovi utenti di dispositivi che eseguono versioni più recenti di Android". Non ha nulla a che fare con l'eliminazione account o la Data Safety, ma blocca una pubblicazione con la stessa nettezza, ed è il tipo di requisito che cambia ogni anno, quindi controlla il numero attuale prima di compilare la release.

Nessuna delle checklist più in alto in classifica per questa esatta ricerca cita un singolo numero di linea guida dell'App Store. Noi lo facciamo, perché tirare a indovinare sulla conformità è il modo in cui i lanci slittano di una settimana alla volta. Se stai costruendo la tua postura più ampia di gestione dei dati, la checklist di gestione dei dati prima del lancio copre il lato sicurezza che qui non duplichiamo.

Checklist di pubblicazione iOS:

• URL della privacy policy live e raggiungibile
• Percorso di eliminazione account in-app rilasciato (linea guida 5.1.1(v))
• Support URL live (linea guida 1.5)
• Dichiarazioni Data Security completate (linea guida 1.6)
• Build TestFlight approvata prima della pubblicazione pubblica

Checklist di pubblicazione Android:

• Modulo Data Safety compilato in Play Console
• Percorso di eliminazione account in-app rilasciato
• URL web pubblico per le richieste di eliminazione account live (requisito Google Play)
• Percentuale di rilascio graduale impostata
• Livello API target conforme al requisito Play attuale

Giorno di lancio

Il giorno di lancio è il giorno in cui la tua app diventa davvero live per utenti reali, separato dalla pubblicazione, che può avvenire giorni o settimane prima, e separato dalla settimana uno, che è il postumo. Il monitoraggio del rilascio graduale nel giorno uno è ciò che ti dice se continuare a espandere o mettere in pausa.

Controlla la dashboard di App Store Connect o Play Console ogni ora, non ogni giorno, per le prime 24 ore. Se il tasso di sessioni senza crash cala, vuoi saperlo entro l'ora, non la mattina dopo quando altri cento utenti hanno incontrato lo stesso bug. Tieni pronta una build di rollback. La stessa disciplina harden-stabilize-deploy che usiamo per le funzionalità AI si applica qui con la stessa identica pertinenza.

• Monitora il tasso di sessioni senza crash ogni ora per le prime 24 ore
• Tieni il canale di supporto presidiato e pronto
• Conferma che il rilascio graduale si stia espandendo come previsto
• Tieni pronta una build di rollback in caso di bug critico

La prima settimana online

La prima settimana online è dove succede la maggior parte del lavoro vero, anche se quasi nessuno la pianifica. La revisione giornaliera dei crash report e la risposta alle prime recensioni sullo store contano più di qualsiasi cosa tu abbia fatto nel giorno di lancio.

"Il lancio in sé conta meno di quanto pensi. Ciò che conta è quello che fai nelle settimane dopo", come ha scritto un founder nella propria checklist post-lancio. Questa è la versione onesta della settimana uno: patch veloci, risposte personali, e verificare davvero che il flusso di cancellazione dei dati funzioni prima che un utente reale lo testi al posto tuo. Se ora ti stai chiedendo quanto costi tutto questo da costruire e mantenere, preventivare manutenzione e aggiornamenti post-lancio è l'articolo gemello. Questo post copre la preparazione; quello copre il conto.

• Revisiona i crash report ogni giorno per la prima settimana
• Rispondi personalmente alle prime 10 recensioni sullo store
• Fai triage e applica patch a ogni bug critico entro 48 ore
• Conferma che il processo di richiesta cancellazione dati funzioni davvero da cima a fondo
• Imposta una cadenza per confrontare le analytics con l'ipotesi MVP originale

Come Techsy affronta tutto questo

Trattiamo la revisione pre-pubblicazione allo stesso modo per ogni build cliente: prima di dare il via libera, chiediamo se il percorso critico funziona su un dispositivo reale, se il tasso di sessioni senza crash regge e se ogni flusso imposto dalle linee guida (eliminazione account, privacy policy, Support URL) funziona davvero, non solo se esiste in un mockup. È un elenco corto, ma è l'elenco che determina se un'app supera la revisione al primo tentativo.

Se preferisci che a gestire la tua pubblicazione sia qualcuno che ha già affrontato queste linee guida, il nostro processo di sviluppo app mobile è costruito esattamente attorno a questo passaggio di revisione pre-pubblicazione. Non sostituisce il fare i compiti a casa: è quello che facciamo dopo che li hai fatti tu.

Domande frequenti

Cos'è un MVP e perché conta per una checklist di lancio?

Un MVP è la versione più piccola del tuo prodotto che mette alla prova un'unica ipotesi centrale con utenti reali. Qui conta perché ogni voce di questa checklist scala con il perimetro: un MVP più stretto significa meno cose che possono andare storte alla pubblicazione e meno funzionalità da strumentare, monitorare e rattoppare nella settimana uno.

Perché le app vengono rifiutate dall'App Store?

I motivi prevenibili più comuni sono la mancanza del link alla privacy policy (linea guida 5.1.1(i)), nessuna eliminazione account in-app (linea guida 5.1.1(v)) e un Support URL non raggiungibile (linea guida 1.5). Nessuno di questi richiede sforzo ingegneristico per essere risolto: sono voci di checklist, non bug.

Cosa succede se non aggiungo un'opzione di eliminazione account alla mia app?

Su iOS, la linea guida 5.1.1(v) ne fa un motivo di rifiuto automatico se la tua app supporta la creazione di account. Su Android, Google Play richiede sia un percorso di eliminazione in-app sia uno pubblico sul web, e le app non conformi vanno incontro a enforcement dopo la scadenza di proroga del 31 maggio 2024; ometterlo blocca la pubblicazione su entrambe le piattaforme.

Le startup hanno bisogno di una privacy policy per un'app mobile?

Sì, quasi sempre. Apple richiede una privacy policy collegata tramite link secondo la linea guida 5.1.1(i) e Google Play ne richiede una dentro il modulo Data Safety. Se raccogli qualsiasi dato utente, anche solo un'email per la registrazione, te ne serve una prima di pubblicare.

Che differenza c'è tra pubblicare sull'App Store e su Google Play?

La revisione di Apple è guidata dalle linee guida, con clausole nominate (5.1.1, 1.5, 1.6) e un revisore umano; Google Play si affida al modulo Data Safety e a controlli automatizzati. Il requisito dell'eliminazione account è simile nello spirito ma diverso nei meccanismi; vedi la tabella di confronto sopra.

Quanto dura davvero la revisione degli store?

Nessuno dei due store pubblica tempi garantiti, quindi tratta qualsiasi numero tu legga come un'aspettativa di massima, non come una promessa. Nelle nostre pubblicazioni per clienti, le approvazioni Apple sono generalmente arrivate entro uno o due giorni, con tutto ciò che tocca eliminazione account o dichiarazione dei dati che richiede più tempo. Google Play è stato di solito più rapido. Pianifica la data di lancio con margine, in ogni caso.

Cos'è un rilascio graduale e dovrei usarlo?

Un rilascio graduale distribuisce un aggiornamento prima a una piccola percentuale di utenti, poi si espande gradualmente, invece di raggiungere il 100% in una volta. Usalo ogni volta che lo store lo supporta: limita quanti utenti incontrano un bug prima che tu possa mettere in pausa e correggerlo.

Mi serve un Support URL per pubblicare la mia app?

Sì. La linea guida 1.5 di Apple richiede un Support URL funzionante come parte della pubblicazione e anche Google Play si aspetta un contatto di supporto. Un link morto o una casella non monitorata, qui, sono un motivo di rifiuto facile ed evitabile.

Cosa dovrei monitorare nella prima settimana online della mia app?

I crash report ogni giorno, le prime dieci recensioni sullo store e se il processo di richiesta cancellazione dati funziona davvero da cima a fondo. È anche il momento in cui inizi a confrontare i dati d'uso reali con l'ipotesi per cui il tuo MVP è stato costruito.

Il GDPR o il KVKK riguardano l'app di una piccola startup?

Se hai utenti nell'UE, il GDPR si applica indipendentemente dalle dimensioni della tua azienda. Se hai utenti in Turchia, il KVKK si applica allo stesso modo. Nessuna delle due leggi prevede un'esenzione per piccole startup, quindi verifica l'applicabilità durante lo scoping, non dopo che hai dati utente reali da proteggere.

Conclusione

Una checklist app mobile per startup si guadagna il suo posto solo se è abbastanza specifica da poterci agire oggi: definisci il tuo MVP in una frase, strumenta le analytics prima della build, revisiona lo schema di versionamento la settimana prima della pubblicazione e separa le checklist iOS e Android invece di trattarle come un unico elenco. Le sole voci su eliminazione account e privacy policy rappresentano la maggior parte dei rifiuti evitabili che vediamo.

Stampa la checklist, lavorala fase per fase e non saltare la prima settimana online: è la parte che ogni checklist della concorrenza omette, ed è la parte che determina davvero se il tuo lancio attecchisce. Se preferisci un secondo paio d'occhi sulla tua pubblicazione prima di inviarla, richiedi una consulenza gratuita →