Pubblicare un'app su App Store e Google Play: account, revisione, requisiti e rifiuti ricorrenti

Pubblicare un'app negli store non è un passaggio finale: è un progetto dentro il progetto, con requisiti che cambiano ogni anno e revisioni che possono rimandare un lancio di settimane. La maggior parte dei ritardi che vedo non nasce dal codice, ma da account aperti male, documentazione sulla privacy incompleta e linee guida lette troppo tardi.

Gli account: la decisione da prendere per prima

L'account sviluppatore va aperto a nome del titolare dell'app, come organizzazione, non a nome dello sviluppatore o dell'agenzia. Lo sviluppatore viene aggiunto al team con i ruoli necessari. Se l'app è nell'account di qualcun altro, trasferirla in seguito è possibile ma macchinoso, e nel frattempo il cliente non controlla un proprio bene.

• Apple Developer Program: quota annuale; per le organizzazioni serve un numero D-U-N-S, la cui emissione può richiedere giorni.
• Google Play Console: quota una tantum; verifica dell'identità e, per gli account personali più recenti, un test chiuso obbligatorio con un numero minimo di tester per un periodo prestabilito prima dell'accesso alla produzione.

Entrambi i passaggi vanno avviati all'inizio dello sviluppo, non alla fine.

La documentazione sulla privacy

È la parte che più spesso blocca una pubblicazione.

• App Store: le «etichette» sulla privacy dichiarano quali dati l'app raccoglie e a che scopo, comprese le librerie di terze parti. Da qualche anno servono anche i privacy manifest per l'app e per gli SDK che usano API considerate sensibili.
• Google Play: la sezione Sicurezza dei dati con le stesse informazioni, che Google confronta con il comportamento reale dell'app.
• Informativa privacy pubblicata a un URL raggiungibile.
• Cancellazione dell'account: se l'app permette di registrarsi, deve permettere di cancellare l'account dall'app stessa, e Google richiede anche un percorso web.

Le dichiarazioni devono essere coerenti con ciò che fanno davvero l'app e i suoi SDK: analytics e crash reporting inclusi.

Le linee guida che causano più rifiuti

Sulla base dei motivi ricorrenti:

• Funzionalità minima: un sito impacchettato in una WebView, senza funzioni proprie, viene respinto.
• Completezza: link rotti, schermate segnaposto, funzioni «in arrivo», credenziali di prova non fornite al revisore.
• Login: se si offre l'accesso tramite servizi di terze parti, Apple richiede anche un'opzione di accesso attenta alla privacy.
• Pagamenti: i contenuti e le funzioni digitali venduti dentro l'app passano dal sistema di acquisto dello store; i beni e i servizi fisici no. Il confine va valutato con attenzione.
• Permessi: ogni richiesta di accesso (posizione, fotocamera, contatti) deve avere una spiegazione chiara e corrispondere a un uso reale.
• Metadati: screenshot che non mostrano l'app vera, descrizioni con riferimenti ad altre piattaforme.

Il percorso tecnico

1. Firma e identificativi: bundle ID e application ID definitivi, certificati e chiavi di firma conservati in modo sicuro. Su Google Play si usa la firma gestita dallo store.
2. Build di rilascio con le configurazioni di produzione, separate da quelle di sviluppo.
3. Distribuzione di prova: TestFlight su iOS, tracce di test interne e chiuse su Google Play, con tester reali.
4. Scheda dello store: nome, descrizioni, parole chiave, screenshot per le dimensioni richieste, icona, classificazione dei contenuti.
5. Invio in revisione con note per il revisore e un account di prova funzionante.
6. Rilascio graduale dove possibile, per limitare l'impatto di un bug arrivato in produzione.

Dopo la pubblicazione

Ogni anno Google alza il livello minimo di API richiesto per aggiornare le app, e Apple richiede di compilare con le versioni recenti degli strumenti. Un'app non aggiornata smette prima o poi di poter ricevere aggiornamenti, e a volte viene nascosta ai nuovi utenti. La manutenzione negli store è un costo ricorrente da prevedere fin dal primo preventivo.

Una lista prima dell'invio

• Account a nome del titolare, con lo sviluppatore come membro del team.
• Privacy dichiarata e coerente con SDK e comportamento reale.
• Cancellazione dell'account disponibile, se c'è la registrazione.
• Account di prova e note per il revisore.
• Nessuna schermata incompleta o link rotto.
• Test chiuso completato, dove richiesto.

Tempi realistici

Una pianificazione onesta della pubblicazione, a sviluppo concluso, prevede:

• account: da subito, perché la verifica dell'organizzazione e il numero D-U-N-S possono richiedere giorni o settimane;
• test chiuso su Google Play, dove richiesto, con il periodo minimo e il numero di tester previsti: va avviato appena c'è una build stabile;
• documentazione privacy e scheda dello store: qualche giorno, soprattutto per gli screenshot nelle dimensioni richieste e per l'inventario dei dati raccolti dagli SDK;
• revisione: di solito rapida, ma con il margine per almeno un rifiuto e un nuovo invio;
• rilascio graduale: qualche giorno di osservazione su una parte degli utenti prima del 100%.

Legare un lancio a una data fissa senza questi margini è la causa più frequente di annunci rimandati. Meglio pubblicare in modalità non visibile e attivare l'app quando serve.

Come la vedo io

Prima di affrontare la pubblicazione chiedo sempre se lo store serve davvero. Per molti progetti una web app o una PWA, aggiornate con un deploy e senza revisioni, coprono tutto il necessario: lo spiego in App nativa, web app o PWA. Quando lo store serve, la pubblicazione va trattata come una fase del progetto con i suoi tempi, non come un clic finale.

E insisto sempre su un punto: account e chiavi di firma a nome del cliente. È la stessa regola che applico a domini, repository e hosting: chi paga il progetto deve possederlo, anche se un giorno sceglierà un altro sviluppatore.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Seguo la pubblicazione negli store dalla configurazione degli account alla revisione, con la documentazione sulla privacy coerente con il codice.

Se devi pubblicare un'app, scrivimi: in una chiacchierata di circa 20 minuti mettiamo in fila requisiti e tempi. Il servizio è in App mobile.