Pubblicare su App Store e Google Play: la checklist completa 2026

Costruire l'app è la parte che tutti pianificano. Pubblicarla è quella che sorprende, perché è soprattutto lavoro amministrativo con regole rigide e cicli di risposta asincroni. Un rifiuto che avreste evitato in dieci minuti vi costa una settimana di calendario. Questa guida percorre i due store nell'ordine in cui vi servono davvero: account, materiali, dichiarazioni, invio, revisione e cosa fare il giorno dopo il lancio.

Prima di tutto: i due account

Entrambi gli store richiedono un account sviluppatore a pagamento, ed entrambi impiegano tempo ad attivarsi. Iniziate questo passo prima che l'app sia finita, non dopo.

Una decisione da prendere presto: registratevi a nome della vostra società, non a titolo personale. Spostare un'app da un account all'altro in seguito è possibile ma laborioso, e un nome di persona fisica visibile sulla scheda risulta poco professionale per una clientela business.

I materiali che vi verranno chiesti

I due store chiedono più o meno le stesse cose, con misure diverse e diversa tolleranza all'approssimazione. Preparate tutto in una sola sessione invece di scoprire ogni requisito a metà dell'invio.

• L'icona. Un quadrato ad alta risoluzione, senza trasparenza e senza angoli arrotondati aggiunti da voi: la maschera la applicano gli store. Evitate il testo piccolo, illeggibile a dimensione reale.
• Gli screenshot. Più formati di dispositivo, incluso almeno un telefono grande. Sono la leva principale del tasso di installazione: annotateli con un beneficio breve invece di caricare catture grezze.
• Titolo e sottotitolo. Brevi, e indicizzati dalla ricerca dello store. Nel titolo mettete la parola chiave che le persone digitano davvero, non una formula di marca spiritosa.
• La descrizione. Solo le prime due righe vengono lette davvero. Iniziate da cosa fa l'app per l'utente, non dalla storia della vostra azienda.
• Immagine in evidenza (Google Play). Un banner largo mostrato in più posizioni. Tenete il testo essenziale lontano dai bordi, che vengono ritagliati.
• Questionario sulla classificazione per età. Rispondete onestamente. Un'incoerenza tra le risposte e il contenuto reale è il modo più sicuro per essere rimossi dopo il lancio.

Privacy: ciò che fa rifiutare le app

Entrambi gli store richiedono ormai un inventario esplicito e strutturato dei dati che raccogliete e delle finalità. Apple lo chiama etichette sulla privacy, Google sezione Sicurezza dei dati. Sono moduli distinti, con lessico diverso, ed entrambi devono corrispondere a ciò che la vostra app fa davvero.

• Un URL di informativa privacy raggiungibile. Obbligatorio da entrambe le parti, online prima dell'invio, e realmente riferito alla vostra app anziché a un modello generico.
• Un inventario dati accurato. Elencate ogni categoria raccolta, comprese quelle acquisite dagli SDK di analytics o di crash reporting. Ciò che le librerie di terze parti raccolgono per vostro conto conta come vostro.
• La cancellazione dell'account. Se l'utente può creare un account nell'app, dovete offrire un modo per eliminarlo, raggiungibile dall'app stessa. È uno dei rifiuti tardivi più frequenti.
• Il permesso di tracciamento su iOS. Se tracciate gli utenti attraverso app o siti di altre aziende, dovete chiedere l'autorizzazione tramite il prompt di sistema. Farne a meno comporta la rimozione.

Canali di test: non inviate mai direttamente in produzione

Entrambi gli store offrono un percorso di preproduzione, gratuito in entrambi i casi. Usatelo: un bug trovato da dieci tester non costa nulla, lo stesso bug trovato da un revisore vi costa un ciclo di revisione.

• TestFlight (Apple). Distribuzione quasi immediata a tester interni, o a tester esterni dopo una revisione più leggera. I build scadono dopo 90 giorni.
• Test interni, chiusi e aperti (Google). Il test interno è quasi istantaneo. Un test chiuso su un piccolo gruppo merita almeno una settimana prima della produzione, e i nuovi account sviluppatore personali possono essere tenuti a svolgerlo.

Qualunque canale usiate, testate almeno su un Android piccolo e datato e su un iPhone recente. Questi due coprono gran parte delle sorprese di layout e prestazioni.

L'invio, passo dopo passo

• 1. Creare la scheda dell'app. Riservate il nome e l'identificativo di bundle o package. Quell'identificativo è definitivo: dopo la pubblicazione non si cambia, si può solo pubblicare una nuova app.
• 2. Caricare un build firmato. Apple richiede un archivio firmato inviato da macOS. Google richiede un Android App Bundle e una chiave di firma da non perdere mai: attivate Play App Signing perché Google ne conservi una copia.
• 3. Compilare la scheda dello store. Titolo, descrizione, screenshot, categoria, contatti e URL di supporto.
• 4. Completare le dichiarazioni. Privacy, sicurezza dei dati, classificazione per età, pubblicità, conformità all'esportazione e il questionario sui permessi se ne usate di sensibili.
• 5. Dare ai revisori un account funzionante. Se l'app ha un login, fornite credenziali di prova e, se serve, una breve nota su come raggiungere la funzionalità principale. Ometterlo è la prima causa di rifiuti inutili.
• 6. Inviare e scegliere la strategia di rilascio. Optate per la pubblicazione manuale se volete coordinare una data, e usate il rilascio graduale su Google Play perché un build difettoso raggiunga il 5% degli utenti anziché tutti.

I motivi di rifiuto che incontrerete davvero

I rifiuti sono normali, anche per team esperti. Quasi tutti rientrano in una manciata di categorie.

• Il revisore non è riuscito ad accedere. Credenziali dimostrative assenti o scadute, o un login che richiede un codice inviato al vostro telefono.
• Link rotti o crash. Un URL di supporto irraggiungibile o un crash sulla versione del dispositivo del revisore. Testate ogni link della scheda prima di inviare.
• «Funzionalità insufficienti». Apple rifiuta le app che sono un sito web impacchettato senza valore nativo. Se rilasciate una WebView, aggiungete vere funzioni del dispositivo e comportamento offline.
• Pagamenti fuori dallo store. Vendere contenuti digitali consumati nell'app richiede in genere l'acquisto in-app. Beni fisici e servizi del mondo reale no.
• Dichiarazione privacy incoerente. Dichiarate di non raccogliere nulla, ma un SDK di analytics acquisisce un identificativo di dispositivo.
• Problemi di metadati. Screenshot che non corrispondono più all'app, nomi di concorrenti nella descrizione, o un testo segnaposto rimasto lì.

In caso di rifiuto, leggete il numero esatto della linea guida citata, correggete solo quel punto e rispondete nel centro risoluzioni con una spiegazione breve e fattuale. Discutere aiuta di rado; una risposta precisa quasi sempre.

Dopo il lancio: i primi trenta giorni

Essere online è l'inizio del lavoro, non la fine. Il primo mese determina come gli store vi posizionano e se i primi utenti restano.

• Monitorate il tasso di crash per dispositivo. Entrambe le console lo riportano. Oltre circa l'1% delle sessioni, posizionamento e recensioni ne risentono.
• Rispondete a ogni recensione, in fretta. Le risposte pubbliche cambiano visibilmente la lettura di una scheda, e una lamentela risolta diventa spesso un voto più alto.
• Iterate sulla scheda, non solo sull'app. Cambiare il primo screenshot o il sottotitolo sposta il tasso di installazione più di una nuova funzionalità.
• Pubblicate un piccolo aggiornamento ogni poche settimane. La freschezza è un segnale di posizionamento, e un ritmo costante rende prevedibili i tempi di revisione.
• Portate il vostro traffico. La ricerca dello store non vi scoprirà da sola. Il vostro sito, la vostra lista e-mail e i clienti esistenti sono il canale di lancio.

Dove si colloca Cadrant

Cadrant interviene su ciò che precede l'invio: mettere un'app reale e funzionante davanti agli utenti abbastanza in fretta da sapere cosa merita di essere pubblicato. Descrivete schermate, dati e ruoli utente in linguaggio naturale, iterate su un'app viva in ore invece che in mesi, e il database resta nel vostro progetto Supabase. Quando il prodotto si è dimostrato valido con utenti veri, affrontate il percorso store con un perimetro stabile invece di tirare a indovinare.

L'ordine conta. Chi pubblica per la prima volta invia quasi sempre un perimetro che nessuno ha testato, poi spende i cicli di revisione a correggere problemi di prodotto anziché problemi di store.

In sintesi

Pubblicare è un progetto amministrativo con una dipendenza dal codice. Aprite presto entrambi gli account sviluppatore, preparate icona, screenshot, descrizione, informativa privacy e dichiarazioni sui dati in un'unica passata, usate un vero canale di test prima della produzione, e date ai revisori un account funzionante con istruzioni chiare. Fatto questo, la revisione è di solito la parte facile.