Rifiuto dell'App Store: come risolverlo, linea guida per linea guida (2026)

Un rifiuto dell'App Store è un messaggio di App Review che cita una linea guida, descrive ciò che il revisore ha visto e blocca la release finché non correggi il problema, lo spieghi o presenti ricorso. Inizia trasformando quel messaggio in un problema che puoi verificare. Il passo successivo dipende dal fatto che il revisore non sia riuscito a usare l'app, abbia riscontrato una non conformità alle policy o abbia bisogno di più informazioni. A ottobre 2026, le App Review Guidelines risultano aggiornate l'ultima volta il 16 ottobre 2026, quindi controlla la numerazione aggiornata prima di citare una sezione.

Cosa ti dice davvero un messaggio di rifiuto dell'App Store?

Un messaggio di rifiuto dell'App Store indica la linea guida applicata dal revisore, descrive il comportamento specifico osservato ed elenca i passi successivi. Spesso include il dispositivo, la versione di iOS e degli screenshot.

Salva il messaggio completo, gli eventuali screenshot, il numero di build e i dettagli del dispositivo. Leggi la sezione citata sulla pagina aggiornata delle linee guida. Poi scrivi una frase: "Il revisore non è riuscito a completare X perché Y." Se il messaggio chiede informazioni mancanti invece di segnalare un difetto, annota esattamente cosa manca. Il testo standard di Apple per la 2.1 spiega anche come riprodurre il problema: "Per le nuove app, disinstalla tutte le versioni precedenti dell'app da un dispositivo, poi installala e segui i passaggi per riprodurre il problema."

• Il messaggio parla di un crash, di una schermata inaccessibile o di una funzionalità incompleta? Riproduci quel flusso nella build di release inviata, sul tipo di dispositivo indicato da Apple.
• Parla di screenshot, descrizione o note per la revisione? Verifica se puoi risolvere intervenendo solo sui metadati.
• Parla di pagamenti, login, privacy o funzionalità minime? Confronta il comportamento del prodotto con la linea guida citata.

Quali linee guida citano i rifiuti dell'App Store e cosa richiedono?

Ogni linea guida stabilisce un requisito concreto, quindi abbina il numero citato al suo testo e verifica l'app rispetto a quel testo. La tabella riporta il testo attuale delle linee guida citate più spesso nei messaggi di rifiuto.

L'aggiornamento del 16 ottobre 2026 ha aggiunto la 2.5.19 per le funzionalità nascoste, dormienti o non documentate, che prima rientravano nella 2.3.1. Ha anche aggiunto la 2.3.14 sugli asset creativi e ha accorpato l'entitlement Music Streaming Services nell'entitlement StoreKit External Purchase Link previsto dalla 3.1.1(a). Considera la tabella un punto di partenza, non una soluzione garantita. Una stessa linea guida può coprire problemi diversi, e l'esempio del revisore è il caso concreto che devi risolvere.

Come si risolve un rifiuto 4.2 per funzionalità minime?

Un rifiuto 4.2 si risolve aggiungendo valore reale all'app, non riscrivendo la descrizione. La linea guida 4.2 dice: "Se la tua app non è particolarmente utile, unica o 'simile a un'app', non è adatta all'App Store."

Chiediti cosa può fare un utente nella tua app che la renda utile in quanto app. Potrebbe completare un flusso di lavoro, salvare uno stato significativo, usare le capacità del dispositivo in modo coerente con l'app oppure avere un'esperienza mobile pensata per il dispositivo. Nessun elenco di funzionalità pubblicato garantisce l'approvazione. Se questi flussi esistono già, elencali nelle note per la revisione con passaggi precisi e screenshot. Se l'app mostra soprattutto una pagina web, serve lavoro sul prodotto. Aggiungere notifiche o una schermata impostazioni vuota solo per sembrare nativa non sostituisce un valore reale per gli utenti.

Come si risponde ad App Review in App Store Connect?

Rispondi in App Store Connect: apri l'invio dal link dei problemi irrisolti dell'app, fai clic su Resolve, poi su Reply to App Review. Secondo la pagina di assistenza di Apple, serve il ruolo di Account Holder, Admin o App Manager.

1. In Apps, seleziona l'app.
2. In cima alla pagina, fai clic sul link che segnala la presenza di problemi irrisolti.
3. Nella sezione In Progress, fai clic su Resolve accanto all'invio.
4. Fai clic su Reply to App Review e inserisci il testo.
5. Per includere screenshot o documenti, fai clic su Attach File, poi su Reply.

Apple specifica che puoi scambiare messaggi e allegare file "finché non reinvii ad App Review", quindi invia le prove prima di reinviare. Mantieni la risposta breve e fattuale: indica cosa è cambiato, dove si trova e come verificarlo. Non discutere di altre app che sembrano fare la stessa cosa.

Correggere i metadati, caricare una nuova build o fare ricorso?

Correggi i metadati e reinvia la stessa build quando erano sbagliate solo le informazioni della scheda. Carica una nuova build quando il comportamento dell'app deve cambiare. Fai ricorso solo se ritieni che l'app sia già conforme alla linea guida.

Le indicazioni di Apple sui ricorsi chiedono di "spiegare punto per punto come la tua app soddisfa" la linea guida. Specificano anche di non fare ricorso dopo aver già corretto i problemi e reinviato l'app. Un ricorso completo "non garantisce" che la decisione venga ribaltata. Per le app già sullo store, la policy Bug Fix Submissions delle linee guida stabilisce che le correzioni di bug non verranno ritardate per violazioni delle linee guida "tranne quelle relative a questioni legali o di sicurezza".

Come hanno risolto altri sviluppatori rifiuti reali dell'App Store?

Nelle discussioni pubbliche sui forum, molti rifiuti 2.1 derivavano da differenze tra la configurazione del revisore e quella dello sviluppatore: una rete, un dispositivo o uno stato dei permessi diversi. Un rifiuto 4.2 è invece un problema di prodotto, quindi piccoli ritocchi raramente bastano.

Errore di login con la 2.1. Uno sviluppatore sugli Apple Developer Forums ha riportato il messaggio "Nello specifico, non siamo riusciti ad accedere a causa di un errore", anche se la versione pubblicata e quella su TestFlight accedevano con le stesse credenziali. Altri sviluppatori nella discussione hanno riportato soluzioni diverse. Uno ha risolto "passando da http a https sul web server". Un altro, dopo tre rifiuti, ha aggiunto uno stato "Controlla la connessione" al posto di un caricamento infinito. Un terzo, dopo cinque rifiuti, ha rimosso l'iPad dal deployment target: una soluzione che aggira il problema rinunciando al supporto per iPad.

Crash all'avvio. Sul forum di Solar2D, uno sviluppatore si è sentito dire "Non siamo riusciti a revisionare l'app perché si è chiusa in modo anomalo all'avvio" su un iPhone 13 mini con iOS 18.3.2. Il crash log allegato mostrava che mancava la chiave NSUserTrackingUsageDescription. Lo sviluppatore ha confermato: "È passata dopo aver aggiunto: NSUserTrackingUsageDescription."

App WebView con la 4.2. Uno sviluppatore sugli Apple Developer Forums ha segnalato il decimo rifiuto per un'app basata su WebView. Il revisore aveva inviato uno screenshot del menu laterale sinistro dicendo che mancavano contenuti. Le schermate principali ormai erano native, ma due o tre aprivano ancora una WebView. La risposta contrassegnata come soluzione è arrivata da App Review e consigliava una consulenza individuale con App Review. La discussione non conferma un'approvazione.

Il confronto: i casi 2.1 sono stati risolti riproducendo le condizioni del revisore e leggendo il crash log. Il caso 4.2 si è arenato perché ogni reinvio modificava solo una parte di un'app che restava per lo più un sito web.

Come evitare che lo stesso rifiuto si ripeta?

Trasforma ogni problema risolto in una voce della checklist di release e ritestala nella build di release prima di ogni invio. Le linee guida di Apple avvertono che la revisione "richiederà più tempo" se un'app viene rifiutata ripetutamente per la stessa violazione.

• Elimina l'app, poi installa da zero la build di release su un iPhone e un iPad fisici.
• Accedi con l'account di revisione su una rete senza server di sviluppo né eccezioni HTTP.
• Apri ogni richiesta di permesso e verifica che esista ogni usage description in Info.plist.
• Assicurati che ogni acquisto in-app sia inviato, visibile e spiegato nelle note per la revisione.
• Aggiorna le note per la revisione ogni volta che un flusso cambia. Non incollare note di sei release fa.

Per i problemi 2.1, segui il piano di test della build di release per i rifiuti 2.1 e configura un account demo per il revisore. Poi completa la checklist di invio per la build successiva. Se il messaggio di revisione ti lascia ancora bloccato, inviaci i dettagli e ti aiuteremo a capire se il tassello mancante riguarda l'accesso, i metadati o il codice.