Revisione accelerata App Store: come richiederla ad Apple
Di Mehdi Azizi
Pubblicato il , 9 min
Apple cita due casi: un bug critico sulla versione pubblicata o un'uscita legata a un evento. La procedura, cosa scrivere e cosa succede dopo.
La revisione accelerata esiste, ma Apple la riserva a circostanze eccezionali e ne cita due: correggere un bug critico su una versione già pubblicata, oppure far uscire una versione legata a un evento a cui la tua app è direttamente collegata. Prima invii la versione, poi spieghi l'urgenza nelle note per il reviewer, infine mandi il modulo di richiesta. Apple valuta ogni richiesta e accelera in base alla sua disponibilità: non è mai una garanzia.
Le mie app, Solys, TradaZen e Nolera, sono fatte con Expo. Quando un bug viene dal codice JavaScript, la correzione parte come aggiornamento remoto, senza passare da App Review. Quindi la revisione accelerata mi serve solo per una build nativa, ed è anche la prima domanda da farti prima di richiederla. Questa guida segue la pagina di supporto di Apple sulla revisione accelerata, riletta il 6 novembre 2026.
Cosa cita Apple, e cosa non passa
Apple parla di circostanze eccezionali e chiede di riservare le richieste alle urgenze reali. La sua pagina App Review dà due esempi e cosa fornire per ciascuno. Le tre righe rifiutate della tabella sono la mia lettura di queste pagine, non un elenco di Apple.
| Motivo | Per Apple | Cosa fornire, o cosa capire |
|---|---|---|
| Bug critico sulla versione pubblicata | Citato come esempio | Passaggi per riprodurlo, versione attuale |
| Uscita legata a un evento | Citato come esempio | L'evento, la sua data, il legame tra la tua app e l'evento |
| Prima pubblicazione in ritardo | No, secondo me | Niente la rende urgente agli occhi di Apple |
| Data di marketing senza evento | No, secondo me | Una campagna non è un evento legato all'app |
| Attesa più lunga del solito | No, secondo me | Un tempo normale non è un'urgenza |
Apple non definisce il termine. In pratica, un bug critico è un'app che crasha, che blocca una funzione essenziale o che impedisce di pagare, per utenti reali, sulla versione pubblicata. Un refuso in una schermata non lo è. E se la tua app è ancora in revisione mentre si avvicina un evento, Apple precisa che puoi chiedere l'accelerazione anche per questo motivo.
La procedura in tre passaggi
- Invia la versione in App Store Connect. Si può accelerare solo un invio già fatto. Se alcune funzioni richiedono il login, inserisci un account demo nella sezione App Review Information.
- Compila il campo Notes al momento dell'invio. Per un bug critico, descrivi il bug corretto e come riprodurlo sulla versione attuale. Per un evento, indica nome, data e cosa lega la tua app all'evento.
- Invia il modulo Request an Expedited App Review, raggiungibile dalla pagina di supporto di Apple dopo il login al tuo account sviluppatore. Lì scegli l'app e la piattaforma interessate, poi invii.
Apple valuta la richiesta e ti risponde, poi segui l'invio in App Store Connect. Se la richiesta viene accettata, la versione passa in In Review prima di quanto avrebbe fatto seguendo la coda. Se viene rifiutata, la revisione segue il suo corso normale: non perdi niente.
Il pulsante Reply to App Review, in App Store Connect, non serve a chiedere una revisione accelerata. La pagina di contatto di App Review lo riserva alle comunicazioni su un invio in corso; la richiesta accelerata e il ricorso hanno ciascuno il proprio modulo.
Cosa scrivere: due modelli
App Review legge in inglese. Ecco i due testi che tengo pronti, da adattare nelle Notes, e nel modulo se ti lascia un campo libero. Stanno in cinque righe perché un reviewer deve capire l'urgenza senza aprire l'app.
Bug critico sulla versione pubblicata:
Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.
Uscita legata a un evento:
This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.
Questi due testi sono esempi, non richieste che ho inviato davvero. Due regole per i tuoi. Fatti verificabili: versione, sistema, passaggi, data, legame con l'evento. Nient'altro che l'urgenza: se la tua build contiene anche una nuova funzione, dillo in una frase, ma non difenderla.
Prima di chiederla, verifica di averne bisogno
Apple chiede di riservarla alle urgenze reali. Tre domande, e una trappola, prima di inviare il modulo.
La correzione può passare senza revisione? Con Expo, un aggiornamento remoto sostituisce il codice JavaScript delle app già installate senza una nuova build. È la strada che uso per le mie correzioni. Non copre però il codice nativo, i permessi né le dipendenze native: per questi servono una build e una revisione. E il contenuto deve restare nei limiti di ciò che Apple ha approvato, come ricorda la presentazione di EAS Update: un aggiornamento remoto non cambia lo scopo dell'app. La guida sul rilascio graduale di un aggiornamento iOS spiega nel dettaglio cosa passa da dove.
L'attesa è anomala? Apple dice di esaminare in genere almeno il 50% degli invii in meno di 24 ore e il 90% in meno di 48 ore. Se la tua versione è in attesa di revisione da un giorno, sei nella norma dei tempi di approvazione dell'App Store. La pagina sullo stato di un invio ricorda anche cosa allunga una revisione: prima app senza storico, documenti da verificare, settore regolamentato.
L'invio è completo? Una revisione accelerata su un invio incompleto non accelera nulla. Apple avverte che un invio incompleto ritarda la revisione o non va a buon fine. Account demo, note, documenti: deve esserci tutto prima del modulo.
E soprattutto, non ritirare la versione per inviarla di nuovo. Una versione ritirata esce dalla coda e riparte da zero. Se Apple ti fa una domanda durante la revisione, rispondi in App Store Connect invece di reinviare, come spiega la guida su come rispondere ad App Review nel Resolution Center.
Se Apple rifiuta l'accelerazione
Mantieni il tuo posto in coda: un rifiuto dell'accelerazione non cambia niente nella revisione in corso. Per non rivivere la stessa situazione:
- Programma le uscite. Per un evento, Apple consiglia di scegliere la pubblicazione programmata in App Store Connect: la versione viene revisionata in anticipo ed esce alla data che vuoi. L'opzione di rilascio di una versione si imposta nella pagina della versione, nella sezione App Store Version Release.
- Invia presto. Una versione pronta una settimana prima dell'evento lascia il tempo per una revisione normale, e perfino per correggere un rifiuto.
- Tieni un canale senza revisione per il JavaScript. Con Expo, è quello che trasforma un bug critico in una correzione di pochi minuti.
I miei modelli di note per il reviewer, la mia checklist prima dell'invio e le risposte ai rifiuti più frequenti sono raccolti nel Review Kit. E se vuoi sapere cosa manca al tuo invio prima di farlo, il diagnostico gratuito te lo dice e ti manda la mia checklist anti-rifiuto Apple. Tutti i passaggi della pubblicazione sono in pubblicare un'app sull'App Store.
Domande frequenti
Quanto dura una revisione accelerata dell'App Store?
Apple non indica alcun tempo. Dice di valutare ogni richiesta e di accelerare la revisione in base alla sua disponibilità e alla domanda del momento. Una richiesta accettata fa passare la versione in In Review prima del suo turno, senza promettere un orario.
Si può chiedere una revisione accelerata per una prima app?
Niente lo vieta, ma Apple riserva l'accelerazione alle urgenze reali e cita due esempi: un bug critico su una versione già pubblicata, o un'uscita legata a un evento con una data precisa. Una prima pubblicazione in ritardo sulla tua tabella di marcia, secondo me, non rientra in nessuno dei due.
Quante volte si può chiedere una revisione accelerata?
Apple non pubblica un numero. Chiede di riservare le richieste alle urgenze reali. Secondo me, ogni richiesta senza un vero motivo rende la successiva meno credibile: tienila per un bug che colpisce i tuoi utenti.
Bisogna ritirare l'invio prima di chiedere l'accelerazione?
No, è il contrario. Si può accelerare solo un invio già fatto, e una versione ritirata perde il suo posto in coda. Invia, compila le Notes, poi manda il modulo.
Dove si trova il modulo per la revisione accelerata?
Sul sito sviluppatori di Apple, dopo il login al tuo account: la pagina di supporto sulla revisione accelerata ci porta tramite il link Request an Expedited App Review. Lì scegli l'app e la piattaforma interessate.
Una revisione accelerata garantisce che l'app venga accettata?
No. Cambia solo la posizione in coda. La versione deve rispettare le App Review Guidelines come qualsiasi altra, e un rifiuto resta possibile.
Si può correggere un bug senza passare da App Review?
Con Expo o React Native, un aggiornamento remoto sostituisce il codice JavaScript senza nuova build né revisione. Il codice nativo, i permessi e le dipendenze native richiedono sempre una build inviata ad Apple.

