Otto motivi per cui la revisione dell'App Store ti rimanda indietro l'app

La risposta breve: la maggior parte dei rifiuti di app su App Store e Google Play non è causata da un bug nel codice. È causata da elementi amministrativi che controlla il titolare dell'azienda, non lo sviluppatore — un account demo con cui il revisore possa accedere, un'informativa sulla privacy completa, una dichiarazione dei dati che corrisponda alla realtà, un account sviluppatore intestato all'azienda e una scadenza tecnica già passata. Ognuno di questi elementi si può preparare due settimane prima del lancio senza scrivere una sola riga di codice.

L'impatto sul calendario è più grande di quanto sembri. Un rifiuto non significa che l'app sia fatta male; significa che l'app torna in fondo alla coda dopo ogni correzione, e così una campagna di lancio legata a una stagione o a un evento si trasforma in un ritardo senza fine prevedibile. Per questo il dossier di pubblicazione merita di essere trattato come parte del progetto, non come una pratica burocratica lasciata all'ultimo giorno.

1 — Non c'è un account demo con cui il revisore possa aprire la tua app

È il motivo più ricorrente nelle app che iniziano con una schermata di accesso. Il revisore non è uno dei tuoi clienti e non ha un numero di telefono registrato nel tuo sistema, quindi senza credenziali pronte si ferma alla prima schermata. La regola di Apple sulla completezza dell'app (App Completeness, 2.1) è esplicita: invia una versione definitiva, includi i dati di un account demo se la tua app prevede un accesso e tieni acceso il tuo servizio di back-end. Se obblighi legali o di sicurezza ti impediscono di fornire un account reale, puoi includere una modalità demo integrata che mostri tutte le funzionalità dell'app, con l'approvazione preventiva di Apple.

In pratica: prepara un account permanente che non scada e non venga cancellato durante le pulizie dei dati, e assicurati che i server di staging siano attivi per tutta la finestra di revisione, non solo durante il tuo orario d'ufficio.

2 — Lo store vede la tua app come un sito web riconfezionato

La regola sulla funzionalità minima (Minimum Functionality, 4.2) stabilisce che un'app deve includere funzioni, contenuti e interfaccia che la elevino al di sopra di un sito web riconfezionato, e che non sono accettabili le app che sono principalmente materiale di marketing, ritagli web, aggregatori di contenuti o una raccolta di link. Molte aziende chiedono un'app perché un concorrente ne ha una, e il prodotto esce come una copia del sito dentro un guscio.

Le vie d'uscita sono due: o dai all'app un valore reale che il browser non può offrire — uso offline, notifiche in base allo stato dell'ordine, scansione di codici a barre, dati salvati sul dispositivo, integrazione di pagamenti e mappe — oppure pubblichi una progressive web app invece di passare dagli store. Abbiamo affrontato questa scelta in progressive web app o app nativa.

3 — L'informativa sulla privacy è incompleta o assente all'interno dell'app

La regola di Apple sulla raccolta dei dati (Data Collection, 5.1.1) richiede un link all'informativa sulla privacy nei metadati di App Store Connect e all'interno dell'app, in un punto facilmente accessibile. L'informativa deve indicare quali dati vengono raccolti, come e ogni uso che se ne fa; confermare che qualunque terza parte con cui condividi dati — strumenti di analisi, reti pubblicitarie, SDK di terze parti — offra la stessa protezione; e spiegare le politiche di conservazione e cancellazione e come l'utente revoca il consenso.

Non è una pagina da copiare da un altro sito. È una descrizione di ciò che il tuo sistema fa davvero, e deve essere coerente con i tuoi obblighi ai sensi della Legge saudita sulla protezione dei dati personali (PDPL), come spieghiamo nella nostra guida pratica alla PDPL.

4 — Nell'app non è possibile eliminare l'account

La regola 5.1.1 (v) è chiara: se la tua app consente di creare un account, devi anche offrire l'eliminazione dell'account all'interno dell'app. E aggiunge una regola che molti team trascurano: se la tua app non include funzionalità significative basate su un account, lascia che le persone la usino senza accesso, e non chiedere informazioni personali a meno che non siano direttamente pertinenti alla funzionalità principale o richieste dalla legge.

L'eliminazione dell'account qui non è solo un pulsante nell'interfaccia; è un percorso completo nel back-end. Che fine fanno gli ordini, le fatture e le registrazioni contabili del cliente che per legge non possono essere cancellati? La risposta abituale è separare i dati identificativi dai documenti finanziari prima che inizi lo sviluppo, non dopo.

5 — La dichiarazione sulla sicurezza dei dati di Google Play non corrisponde a ciò che fa l'app

Google richiede a ogni sviluppatore di dichiarare i dati che l'app raccoglie e trasmette fuori dal dispositivo, compresi i dati raccolti da librerie e SDK di terze parti, se la raccolta è obbligatoria o facoltativa, la finalità, se i dati sono crittografati in transito e se esiste un meccanismo per richiederne la cancellazione. Le norme stabiliscono che il solo sviluppatore è responsabile dell'accuratezza delle dichiarazioni e che le violazioni comportano il blocco degli aggiornamenti o la rimozione da Google Play.

L'errore tipico è semplice: uno sviluppatore ha aggiunto uno strumento di analisi o di segnalazione degli arresti anomali per facilitarsi il lavoro, e nessuno l'ha inserito nella dichiarazione. Fai al tuo team una sola domanda prima dell'invio: qual è l'elenco completo dei pacchetti di terze parti in questa app, e che cosa invia ciascuno di essi?

6 — L'aggiornamento viene rifiutato perché l'app ha come target una versione vecchia di Android

Dal 31 agosto 2026 Google Play richiede che le nuove app e gli aggiornamenti abbiano come target Android 16 (livello API 36) o superiore, con alcune eccezioni: Wear OS e Android Automotive al livello 35, Android TV e Android XR al livello 34. Gli sviluppatori che hanno chiesto una proroga hanno tempo fino al 1° novembre 2026.

La conseguenza operativa per il titolare di un'azienda: la tua app pubblicata resta nello store, ma non puoi rilasciare alcun aggiornamento — nemmeno una correzione di sicurezza urgente o una modifica di prezzo — finché non viene ricompilata per il livello richiesto. Qualsiasi app che non sia stata aggiornata da un anno merita una verifica su questo punto prima che ti serva un rilascio urgente.

7 — I nuovi account hanno bisogno di 12 tester e 14 giorni prima di pubblicare

Gli account sviluppatore personali creati su Google Play dopo il 13 novembre 2023 non possono pubblicare subito in modo pubblico. Hanno bisogno di un test chiuso con almeno 12 tester iscritti in modo continuativo per almeno 14 giorni prima di poter richiedere l'accesso alla produzione. Sono due settimane in più nel calendario e 12 persone reali con account Google reali.

Dall'altra parte, iscriversi all'Apple Developer Program come organizzazione richiede un numero D-U-N-S e una persona giuridica in grado di stipulare contratti, con la ragione sociale dell'organizzazione — non un nome commerciale e non una filiale. Ottenere il numero e superare la verifica richiede giorni. Avvia questa pratica nella prima settimana del progetto, non nella settimana del lancio.

8 — Metadati dello store, screenshot e un'app separata per ogni filiale

Tre piccole regole affossano interi rilasci: gli screenshot devono mostrare l'app in uso, non l'immagine del titolo, la pagina di accesso o la schermata iniziale (2.3.3); il nome dell'app è limitato a 30 caratteri e i metadati non possono essere riempiti di termini di marchi registrati, nomi di app popolari o prezzi (2.3.7); e non puoi creare più bundle ID della stessa app (4.3a) — che è esattamente ciò che accade quando un'azienda chiede un'app separata per ogni filiale o città. Lo schema corretto è un'unica app in cui l'utente seleziona la filiale.

Come si inserisce questo cancello nel piano di progetto

  • Registra l'account sviluppatore a nome della tua azienda, non dello sviluppatore né dell'agenzia. È un bene aziendale come il dominio, come abbiamo spiegato in a chi appartengono i diritti del tuo software.
  • Apri gli account nella prima settimana: Apple costa 99 $ all'anno e Google Play prevede una quota una tantum di 25 $, e a richiedere tempo è la verifica, non il pagamento.
  • Inserisci una clausola nel contratto che indichi chi invia la build e risponde alle note della revisione, e quanti cicli di revisione copre il prezzo.
  • Tratta il dossier di pubblicazione come un deliverable a sé: informativa sulla privacy, dichiarazione dei dati, screenshot, descrizione, account demo e l'elenco dei pacchetti di terze parti.
Il codice è pronto una settimana prima del lancio. Il dossier di pubblicazione richiede due settimane. Sbagliare questo ordine è la causa della maggior parte dei lanci in ritardo.

Fonti