Guideline 2.1 App Store: capire e risolvere un rifiuto

La guideline 2.1 è la regola che fa cadere più invii. Lo scrive Apple stessa sulla sua pagina App Review: in media, oltre il 40 % dei problemi non risolti riguarda la 2.1, quella che copre crash, contenuti provvisori e informazioni incomplete.

Questo articolo tratta solo questa regola: cosa copre, le sue due varianti, come il reviewer testa la tua app e cosa rispondergli, con tre rifiuti che ho preso sulle mie app. Per una panoramica di tutti i motivi di rifiuto, leggi invece perché Apple rifiuta un'app.

Cos'è la guideline 2.1 App Completeness?

La guideline 2.1 richiede che l'app inviata ad Apple sia una versione finale e completa: niente crash, niente link non funzionanti, niente testo provvisorio, un account demo se l'app richiede un login, e acquisti in-app visibili e funzionanti. Se il reviewer non riesce a usare la tua app fino in fondo, è un rifiuto 2.1.

Il testo ufficiale si trova nelle App Review Guidelines, sezione 2 "Performance". Si divide in due commi.

2.1(a) chiede che ogni invio sia una versione finale, con tutti i metadati e URL funzionanti. Testo segnaposto, siti vuoti e qualsiasi contenuto temporaneo devono sparire prima dell'invio. L'app deve essere stata testata su un dispositivo reale per bug e stabilità. Se richiede un login, fornisci un account demo e tieni acceso il tuo server. Una modalità demo integrata può sostituire l'account, ma solo con l'approvazione preventiva di Apple, e deve mostrare tutte le funzioni dell'app. La frase che riassume tutto: "We will reject incomplete app bundles and binaries that crash".

2.1(b) riguarda gli acquisti in-app: devono essere completi, aggiornati, visibili al reviewer e funzionanti. Se un acquisto configurato in App Store Connect non si trova nell'app, devi spiegare perché nelle note per la revisione.

Cosa copre concretamente la guideline 2.1

In pratica, un rifiuto 2.1 arriva per uno di questi motivi:

• Un crash. All'avvio, dopo un permesso negato, senza rete. Ne basta uno.
• Un link non funzionante. Privacy, termini d'uso, supporto: ogni URL dichiarato verrà aperto.
• Una funzione inaccessibile. Un pulsante che non porta da nessuna parte, una schermata obbligatoria impossibile da superare, un onboarding senza uscita. La forma più subdola: invisibile sul tuo telefono.
• Un account demo mancante o scaduto. Il reviewer resta bloccato sulla schermata di login, oppure l'account fornito non funziona più, oppure il server è spento.
• Contenuto riempitivo. Lorem ipsum, "Disponibile a breve", schermate vuote, dati di test visibili.
• Acquisti in-app introvabili. L'abbonamento esiste in App Store Connect, ma il reviewer non trova la schermata che lo vende, oppure l'acquisto fallisce in sandbox. Gli errori più comuni sulla schermata di pagamento sono in paywall iOS: 7 errori da principiante.

2.1 Information Needed o 2.1(a): che differenza c'è?

I messaggi di Apple non hanno tutti lo stesso titolo, e la differenza cambia la tua risposta.

"Guideline 2.1 - Information Needed" significa che il reviewer non è riuscito a completare la revisione e ti fa una domanda. Manca una credenziale, una spiegazione, un modo per raggiungere una funzione. Non è ancora la constatazione di un bug: è una richiesta. A volte basta una risposta precisa in App Store Connect. Ma se la domanda rivela un vero blocco nell'app, serve una nuova build.

"Guideline 2.1(a) - Performance - App Completeness" significa che il reviewer ha riscontrato un problema: un crash, un bug, una schermata che non risponde. Il messaggio indica di solito il dispositivo usato e spesso allega uno screenshot. Qui devi correggere, inviare una nuova build e poi rispondere.

Come Apple testa la tua app

Mettiti nei panni del reviewer. Contano tre cose.

Testa su un dispositivo che forse non hai. Il messaggio di rifiuto spesso indica il modello. La regola 2.4.1 dice che le app iPhone devono funzionare su iPad quando possibile, e un'app pensata per iPhone ci appare in modalità compatibilità, in una finestra in formato iPhone. I miei rifiuti 2.1 recenti venivano da un iPad Air: se testi solo sul tuo iPhone, non vedi quello che vede il reviewer.

Parte da un primo avvio. App nuova, nessuna cache, nessuna sessione, nessun aggiornamento scaricato.

La rete deve funzionare solo in IPv6. La regola 2.5.5, vicina alla guideline 2.5.4 sulle modalità in background, richiede che l'app funzioni pienamente su una rete solo IPv6, e la pagina di supporto di Apple sull'IPv6 lo rende un requisito per tutte le app inviate dal 1° giugno 2016. Il rischio viene da un indirizzo IPv4 scritto nel codice: Apple consiglia di testare su una rete solo IPv6, con i dati cellulare disattivati.

Per riprodurre queste condizioni prima dell'invio, TestFlight su più dispositivi resta la via più semplice: vedi TestFlight: testare la tua app iPhone.

Tre rifiuti che ho preso, e la loro vera causa

Tre rifiuti recenti sulle mie app, con la loro vera causa.

Solys: una demo di minigioco impossibile da vincere su iPad

Solys è la mia sveglia con minigiochi. Il 18 agosto 2026 una build viene rifiutata con "2.1 Information Needed": Apple chiede un modo per superare la missione di gioco. Il reviewer testava su un iPad Air, con l'app iPhone in modalità compatibilità.

La vera causa era nella demo di minigioco dell'onboarding. Le altezze degli ostacoli erano scritte in punti fissi. Con l'altezza della card disponibile sull'iPad in compatibilità, il passaggio diventava più stretto del personaggio: la demo era impossibile da vincere. E il pulsante "Continua" si attivava solo in caso di vittoria. Nessuna via d'uscita: il reviewer non poteva vedere l'app.

La correzione: una geometria proporzionale alla dimensione misurata della card, e un link "Salta la demo" che compare dopo una sconfitta.

La lezione: ogni passaggio bloccato da una prestazione deve avere un'uscita senza condizioni. E ogni schermata obbligatoria va testata sullo schermo più piccolo supportato E su iPad in modalità compatibilità.

Nolera: una correzione invisibile per il reviewer

Il 17 settembre 2026 Nolera viene rifiutata dopo una revisione su iPad Air. Il messaggio combinava la 2.1(a) e altri punti. La correzione del problema segnalato era stata distribuita con un aggiornamento remoto (OTA), senza nuova build.

Il problema: al primissimo avvio il reviewer vede il codice incluso nella build, non l'aggiornamento scaricato dopo. Per lui la correzione non esisteva.

La lezione: una correzione destinata alla revisione deve stare nel binario inviato ad Apple.

Clic: la causa non era nell'app

Il 16 settembre 2026 Clic viene rifiutata. L'app era aggiornata. La vera causa era altrove: la privacy policy pubblicata online non era aggiornata sul fornitore di IA usato. Questo rifiuto riguarda più la privacy che la 2.1, ma illustra la stessa cosa: le vere cause non sono sempre quelle che il messaggio lascia intendere.

La lezione: controlla quello che è online, non quello che è nel tuo repository. Apri ogni URL dichiarato il giorno dell'invio.

Cosa rispondere nel Resolution Center

Dopo un rifiuto, il tuo invio passa in "Unresolved Issues" e la conversazione con Apple si svolge nella sezione App Review della tua app, che si chiama ancora Resolution Center. La procedura ufficiale per rispondere ad App Review consente un messaggio di massimo 4.000 caratteri, con un allegato.

Scrivi in inglese, in modo sobrio. Il reviewer vuole tre informazioni: cosa bloccava, cosa è cambiato, come verificarlo. Ecco il modello che uso (sostituisci il numero di build e la correzione con i tuoi):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Qualche regola:

• Rispondi alla domanda posta. Su un "Information Needed", inizia con la risposta esatta, non con il contesto.
• Indica la build e il percorso verso la schermata corretta, in tre o quattro azioni.
• Allega una prova. Un breve video su un dispositivo simile a quello del reviewer evita un altro giro.
• Niente arringhe. Il ricorso all'App Review Board esiste, ma su un rifiuto 2.1 meritato allunga solo l'attesa. I dettagli sui tempi sono in tempi di approvazione App Store.

Se il motivo resta poco chiaro dopo la lettura, la procedura completa è nella pagina app rifiutata da Apple.

Note per la revisione e account demo

La sezione App Review Information della tua versione, in App Store Connect, è la tua migliore difesa contro la 2.1. Secondo il riferimento ufficiale di questi campi, contiene:

• Sign-in required: nome utente e password di un account demo. L'account non deve scadere. Se la tua app usa un login di terze parti, fornisci le credenziali di quel servizio.
• Notes: fino a 4.000 byte, nella lingua che preferisci. Tutto ciò che aiuta a testare.
• Contact: un nome, un'email e un numero in formato internazionale.

Cosa metto sempre nelle note:

1. Il percorso verso ogni acquisto in-app, come richiede la regola 2.1(b).
2. Le funzioni non evidenti: un gesto, un permesso, un contenuto legato a un orario.
3. Lo stato dell'account demo: abbonato o no, dati precompilati o vuoti.
4. I limiti noti: per un hardware o un ambiente difficile da riprodurre, Apple chiede di essere pronti a fornire un video.

E una regola fuori dal modulo: tieni acceso il server per tutta la revisione. Un server di test spento significa un account demo che non funziona più, quindi un rifiuto 2.1.

La checklist 2.1 prima dell'invio

Quella che applico prima di ogni invio, costruita sui miei rifiuti:

• App installata da zero sull'iPhone più piccolo supportato, sul più grande e su un iPad in modalità compatibilità
• Onboarding percorso per intero, fallendo di proposito a ogni passaggio che richiede una prestazione
• Ogni schermata obbligatoria dotata di un'uscita senza condizioni
• Nessuna correzione destinata alla revisione distribuita solo tramite aggiornamento remoto
• App avviata in modalità aereo, poi su una rete solo IPv6
• Ogni URL dichiarato aperto il giorno stesso: privacy, termini, supporto
• Nessun testo provvisorio, schermata vuota o dato di test visibile
• Account demo testato il giorno dell'invio, senza data di scadenza, server acceso
• Ogni acquisto in-app trovato dall'app e testato in sandbox, ripristino compreso
• Note per la revisione che indicano dove si trovano gli acquisti e le funzioni non evidenti

Se è la tua prima pubblicazione, tutti i passaggi precedenti sono in pubblicare un'app sull'App Store.

Inviare la tua app con qualcuno che ha già preso questi rifiuti

L'Apple Review Kit riunisce la mia checklist pre-invio, i modelli di note per il reviewer e skill di Claude Code che rileggono il tuo progetto prima che tu lo invii.

Hai appena ricevuto un rifiuto 2.1? Il kit ti aiuta anche a ritrovare la regola citata, cosa richiede, e un esempio di correzione e di risposta. Se vuoi che guardiamo insieme la tua app da subito, prenota un'ora con me, in videochiamata.

Nessuno può garantire che Apple accetterà la tua app. Quello che posso fare è aiutarti a evitare i rifiuti 2.1 che ho già pagato con un ciclo di revisione.

Non hai ancora inviato la tua app? La diagnosi gratuita ti manda la mia checklist anti-rifiuto Apple, regola 2.1 compresa, e ti dice cosa resta da fare prima dell'invio. Se la stai ancora costruendo, la home mostra come creare un'app mobile pensando alla review fin dall'inizio.

Domande frequenti

Cosa significa "Guideline 2.1 - Information Needed"?

Il reviewer non è riuscito a completare la revisione e ti fa una domanda: una credenziale, una spiegazione, un modo per accedere a una funzione. Rispondi in modo preciso in App Store Connect. Se la domanda rivela un blocco reale nell'app, come per Solys, correggilo e invia una nuova build.

Serve una nuova build dopo un rifiuto 2.1?

Per un crash, un bug o una schermata bloccante, sì: la correzione deve stare nel binario. Un aggiornamento remoto non basta, perché al primo avvio il reviewer vede il codice incluso nella build. Per una semplice informazione mancante, può bastare una risposta.

La mia app richiede un login: cosa fornire al reviewer?

Un account demo che non scade, inserito nella sezione App Review Information, e un server acceso per tutta la revisione. Una modalità demo integrata può sostituire l'account solo con l'approvazione preventiva di Apple, e deve mostrare tutte le funzioni.

Un rifiuto 2.1 può dipendere da qualcosa che non è l'app?

Sì. Basta un URL non funzionante nella scheda, un account demo scaduto, un server spento o un acquisto in-app configurato male. E a volte, come per Clic, la vera causa è online e non nel codice: controlla tutto ciò che il reviewer può aprire.