Rifiuto App Store 2.1 App Completeness: piano di test della build di release prima di reinviare (2026)

Un rifiuto App Store per la 2.1 App Completeness significa che il revisore non è riuscito a usare la tua app come farebbe un cliente. Magari è andata in crash, ha mostrato contenuti segnaposto, lo ha bloccato a una schermata di login o ha nascosto un acquisto in-app. La soluzione raramente è una singola riga di codice. Prima di reinviare, esegui un breve piano di test sulla build di release, usando un'installazione pulita e le stesse credenziali che fornisci ad App Review. Questo articolo illustra il piano e mostra come altri sviluppatori hanno risolto lo stesso rifiuto.

Cosa verifica la linea guida 2.1 App Completeness dell'App Store?

La linea guida 2.1 verifica che la build inviata sia un'app finita e funzionante. Servono metadati completi, link funzionanti, un login demo, un back end attivo e acquisti in-app che il revisore possa trovare e usare.

Le App Review Guidelines di Apple dividono la 2.1 in due parti. La 2.1(a) afferma che gli invii "devono essere versioni definitive con tutti i metadati necessari e URL pienamente funzionanti" e che testo segnaposto e siti web vuoti vanno rimossi. Chiede inoltre di testare su dispositivo per individuare bug e problemi di stabilità, e di "includere le informazioni dell'account demo (e attivare il servizio di back end!) se la tua app prevede un login". Apple "rifiuterà bundle e binari incompleti che vanno in crash o presentano evidenti problemi tecnici". La 2.1(b) afferma che gli acquisti in-app devono essere "completi, aggiornati, visibili al revisore e funzionanti". Se un acquisto configurato non si trova nell'app, spiega il motivo nelle note per la revisione.

Questo rifiuto è frequente. La pagina Preparing for App Review di Apple dice: "In media, oltre il 40% dei problemi irrisolti riguarda la linea guida 2.1: App Completeness, che copre crash, contenuti segnaposto, informazioni incomplete e altro."

Perché testare la build di debug non intercetta i problemi della 2.1?

Una build di debug non si comporta come la copia del revisore. Il revisore installa una build di release firmata per la distribuzione su un dispositivo pulito, senza sessione salvata e senza scorciatoie di debug.

Il tuo simulatore ha già effettuato l'accesso. La tua API locale potrebbe puntare a un server di staging che non va mai giù. I flag di debug saltano il paywall e i feature flag sono attivi di default. Il revisore non ha nulla di tutto questo. La pagina di revisione di Apple chiede anche di "testare a fondo su dispositivi con il software più recente", quindi il revisore potrebbe usare una versione di iOS più nuova di quella del tuo telefono di test.

TestFlight è quanto di più vicino ci sia all'ambiente del revisore. Secondo la panoramica di TestFlight, puoi aggiungere fino a 100 tester interni dal tuo team App Store Connect e fino a 10.000 tester esterni. Puoi testare una build per un massimo di 90 giorni. Carica esattamente la build che intendi inviare, installala da TestFlight su un dispositivo che non ha mai eseguito l'app e testa quella copia.

Cosa deve coprire un piano di test della build di release prima del reinvio?

Un piano di test della build di release controlla ogni punto in cui un revisore alle prime armi può bloccarsi: avvio, permessi, login, back end, contenuti, link, acquisti, problemi di rete e iPad. Esegui i passaggi in ordine sulla build TestFlight e annota ogni risultato, così potrai citarlo nelle note per la revisione.

1. Installazione pulita sull'ultima versione di iOS. Elimina qualsiasi copia precedente, installa da TestFlight e avvia senza stato salvato. Esegui tre avvii a freddo e verifica che l'onboarding non vada in crash.
2. Nega una volta ogni richiesta di permesso. Rifiuta notifiche, posizione, fotocamera e tracciamento. L'app deve comunque arrivare a una schermata utilizzabile. Verifica anche che Info.plist contenga una descrizione d'uso per ogni risorsa protetta usata dall'app o dai suoi SDK.
3. Accedi con le credenziali demo esatte. Copiale da App Store Connect, non dal tuo password manager. L'account deve avere dati realistici, non deve richiedere la verifica dell'email e non deve usare l'autenticazione a due fattori legata al tuo telefono.
4. Verifica che il back end sia quello di produzione e sia attivo. La build deve puntare agli endpoint di produzione. Rate limit, allowlist di IP e blocchi geografici non devono escludere un revisore. La linea guida 2.1(a) chiede di attivare il servizio di back end.
5. Percorri ogni tab e ogni schermata. Cerca lorem ipsum, schermate "Prossimamente", stati vuoti senza spiegazione, immagini di test e pulsanti che non fanno nulla.
6. Tocca ogni link. Inclusi privacy policy, supporto, termini e qualsiasi web view. Apple afferma che "un link al supporto utenti con informazioni di contatto aggiornate e un link alla privacy policy sono obbligatori per tutte le app".
7. Apri ogni acquisto in-app. Accedi con un account nuovo. Verifica che ogni prodotto inviato con la versione compaia con un prezzo, sia acquistabile nella sandbox e che Ripristina acquisti funzioni.
8. Testa con una rete lenta o assente. Attiva la modalità aereo a metà di un flusso. Un messaggio di errore chiaro va bene. Uno spinner che gira all'infinito, o un crash, no.
9. Controlla iPad se lo supporti. Se l'app gira su iPad, avviala lì e assicurati che il layout non intrappoli l'utente.

L'account demo del passaggio 3 causa più rifiuti ripetuti di qualsiasi altro passaggio. La nostra guida su come configurare un account demo per la revisione App Store spiega come crearne uno che duri.

Come si collega un messaggio di rifiuto 2.1 a una correzione?

Per collegare un rifiuto 2.1 a una correzione, leggi la frase che segue il numero della linea guida. Indica il sintomo, e ogni sintomo rimanda a un passaggio del piano di test.

Supponiamo che un'app per tracciare le abitudini venga rifiutata con il messaggio "Non è stato possibile revisionare l'app perché è andata in crash all'avvio". Una seconda nota dice che il revisore non è riuscito a trovare gli acquisti in-app. La tabella qui sotto associa i sintomi più comuni a una causa, un test e una correzione.

Per un metodo più generale di lettura di qualsiasi messaggio di rifiuto, vedi Rifiuto App Store: come risolverlo, linea guida per linea guida.

Com'erano i rifiuti 2.1 di altri sviluppatori?

I casi pubblici di 2.1 seguono lo stesso schema. L'app funziona nell'ambiente dello sviluppatore e fallisce per il revisore a causa di qualcosa che solo un'installazione pulita o il login di un estraneo potrebbe far emergere.

• Crash per una descrizione d'uso mancante. Sui forum di Solar2D, a uno sviluppatore è stato comunicato "Non è stato possibile revisionare l'app perché è andata in crash all'avvio" su un iPhone 13 mini con iOS 18.3.2, anche se l'app funzionava in TestFlight. Un altro utente ha trovato nel crash log allegato: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." Lo sviluppatore ha riferito: "È passata dopo aver aggiunto: NSUserTrackingUsageDescription."
• Login social che il revisore non poteva usare. Uno sviluppatore sugli Apple Developer Forums ha segnalato ripetuti rifiuti 2.1 perché i revisori "non sono riusciti a usare i login social". Aveva fornito account demo Apple e Google, ma l'accesso con ID Apple richiedeva un codice di verifica inviato al telefono dello sviluppatore. Lo staff Apple ha risposto che App Review lo avrebbe contattato direttamente. Non è stata pubblicata alcuna soluzione.
• Acquisti in-app che "non è stato possibile trovare nel binario inviato". In un thread della community di RevenueCat, uno sviluppatore è stato rifiutato perché un piano mensile non risultava nel binario, nonostante gli acquisti in sandbox funzionassero. Un utente ha spiegato che un rifiuto simile era stato risolto rispondendo con una guida dettagliata e gli screenshot di ogni percorso verso il paywall. Lo staff di RevenueCat ha consigliato di mostrare ogni prodotto inviato nel paywall predefinito e di tenere i file di test StoreKit fuori dallo scheme di Archive.

In tutti e tre i casi i test dello sviluppatore erano superati. Il problema emergeva solo partendo dalla situazione del revisore: nessun telefono per la 2FA, nessuna sessione precedente e nessuna idea di dove fosse il paywall. È proprio questa situazione che il piano di test qui sopra ricrea.

Cosa scrivere nelle note per App Review dopo un rifiuto 2.1?

Le note per la revisione dopo un rifiuto 2.1 devono fornire credenziali demo funzionanti, elencare cosa è cambiato rispetto alla build rifiutata e indicare esattamente dove trovare gli acquisti in-app e le funzionalità meno evidenti.

La pagina di revisione di Apple chiede di inserire i dati dell'account e le configurazioni speciali nella sezione Informazioni per App Review. Se una funzionalità richiede hardware o un ambiente difficile da configurare, "preparati a fornire un video dimostrativo o l'hardware". La linea guida 2.3.1(a) aggiunge che le nuove funzionalità vanno descritte "in modo specifico" nelle Note per la revisione e che "le descrizioni generiche verranno rifiutate". Una nota breve e strutturata funziona bene:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Se obblighi legali o di sicurezza escludono un account demo, la linea guida 2.1(a) consente una modalità demo integrata, ma solo con previa approvazione di Apple, e tale modalità deve mostrare tutte le funzionalità dell'app. Non passare a una modalità demo senza questa approvazione.

Come reinviare o fare ricorso contro un rifiuto 2.1?

Per reinviare dopo un rifiuto 2.1, carica o seleziona la build che hai testato, rispondi ad App Review in App Store Connect indicando cosa hai cambiato, aggiorna le note per la revisione e invia di nuovo. Fai ricorso solo se ritieni che il revisore abbia frainteso l'app.

1. Verifica che il numero di build associato alla versione in App Store Connect corrisponda alla build TestFlight che hai testato.
2. Rispondi al messaggio di rifiuto con un breve riepilogo di ogni correzione. Per un problema di acquisti o di navigazione, aggiungi istruzioni passo passo e screenshot.
3. Aggiorna la sezione Informazioni per App Review con credenziali e note aggiornate.
4. Invia per la revisione. A ottobre 2026, Apple afferma di esaminare di solito "almeno il 50% degli invii in meno di 24 ore e il 90% in meno di 48 ore".

Se ritieni che Apple abbia sbagliato, la pagina App Review ti permette di fare ricorso all'App Review Board. Fornisci motivazioni specifiche sul perché l'app è conforme e "invia un solo ricorso per ogni invio che non ha superato la revisione". Per un rifiuto 2.1, però, riprodurre il problema su un dispositivo pulito è di solito più rapido che discutere. Se preferisci affidare a qualcun altro il reinvio, il nostro servizio di pubblicazione su App Store copre la preparazione alla revisione e la gestione dei feedback di rifiuto per entrambi gli store a $599, con le quote dell'account sviluppatore escluse.

I problemi della 2.1 si ripresentano spesso negli aggiornamenti successivi: un nuovo feature flag, una chiave API ruotata o un account demo scaduto. Aggiungi questo piano di test alla tua routine di rilascio insieme alla checklist per la pubblicazione su App Store. Per gli aggiornamenti, un rilascio graduale limita il numero di utenti raggiunti da un bug sfuggito. Per un secondo parere su una build rifiutata, scrivi a yagyeshsrbobde@gmail.com allegando il messaggio di rifiuto.