App Store e Google Play: come evitare il rifiuto
La maggior parte dei rifiuti nasce da una preparazione mancante, non da codice difettoso. Cosa deve essere pronto prima di inviare, per entrambi gli store.
Team rabbitclipPubblicato: 5 min di lettura
In breve
La maggior parte dei rifiuti su App Store e Google Play non nasce da codice difettoso ma da una privacy policy mancante, una richiesta di permesso non spiegata, o un account di test mancante. Quando questi elementi sono pronti prima dell'invio, l'app di solito supera la revisione al primo tentativo.
I due store revisionano in modo diverso. Apple si affida alla revisione umana ed è più severa; Google si affida di più alla scansione automatica ma agisce comunque con fermezza sulle violazioni delle policy. Ognuno richiede una preparazione propria.
Cosa deve essere pronto prima dell'invio
La privacy policy è obbligatoria per entrambi gli store e deve riflettere davvero i dati che l'app raccoglie; un modello copiato e incollato tende a creare problemi in revisione.
Se l'app richiede un permesso (posizione, fotocamera, notifiche), una breve spiegazione del perché serve dovrebbe essere visibile sia all'utente sia al revisore. Apple la cerca in modo specifico.
- Una privacy policy (accessibile tramite una URL attiva)
- Spiegazioni dei permessi (posizione, fotocamera, notifiche, contatti)
- Un account di test per la revisione (per app che richiedono il login)
- Screenshot e testi dello store che rispecchiano l'interfaccia reale
Perché Apple rifiuta le app
Tra i motivi di rifiuto più comuni di Apple ci sono funzionalità mancante (crash, schermate vuote), un permesso non spiegato e violazioni delle regole sugli acquisti in-app. Il revisore usa davvero l'app; se l'account di test non funziona, arriva il rifiuto.
Un altro motivo frequente è che l'app appaia come un semplice contenitore attorno a un sito web. Apple vuole vedere un valore nativo genuino; questo rende utile la cura dedicata all'interfaccia e all'esperienza.
Perché Google Play rifiuta le app
Dal lato Google, il problema più comune è un modulo Data Safety che non corrisponde a ciò che l'app raccoglie davvero. Se quel modulo è compilato in modo incompleto o scorretto, i sistemi automatici lo segnalano.
Anche il livello API target va tenuto aggiornato; Google alza il livello API target minimo ogni anno, e le app rimaste su un livello vecchio possono perdere la possibilità di essere installate o aggiornate.
L'esperienza di un produttore di abbigliamento da lavoro
L'app di ordini B2B di un produttore di abbigliamento da lavoro è stata rifiutata al primo invio perché non era spiegato il motivo della richiesta del permesso di posizione. È stata aggiunta una spiegazione e la stessa versione è stata reinviata lo stesso giorno; ha superato la seconda revisione.
È un esempio utile: il rifiuto nasce di solito non da codice scadente ma da qualcosa che un revisore non ha potuto vedere spiegato. Impostare bene la lista di preparazione fin dall'inizio previene la maggior parte dei rifiuti.
Il criterio di decisione qui era semplice: per ogni permesso richiesto dall'app è stata scritta una risposta di una frase a 'a cosa serve davvero questo permesso nell'app'. Quel singolo passo ha permesso al secondo invio di passare senza problemi sia su Apple sia su Google.
Come prepararsi: passo dopo passo
Trattare la preparazione dell'invio come una sequenza invece che come una checklist una tantum abbassa il rischio su entrambi gli store. Il primo passo è elencare ogni permesso richiesto dall'app e scrivere in anticipo la spiegazione rivolta all'utente per ciascuno; questo si può fare già in fase di design, prima che lo sviluppo sia finito.
Il secondo passo è creare un account di test che funzioni davvero per ogni schermata che richiede il login, e percorrere l'app dall'inizio alla fine come farebbe un revisore. Il terzo è contare ogni dato effettivamente raccolto dall'app, incluso qualsiasi strumento di analisi o servizio di notifica, quando si compila il modulo Data Safety di Google Play; anche un servizio di terze parti dimenticato può invalidare l'intero modulo.
L'ultimo passo è verificare che gli screenshot dell'invio e il testo dello store corrispondano esattamente all'interfaccia attuale dell'app; uno screenshot rimasto da un design più vecchio è un motivo di rifiuto piccolo ma sorprendentemente comune.
Errori frequenti
L'errore più frequente è scrivere la privacy policy e le spiegazioni dei permessi all'ultimo minuto, la notte prima dell'invio, una volta finito lo sviluppo; un testo scritto di fretta tende a ridursi a frasi generiche che non soddisfano né il revisore né l'utente.
Il secondo è dare per scontato che una versione approvata su una piattaforma passi anche sull'altra senza modifiche. Apple e Google guardano a cose diverse; una spiegazione dei permessi che soddisfa Apple può lasciare comunque incompleto il modulo Data Safety di Google. Ogni store va preparato secondo i propri criteri.
- Lasciare privacy policy e testi dei permessi all'ultimo momento
- Dare per scontato che una preparazione sufficiente per uno store basti anche per l'altro
- Creare l'account di test appena prima dell'invio, senza provarlo davvero
Quanto dura la revisione
La revisione di Apple si conclude di solito in pochi giorni, ma un ciclo di rifiuto e reinvio allunga i tempi. La revisione automatica di Google è più rapida, ma le app segnalate per un problema di policy passano a revisione manuale e possono richiedere più tempo.
Il rifiuto in store è di solito una lacuna nella preparazione, non un problema di codice; quando privacy policy, spiegazioni dei permessi e account di test sono completi fin dall'inizio, il processo procede senza intoppi. Che stiate inviando per la prima volta o reinviando con un aggiornamento, vale la pena rivedere insieme questa lista.
Domande frequenti
Quanto dura la revisione dell'App Store?
Di solito pochi giorni; non c'è un tempo garantito e varia in base al volume di revisione.
Perché il modulo Data Safety conta così tanto su Google Play?
Se i dati dichiarati nel modulo non corrispondono a ciò che l'app raccoglie davvero, i sistemi automatici lo segnalano, il che può portare a rifiuto o sospensione.
Si può inviare un'app senza account di test?
Non per le app che richiedono il login; il revisore o il sistema deve poter usare davvero l'app.
Il processo ricomincia da capo dopo un rifiuto?
No, di solito il problema segnalato viene corretto, la stessa versione viene reinviata e rientra nella coda di revisione.
