Tempi di revisione App Store: quanto bisogna aspettare

I tempi di revisione dell'App Store sono brevi, almeno sulla carta: Apple dichiara di esaminare almeno il 50% delle richieste in meno di 24 ore e il 90% in meno di 48 ore. Il dato viene dalla pagina ufficiale di App Review. Se la tua app passa al primo colpo, puoi aspettarti una risposta in circa un giorno.

I tempi reali, però, si contano in un altro modo: è il tempo tra il tuo primo invio e il momento in cui l'app è in vendita. E a farli esplodere non è quasi mai l'attesa in coda, sono i rifiuti. Ogni rifiuto fa ripartire un ciclo completo: leggere il motivo, correggere, reinviare, aspettare di nuovo, anche per un rifiuto automatico all'invio come ITMS-90338. Questa guida spiega cosa allunga i tempi, come gestire un rifiuto senza perdere giorni e quali motivi colpiscono più spesso una prima app.

Ne parlo partendo dai miei invii. Le mie app iOS, tra cui Solys (una sveglia con minigiochi) e TradaZen (un simulatore di trading), sono sull'App Store, e lungo la strada ho preso diversi rifiuti, su Solys come su altre due app, Clic e Nolera. Trovi i motivi nel dettaglio più sotto.

Tempi di revisione App Store: cosa dichiara davvero Apple

Una volta inviata la build, senza errori automatici come ITMS-90725, e completata la scheda, la mandi in revisione da App Store Connect. La tua richiesta passa allora per diversi stati: in attesa (Waiting for Review), in revisione (In Review), poi accettata o rifiutata. Apple ti avvisa via e-mail a ogni cambio di stato, e puoi seguire l'avanzamento in App Store Connect o nella sua app per iPhone.

Tre precisazioni ufficiali utili per pianificare:

• Questi numeri sono tendenze, non una garanzia: fino a una richiesta su dieci aspetta più di 48 ore.
• Le richieste non vengono per forza esaminate nell'ordine di invio, precisa la guida di App Store Connect.
• Può essere in revisione una sola versione dell'app per piattaforma. Non puoi accodare più versioni per "guadagnare tempo".

Una volta accettata l'app, puoi scegliere di pubblicarla automaticamente o di rilasciarla tu. La seconda opzione è preziosa: prima fai approvare l'app, poi fissi la data di lancio quando hai il via libera.

Cosa allunga l'attesa

I tempi si allungano raramente per colpa di Apple. Si allungano quasi sempre per colpa di quello che le mandiamo.

Il primo invio

Per una primissima versione, Apple esamina tutto in un colpo solo: la scheda, gli screenshot, la classificazione per età, la privacy policy, le dichiarazioni sulla raccolta dei dati, gli abbonamenti e l'app stessa. Ogni elemento è un'occasione di rifiuto. Non è la coda a essere più lunga, è la superficie a essere più ampia. Se non hai mai pubblicato, i passaggi da preparare sono elencati in pubblicare un'app sull'App Store.

Abbonamenti e acquisti in-app

Se la tua app vende un abbonamento, due regole cambiano il tuo calendario:

1. Il tuo primo abbonamento va inviato insieme a una nuova versione dell'app. È scritto nero su bianco nella guida sugli acquisti in-app. Se l'app parte senza, servirà una nuova versione per farlo approvare.
2. Tutti gli elementi di una richiesta devono essere accettati perché lo sia la richiesta. Un abbonamento rifiutato blocca tutto.

La regola 2.1(b) chiede anche che gli acquisti in-app siano completi, visibili al reviewer e funzionanti. Se uno di questi non compare nell'app, spiega il perché nelle note di revisione. La configurazione completa di un abbonamento è spiegata in abbonamenti in-app iOS.

L'account demo mancante

Se la tua app richiede un login, le App Review Guidelines esigono un account demo attivo o una modalità demo completa, e servizi server accesi durante la revisione. Senza credenziali nella sezione App Review Information della tua versione, il reviewer resta bloccato alla schermata di login, ed è un rifiuto. Ricordati anche di non spegnere il server di test durante la revisione.

I rifiuti stessi

È il primo fattore, di gran lunga. Apple indica che oltre il 40% dei problemi irrisolti riguarda la regola 2.1, quella che copre crash, contenuti segnaposto e informazioni incomplete. Un rifiuto evitato è almeno un ciclo guadagnato.

Rispondere nel Resolution Center

Quando una richiesta viene rifiutata, il suo stato passa a Unresolved Issues. Il messaggio di Apple cita la regola violata, spesso con uno screenshot del problema. Tutto avviene nella sezione App Review della tua app in App Store Connect, che molti chiamano ancora Resolution Center.

La procedura ufficiale per rispondere ad App Review:

1. Nella tua app, clicca sul link dei problemi irrisolti in cima alla pagina.
2. Clicca su Resolve accanto alla richiesta.
3. Clicca su Reply to App Review, scrivi la risposta (massimo 4.000 caratteri) e allega, se serve, uno screenshot o un documento.

Cosa rende efficace una risposta:

• Descrivi la correzione, non come ti senti. "La richiesta di valutazione ora compare dopo la demo vinta, screenshot allegato" funziona meglio di una lunga arringa.
• Allega una prova. Uno screenshot o un breve video della schermata corretta evita un botta e risposta di domande.
• Se il rifiuto riguarda solo i metadati (testo della scheda, screenshot, link, come un rifiuto 2.3.10), Apple precisa che puoi reinviare la stessa build dopo la correzione. Non serve ricompilare.

Fare ricorso, solo se sei sicuro

Puoi contestare un rifiuto davanti all'App Review Board. Apple chiede di spiegare con precisione perché l'app rispetta le regole, di fare un solo ricorso per ogni richiesta rifiutata e di rispondere prima alle richieste di informazioni in sospeso. Un ricorso su un rifiuto meritato non fa che allungare l'attesa.

Inviare una correzione in fretta

Quando il motivo è chiaro, la velocità viene dalla disciplina:

• Correggi il motivo, e solo quello. Infilare tre novità nella build corretta significa riaprire la superficie di revisione.
• Testa la correzione nelle condizioni del reviewer. Per un problema di visualizzazione, vuol dire sull'iPhone più piccolo supportato e su quello più grande, non solo sul tuo.
• Occhio agli elementi rimossi. In una richiesta con problemi irrisolti, la guida di Apple precisa che un elemento rimosso non può essere riaggiunto alla stessa richiesta, e che ogni elemento si può modificare una sola volta prima del reinvio. Pensaci bene prima di eliminare un abbonamento rifiutato.
• Reinvia, poi rispondi. Una o due frasi concrete nella risposta per dire cosa è cambiato.

E la revisione accelerata? Esiste, ma Apple la riserva a due casi: la correzione di un bug critico su una versione già pubblicata, con i passaggi per riprodurlo, e le app legate a un evento con una data precisa. Non è una scorciatoia per una prima pubblicazione in ritardo.

I rifiuti più frequenti per chi inizia

Ho già raccontato nel dettaglio i miei due rifiuti su Solys in perché Apple rifiuta un'app. Ecco i motivi che ho preso davvero, con il numero della regola, perché sono proprio quelli che minacciano una prima app.

2.1, l'app non funziona (Solys). La demo iniziale di Solys era impossibile da vincere su uno schermo di iPhone piccolo: un passaggio obbligatorio insuperabile, quindi un'app giudicata incompleta. Ora è corretta.

5.6.3, la richiesta di valutazione troppo presto (Solys). La valutazione sull'App Store veniva chiesta all'inizio dell'onboarding, prima che la persona avesse vissuto qualcosa nell'app. Deve arrivare dopo un vero momento di valore.

5.1.1, la privacy policy non aggiornata (Clic). La regola 5.1.1 richiede un link alla privacy policy in App Store Connect e nell'app, e questa policy deve descrivere con precisione i dati raccolti, come vengono usati e come eliminarli. Su Clic, la versione online non era aggiornata. Una policy che non segue il tuo prodotto basta a far rifiutare la richiesta.

5.1.1, il pulsante "Allow" prima della richiesta di sistema (Nolera). Nolera mostrava una schermata di spiegazione prima della richiesta di accesso alla fotocamera, con un pulsante "Allow". Le Human Interface Guidelines sulla privacy sono chiare: una schermata prima dell'avviso di sistema è consentita, ma il suo pulsante non deve riprendere "Allow" o un termine simile, perché a quel punto non si sta autorizzando nulla. Apple consiglia "Continue" o "Next".

2.3.2, l'icona riusata come immagine promozionale dell'abbonamento (Nolera). La regola 2.3.2 disciplina la promozione degli acquisti in-app sull'App Store: nome, immagine e descrizione devono essere adeguati. Su Nolera, l'immagine promozionale dell'abbonamento riprendeva semplicemente l'icona dell'app. Serve un'immagine specifica per l'acquisto.

Cosa lega questi cinque rifiuti: nessuno era un problema di codice complesso. Si vedevano tutti rileggendo il materiale con gli occhi di un reviewer. Se la tua app è appena stata rifiutata e il motivo resta poco chiaro, il percorso completo è in app rifiutata da Apple.

Mettere in conto i tempi nella tua pianificazione

Qualche regola semplice perché la revisione non faccia slittare il lancio:

• Non annunciare una data prima dell'approvazione. Fai approvare l'app, scegli la pubblicazione manuale, poi fissa la data.
• Tieni un margine di almeno un ciclo di rifiuto se è il tuo primo invio o il tuo primo abbonamento.
• Apri presto l'account sviluppatore se passi da una società: il numero D-U-N-S da solo può richiedere più di una settimana. Trovi tutto nella guida all'account sviluppatore Apple.
• Rileggi il materiale come un reviewer: account demo, privacy policy aggiornata, privacy manifest completo, schermate dei permessi, immagini degli abbonamenti e ogni schermata obbligatoria su iPhone piccolo e grande.

Se vuoi far rileggere il tuo materiale prima dell'invio

L'Apple Review Kit raccoglie la mia checklist pre-invio, i miei rifiuti di Apple corretti e delle skill di Claude Code che rileggono il tuo progetto, il paywall e la scheda. Non garantisce l'approvazione, decide Apple, ma ti aiuta a beccare i motivi elencati sopra prima che ti costino un ciclo.

Stai preparando il tuo primo invio? La diagnosi gratuita ti manda la mia checklist anti-rifiuto Apple e ti dice cosa resta da fare. Se la tua app è già bloccata, prenota un'ora con me: leggiamo insieme il messaggio di Apple, in videochiamata. E se la stai ancora costruendo, la home mostra come creare la tua app mobile pensando alla revisione fin dall'inizio.

Domande frequenti

Quali sono i tempi di revisione di un'app sull'App Store?

Apple dichiara di esaminare almeno il 50% delle richieste in meno di 24 ore e il 90% in meno di 48 ore. Non è una garanzia: alcune richiedono più tempo, e non vengono per forza esaminate nell'ordine di invio. I tempi reali sono quelli tra il tuo primo invio e la messa in vendita, e si allungano soprattutto per colpa dei rifiuti.

Cosa allunga i tempi di revisione di un'app?

I rifiuti, di gran lunga: ognuno fa ripartire un ciclo completo (leggere il motivo, correggere, reinviare, aspettare di nuovo). Apple indica che oltre il 40% dei problemi irrisolti riguarda la regola 2.1, quella su crash, contenuti segnaposto e informazioni incomplete. Anche un primo invio moltiplica le occasioni di rifiuto, perché Apple esamina tutto in un colpo solo.

Come rispondere a un rifiuto dell'App Store?

Nella sezione App Review della tua app, apri i problemi irrisolti, clicca su Resolve e poi su Reply to App Review. Scrivi la risposta (massimo 4.000 caratteri), descrivi la correzione invece di come ti senti e allega uno screenshot o un breve video. Se il rifiuto riguarda solo i metadati, puoi reinviare la stessa build dopo la correzione. Se il motivo resta poco chiaro, leggi app rifiutata da Apple.

Si può chiedere ad Apple una revisione accelerata?

Sì, la revisione accelerata esiste, ma Apple la riserva a due casi: la correzione di un bug critico su una versione già pubblicata, con i passaggi per riprodurlo, e le app legate a un evento con una data precisa. Non è una scorciatoia per una prima pubblicazione in ritardo.

Il primo abbonamento va inviato insieme all'app?

Sì, secondo la guida di Apple: il tuo primo abbonamento va inviato insieme a una nuova versione dell'app. Se l'app parte senza, servirà una nuova versione per farlo approvare. Perché la richiesta venga accettata, devono esserlo tutti i suoi elementi: un abbonamento rifiutato blocca tutto.

Quando annunciare la data di lancio della propria app?

Non prima che Apple abbia approvato l'app. Scegli la pubblicazione manuale: prima fai approvare l'app, poi fissi la data di lancio quando hai il via libera. Se è il tuo primo invio o il tuo primo abbonamento, tieni anche un margine di almeno un ciclo di rifiuto.