Un rifiuto App Store arriva come un messaggio in App Store Connect: un numero di linea guida, qualche frase del revisore, spesso uno screenshot della schermata che non ha superato la prova. Non è un verdetto sulla vostra app né sul vostro account. L'App Review di Apple ha gestito più di 9,1 milioni di invii nel 2025, la maggior parte entro 24 ore, e una buona parte dei primi invii torna indietro almeno una volta. Ciò che conta è cosa fate nell'ora successiva al messaggio.
Quella decisione si riduce a tre domande. Il revisore ha ragione? La correzione richiede un nuovo build, o solo una modifica alla scheda? E se non siete d'accordo, rispondete o fate ricorso? Questa guida risponde nell'ordine: come vi arriva un rifiuto e cosa significano gli stati, gli otto motivi che coprono la maggior parte dei rifiuti, le tre risposte possibili, e una checklist per il reinvio.
Se siete più indietro nel percorso, la nostra guida su come pubblicare un'app sull'App Store copre l'intero cammino dall'account sviluppatore al rilascio; questo articolo comincia il giorno in cui la revisione torna negativa.
Come vi arriva un rifiuto e cosa significano gli stati
L'App Review combina controlli automatici, che intercettano crash, uso di API private e malware, con un revisore umano che installa il vostro build, apre la scheda, legge le vostre note per la revisione e usa l'app come farebbe un cliente. Quando qualcosa non va, il revisore scrive un messaggio nel Resolution Center di App Store Connect e la versione cambia stato. Tre stati contano:
- Rejected. Il binario stesso ha un problema: un crash, una funzionalità mancante, un problema di permessi. Dovrete quasi sempre caricare un nuovo build.
- Metadata Rejected. Il build va bene; la scheda no. Screenshot, descrizione, parole chiave, risposte sulla privacy o note per la revisione vanno modificati, cosa che fate direttamente in App Store Connect prima di reinviare senza un nuovo build.
- Developer Rejected. Avete ritirato la versione voi stessi, per esempio per sostituire un build. Niente a cui rispondere.
Gli otto motivi dietro la maggior parte dei rifiuti al primo invio
Le App Review Guidelines contano cinque capitoli e decine di regole, ma i rifiuti che un primo invio riceve davvero si concentrano su una manciata di esse. Eccoli, con ciò che il revisore ha visto e ciò che risolve il problema.
| Linea guida | Cosa ha visto il revisore | Cosa lo risolve |
|---|---|---|
| 2.1 Performance | L'app è andata in crash all'avvio o in un flusso centrale sul dispositivo del revisore | Riproducete sul binario TestFlight, su più dispositivi e versioni di iOS, e correggete. Non allegate nulla; caricate un nuovo build. |
| 2.1 App completeness | Un account dimostrativo che non funziona, contenuti segnaposto, una funzionalità «in arrivo» | Fornite un login funzionante con dati realistici in App Review Information; rimuovete o completate i segnaposto. |
| 2.3 Accurate metadata | Screenshot o descrizione mostrano funzionalità assenti dal build | Metadata Rejected: aggiornate screenshot e testi perché corrispondano all'app, reinviate lo stesso build. |
| 4.2 Minimum functionality | Un sito web in una cornice, o un'app che fa troppo poco per giustificare un'installazione nativa | Aggiungete valore nativo: uso offline, notifiche, funzioni del dispositivo, un'esperienza che il sito non offre. |
| 4.3 Spam | Un'app che ne duplica un'altra, vostra o nata da un modello, in una categoria satura | Differenziatela in modo sostanziale, o unite le varianti in una sola app. |
| 5.1.1 Data collection and storage | URL dell'informativa privacy mancante, etichette App Privacy che contraddicono l'app, richieste di permesso senza motivazione, prompt di tracciamento assente | Pubblicate l'informativa, allineate le etichette a ciò che l'app raccoglie davvero, scrivete una stringa di motivazione per ogni permesso, mostrate il prompt App Tracking Transparency se tracciate. |
| 3.1.1 In-app purchase | Contenuti digitali o abbonamenti venduti fuori dall'acquisto in-app di Apple | Usate l'acquisto in-app per i beni digitali; il pagamento esterno resta consentito per beni fisici e servizi consumati fuori dall'app. |
| 1.5 Developer information | Un URL di supporto che restituisce un errore o una pagina senza un modo per contattarvi | Metadata Rejected: fate puntare l'URL di supporto a una pagina online con un modulo di contatto o un'e-mail. |
Il caso particolare dei siti impacchettati
La linea guida 4.2 è quella che sorprende i fondatori che hanno impacchettato il loro sito web in un'app. La posizione di Apple è coerente: se l'app è il sito in una WebView senza nulla che il browser non potrebbe fare, non ha posto sull'App Store. La correzione non è una descrizione migliore; è la funzionalità. Accesso offline, notifiche push, fotocamera o posizione, una navigazione nativa che il sito non ha. Se il progetto è nato come app web, la via onesta è un vero build nativo, ed è per questo che la nostra guida su come creare un'app mobile senza programmare separa gli strumenti che generano codice nativo da quelli che impacchettano un sito.
Come reagire: correggere, rispondere o fare ricorso
Leggere il messaggio come una checklist
Prima di decidere qualsiasi cosa, estraete dal messaggio il numero della linea guida, il passaggio esatto che il revisore descrive, il dispositivo e la versione di iOS indicati in alto, e ogni screenshot allegato. Poi riproducetelo voi stessi sullo stesso build tramite TestFlight. Metà delle volte il revisore ha ragione e non ve n'eravate accorti; un quarto delle volte è incappato in un contesto che non avevate testato, come un'installazione pulita senza dati; il resto è un vero disaccordo.
Correggere e reinviare
Per uno stato Metadata Rejected, modificate la scheda in App Store Connect e cliccate su reinvia: nessun nuovo build, e la seconda revisione è di solito rapida. Per uno stato Rejected, caricate un build corretto, selezionatelo nella stessa versione e inviate di nuovo. In entrambi i casi, scrivete una breve nota nel Resolution Center per dire cosa è cambiato. I revisori la leggono, e orienta la seconda revisione verso la correzione invece di ripartire da zero.
Rispondere quando il revisore sbaglia
Se non riuscite a riprodurre il problema o la linea guida non si applica, rispondete nel Resolution Center invece di reinviare lo stesso build in silenzio. Restate sui fatti: i passaggi esatti che avete seguito, il dispositivo e la versione, una registrazione dello schermo che mostra la funzionalità in azione, le credenziali da usare. Se il revisore ha frainteso cosa fa l'app, spiegate il caso d'uso in due frasi. Potete anche chiedere una telefonata dall'App Review nello stesso thread; non è veloce, ma sblocca le conversazioni che il testo non riesce a chiudere.
Fare ricorso all'App Review Board
Un ricorso serve per un disaccordo sulla linea guida in sé, non su un fatto. Passa dall'App Review Board tramite il modulo collegato al rifiuto, e richiede giorni, a volte di più. Usatelo dopo che la risposta nel Resolution Center ha fallito, e scrivetelo per qualcuno che non ha mai visto la vostra app: cosa fa, quale linea guida è stata citata, perché ritenete che non si applichi. Se la linea guida è cambiata di recente, o se pensate che venga applicata in modo incoerente, ditelo e portate esempi.
La revisione accelerata
Apple concede una revisione accelerata per la correzione di un bug critico in un'app già online o per un evento con una data precisa, non per un primo rilascio in ritardo. Chiederla per un lancio viene rifiutato e fa perdere un giorno. Se la vostra scadenza è reale, l'unica leva è inviare presto e rispondere a ogni messaggio entro poche ore.
Una checklist per evitare il secondo rifiuto
La maggior parte dei secondi rifiuti ripete il primo, o fa emergere il problema successivo che il revisore non aveva raggiunto perché il primo aveva fermato la revisione. Prima di reinviare, scorrete questa lista una volta:
- Il binario TestFlight si apre su un'installazione pulita, senza dati, sulla versione di iOS più vecchia che supportate.
- L'account dimostrativo in App Review Information accede, e i dati dietro sembrano reali.
- Ogni richiesta di permesso ha una stringa di motivazione che dice cosa fa la funzionalità con i dati.
- L'URL dell'informativa privacy si apre, e le risposte App Privacy corrispondono agli SDK presenti nell'app.
- Gli screenshot mostrano schermate che esistono in questo build, nelle dimensioni di dispositivo giuste.
- Ogni acquisto digitale passa dall'acquisto in-app, e ogni acquisto fisico è chiaramente fisico.
- L'URL di supporto e l'URL marketing si caricano e offrono un modo per contattarvi.
- Testi segnaposto, pulsanti di test e schermate «in arrivo» sono spariti.
- Le note per la revisione spiegano tutto ciò che è insolito: un requisito hardware, una funzionalità limitata a una regione, un accesso tramite un servizio terzo.
Se costruite con il creatore di app mobile di Cadrant, le parti del percorso che causano rifiuti a livello di build sono gestite per voi: il binario nativo viene compilato e firmato sul vostro account Expo, inviato al vostro App Store Connect, e l'app è una vera applicazione Expo e non un sito impacchettato, il che tiene fuori la linea guida 4.2. Ciò che resta a voi è esattamente questa checklist: la scheda, le risposte sulla privacy, l'account dimostrativo e un passaggio su TestFlight prima di premere invia. La documentazione sulla pubblicazione elenca i passi in App Store Connect nell'ordine.
In sintesi
- Un rifiuto è un messaggio con un numero di linea guida; lo stato vi dice se la colpa è del build o della scheda.
- Otto linee guida spiegano la maggior parte dei primi rifiuti: crash, account dimostrativo, metadati, funzionalità minima, spam, privacy, acquisto in-app, URL di supporto.
- Correggete e reinviate quando il revisore ha ragione, rispondete con prove quando i fatti sono sbagliati, fate ricorso solo quando è la linea guida stessa a essere in discussione.
- Rispondete in giornata, e scorrete la checklist prima di ogni reinvio.
Gestito così, un rifiuto costa un giorno o due, non un lancio. Le app che restano bloccate sono quelle che reinviano lo stesso build sperando in un altro revisore.