Quanto dura davvero la revisione di Google Play nel 2026?

Ogni fase di un lancio su Google Play ha il proprio orologio, e confonderli è il modo in cui un piano di lancio slitta di settimane senza che te ne accorga. Questo articolo percorre la pipeline 2026 fase per fase: i numeri che Google dichiara davvero, le fasi senza tempi promessi, l’unica finestra che è compito tuo e non di Google, e cosa deve essere completo prima di ogni passo successivo. È aggiornato al 16 ottobre 2026; dove un numero conta, usiamo la formulazione di Google invece delle ipotesi dei forum. Per la sequenza completa di lancio intorno a questi orologi, vedi la nostra guida passo dopo passo ai requisiti di pubblicazione su Google Play.

Quanto dura la revisione di Google Play nel 2026?

Dipende da quale revisione stai aspettando, e nessuna revisione ha una data di completamento promessa. Le build del test interno di solito sono disponibili in pochi minuti. Google dice che le revisioni delle app vengono in genere completate entro 7 giorni, ma potrebbero richiedere più tempo, e queste indicazioni generali valgono anche per la tua prima release del test chiuso, perché Google non pubblica un calendario separato. La revisione dell’accesso in produzione in genere richiede al massimo 7 giorni, secondo le parole di Google. I famosi 14 giorni stanno tra queste revisioni e non sono affatto una revisione.

«Tempo di revisione di Google Play» sono, in pratica, cinque orologi diversi, e ognuno si comporta a modo suo. Ecco l’intero pipeline 2026 in un solo quadro, con chi tiene ogni orologio e cosa Google dichiara davvero:

1. 01
   Versione di test interno Minuti, in genere

   Le build di solito sono disponibili per i tester interni in pochi minuti, anche se la prima release può essere esaminata e il link di test può richiedere diverse ore per funzionare dopo la prima pubblicazione.

2. 02
   Prima release del test chiuso In genere entro 7 giorni

   Google esamina la release prima che i tester possano partecipare. Non pubblica un calendario separato per questa revisione, quindi usa le sue indicazioni generali: in genere entro 7 giorni, a volte di più. Questi giorni non contano per il requisito di 14 giorni.

3. 03
   Il test chiuso di 14 giorni 14 giorni, il tuo orologio

   Non è revisione. È una finestra di test che gestisci tu: i tester restano attivati e usano davvero l’app. Non la accorci; eviti solo di azzerarla.

4. 04
   Revisione accesso alla produzione In genere al massimo 7 giorni

   Formulazione di Google stessa. Richiedi con un modulo in tre parti dopo la finestra; la decisione va via email al titolare dell’account.

5. 05
   Versione finale + update successivi Senza termine fisso

   Secondo le indicazioni generali di Google, le revisioni vengono in genere completate entro 7 giorni ma potrebbero richiedere più tempo, senza un massimo fisso. Non inviare mai all’ultimo minuto una release legata a una scadenza.

Nota lo schema: Google tiene quattro dei cinque orologi, e l’unico che è tuo, il test di 14 giorni, è anche quello che la maggior parte dei lanci rovina. Il comportamento di revisione dipende anche dal canale su cui pubblichi; se stai ancora scegliendo tra i canali, il nostro confronto test interno vs chiuso vs aperto mappa i tre prima di impegnarti.

Revisione della prima app: cosa aspettarti?

La tua prima app affronta più momenti di revisione di qualsiasi app che pubblicherai in seguito. La verifica dell’identità arriva per prima; segui le istruzioni che Google dà al tuo account, perché Google non pubblica una durata unica per questa fase. Poi la tua prima release del test chiuso viene esaminata prima che i tester possano partecipare, e secondo le indicazioni generali di Google le revisioni vengono in genere completate entro 7 giorni, ma potrebbero richiedere più tempo. Solo dopo il test di 14 giorni arrivi alla revisione dell’accesso in produzione. Al primo lancio, pianifica sul lato lento di ogni intervallo.

Un primo invio non viene esaminato una sola volta: passa da una catena di controlli, ognuno con il proprio orologio. Prima che qualsiasi cosa possa essere pubblicata, Google verifica la tua identità. Il tuo primo caricamento su un canale chiuso viene poi esaminato prima che i tester possano partecipare. Dopo la finestra di test, la richiesta di accesso in produzione e la release di produzione restano ancora tra te e lo store. Nessuno di questi passaggi è facoltativo per un nuovo account personale. Alcuni possono sovrapporsi: una correzione che invii durante il test chiuso può essere esaminata mentre i tuoi tester restano attivati.

La conseguenza pratica: al primo lancio, il tempo di revisione si perde soprattutto ai bordi, prima che il test parta e dopo che finisce. Chi pianifica solo “i 14 giorni” scopre che le revisioni intorno aggiungono attese proprie. La buona notizia è che il lavoro intorno alle revisioni può sovrapporsi: puoi completare la scheda dello store, le dichiarazioni e gli screenshot mentre una revisione è in corso, e Google incoraggia a iniziare subito la verifica dell’identità.

Quanto durano le revisioni sul canale di test chiuso?

La tua prima release del test chiuso viene esaminata prima che i tester possano partecipare, e Google non pubblica un calendario separato per questa revisione. Usa le indicazioni generali di Google: le revisioni vengono in genere completate entro 7 giorni, ma potrebbero richiedere più tempo. Le build successive sullo stesso canale seguono lo stesso flusso di revisione, senza tempi promessi. I giorni di revisione prima che i tester possano attivare il test non contano per il requisito di 14 giorni: quell’orologio parte solo dopo che la release è disponibile sul canale chiuso e i tuoi tester attivano davvero il test.

Il test chiuso è dove la maggior parte dei lanci del 2026 spende il calendario, perché i nuovi account sviluppatore personali devono eseguire un test chiuso con almeno 12 tester attivati per 14 giorni consecutivi prima di richiedere l’accesso alla produzione. Se vuoi lo sfondo di quel requisito, incluso come il minimo è passato da 20 a 12, vedi il nostro post sul cambio di policy dell’11 dicembre 2024. Questo post risponde a una domanda più stretta: quanto durano le revisioni intorno a quel test.

La trappola è la prima release. Il test interno abitua gli sviluppatori ad aspettarsi build disponibili in pochi minuti; la prima release su un canale chiuso viene prima esaminata, e le indicazioni generali di Google per questo parlano di un tempo in genere entro 7 giorni, a volte di più. Un’attesa silenziosa non prova che qualcosa non vada, ma controlla che la release sia stata davvero inviata per la revisione. Se hai convocato i tester per “domani”, ora aspettano Google insieme a te, e la tua finestra di 14 giorni non si è ancora aperta. Gli orologi si alternano così:

I build aggiornati che invii al canale durante il test passano dal flusso normale di revisione di Google. Google non pubblica un termine fisso per essi, quindi tratta ogni build a metà test come «spesso rapido, non istantaneo» e non pianificare mai un ciclo di fix e verifica lo stesso giorno intorno a uno di essi.

La finestra di test di 14 giorni non è una coda di revisione

I 14 giorni sono una finestra di test, non una coda di revisione. I tuoi tester restano attivati e usano davvero l’app per almeno 14 giorni continuativi. Una correzione che invii durante la finestra può essere esaminata mentre i tester restano attivati, ma la finestra in sé non è una revisione, e l’accesso in produzione viene esaminato solo dopo la richiesta. Aspettare in silenzio non la fa avanzare; tenere attivi i tester sì.

Questa distinzione cambia come usi le due settimane. Una coda di revisione premia la pazienza: invii, aspetti, decide qualcun altro. La finestra di 14 giorni premia l’operatività: ogni giorno l’app ha bisogno di tester attivati e attivi, e il requisito si misura in modo continuo. Scendere sotto il conteggio minimo a metà finestra spezza la sequenza continua; l’attesa può ripartire con un nuovo gruppo. Nessun revisore avvisa che sta succedendo, perché nessun revisore sta ancora guardando.

Significa anche che la finestra non può essere accelerata, negoziata o accorciata dalla qualità dell’app. Un’app impeccabile deve gli stessi 14 giorni di una bozza. L’unica prestazione sotto il tuo controllo è non perdere giorni: reclutare tester che restano, rimpiazzare le uscite al volo e non confondere il conteggio di attivazione in Console con l’uso quotidiano reale. Come si contano i 14 giorni, cosa azzera davvero l’orologio e cosa succede quando un tester esce il giorno 9 è un tema a sé; la nostra guida ai 14 giorni consecutivi copre tutta la meccanica dell’orologio.

Revisione accesso alla produzione: in genere al massimo 7 giorni

Questa è la revisione con tempi propri dichiarati. Dopo che il test chiuso soddisfa i requisiti, richiedi l’accesso in produzione con un questionario in tre sezioni. Google esamina la richiesta dopo che l’hai inviata, in genere in 7 giorni o meno, anche se a volte può essere necessario più tempo. La decisione arriva al titolare dell’account.

La formulazione stessa di Google, nella pagina di aiuto della Play Console che definisce il requisito di test, merita di essere letta con precisione:

Ciò che viene esaminato è più ampio di quanto la maggior parte di chi richiede si aspetti. Google guarda il test chiuso in sé, cioè l’attività dei tester e non solo il conteggio di chi è attivato, l’app e le risposte scritte sulla prontezza per la produzione. Raggiungere 12 tester attivati è necessario, non sufficiente: le richieste sono già state rifiutate quando l’engagement era troppo basso, e risposte vaghe nel modulo sono un motivo comune di rifiuto. Le tre parti premiano dettagli concreti, esattamente ciò che il nostro post sulle risposte al modulo di accesso alla produzione percorre domanda per domanda.

Mentre la revisione gira, tre abitudini ti tengono fuori dai guai: tieni i tester attivati finché non hai la risposta di Google in mano, controlla la casella email del titolare dell’account, spam incluso, perché è quell’indirizzo che riceve la decisione, e resisti a cambiare la versione in revisione a meno che qualcosa non sia davvero rotto. La richiesta è uno scatto di un test stabile e concluso; falla sembrare tale.

Quanto durano le revisioni degli update dell’app?

Google non promette un tempo di revisione fisso per gli aggiornamenti. Secondo le sue indicazioni generali, le revisioni vengono in genere completate entro 7 giorni, ma in casi eccezionali potrebbero richiedere più tempo. Gli aggiornamenti di un’app che ha già l’accesso in produzione seguono la normale procedura di aggiornamento; non richiedono un nuovo test chiuso con 12 tester.

Due scenari di update si confondono sempre, e hanno orologi diversi:

Aggiornamenti dopo l’accesso in produzione. Il requisito di test si soddisfa una volta per app, quindi un aggiornamento di routine di un’app online segue la normale procedura di aggiornamento, non un nuovo test di 14 giorni. Passa però dalla revisione standard delle release di Google, quella senza tempi promessi. In pratica, i tempi degli aggiornamenti diventano una questione di pianificazione, non di norme: se una release conta per una data, una campagna di marketing o una correzione con utenti in attesa, inviala con giorni di anticipo, non ore, perché “spesso rapido” non è “sempre rapido”.

Update durante il test chiuso. Inviare un build migliore a metà test è normale, incoraggiato e sicuro per il calendario: aggiornare l’app durante il test chiuso non azzera l’orologio di 14 giorni. Il build nuovo passa comunque dalla revisione normale prima che i tester lo ricevano, quindi un update a metà test mette in pausa un po’ il loop di feedback, ma mai la finestra.

Cosa rallenta una revisione (e cosa non acceleri)

Controlla se c’è un’azione richiesta prima di dare per scontato che l’app stia solo aspettando in coda. Dichiarazioni incomplete, un login che il revisore non riesce a superare, permessi sensibili o una storia di test debole possono ciascuno aggiungere tempo o forzare un secondo passaggio. Cosa non esiste: una corsia preferenziale a pagamento. Google non documenta alcuna opzione di priorità per le revisioni standard.

Non vedi dentro la coda di revisione di Google, ma controlli la maggior parte di ciò che fa un invio uscire lento o tornare per un altro ciclo:

E la parte che non controlli: Google non documenta corsie preferenziali a pagamento né richieste di priorità per le revisioni standard. L’assistenza della Play Console può verificare un invio e, in alcuni casi, fare escalation, ma una verifica non è la promessa di una decisione più rapida. Chi promette di accelerare il lato di Google del processo promette qualcosa che Google non vende. La tua leva sta nella preparazione, ed è per questo che i lanci più fluidi sono quelli che non vedono mai un secondo ciclo di revisione.

La tua app è bloccata in revisione? Quando agire

Il solo tempo trascorso non ti dice se una revisione è bloccata. Google dice che le revisioni vengono in genere completate entro 7 giorni, ma potrebbero richiedere più tempo. In qualsiasi momento, controlla che l’ultima modifica sia stata davvero inviata per la revisione e cerca un’azione richiesta nella Play Console e nell’e-mail del titolare dell’account, spam incluso. Contatta l’assistenza tramite il Centro assistenza Play Console quando l’attesa ha chiaramente superato le indicazioni abituali di Google.

Una revisione “bloccata” può rivelarsi una revisione ancora entro la sua fascia normale, una release che non è mai stata davvero inviata, o una decisione già arrivata in una casella che nessuno ha controllato. Passa la tua situazione dal verificatore prima di pensare al peggio:

Qualunque cosa dica il verificatore, il percorso di escalation è lo stesso in quattro mosse, in quest’ordine:

1. 1
   Conferma che sia davvero in revisione

   Apri la Publishing overview nella Play Console. Una release salvata come bozza, o modifiche mai inviate per la revisione, non vengono esaminate. Poi apri Submission activity e annota l’ID dell’ultimo invio e la sua cronologia degli stati; quel registro è più affidabile di una data di caricamento che ricordi a memoria.

2. 2
   Controlla l’email del titolare dell’account, spam incluso

   Google invia le decisioni via e-mail al titolare dell’account, non necessariamente all’indirizzo che controlli ogni giorno, quindi controlla anche le notifiche della Play Console. Un rifiuto di una settimana fa finito nello spam, dall’interno della Console, sembra esattamente una revisione bloccata.

3. 3
   Agisci subito su una modifica richiesta; altrimenti concedi alla revisione la sua finestra abituale

   Se Google chiede una correzione, falla subito invece di aspettare. Se non viene richiesto nulla, una revisione entro le indicazioni abituali di Google si sta comportando come documentato, e caricare altre build per smuoverla può rallentarla. Segna il giorno in cui la finestra abituale scade e agisci allora.

4. 4
   Contatta il supporto della Play Console

   Passata la finestra abituale, con un invio confermato e nessuna richiesta, contatta l’assistenza tramite il Centro assistenza Play Console e includi l’ID dell’invio, gli orari e il tuo fuso orario. Prosegui ogni contatto successivo nella stessa richiesta. Se la risposta che alla fine arriva è un rifiuto, parti da perché il test chiuso viene rifiutato prima di reinviare.

Bloccata in revisione da 12 giorni o più

Controlla l’ultimo invio e il suo stato prima di decidere cosa fare. Dodici giorni non sono una soglia di escalation di Google; sono semplicemente ben oltre le indicazioni abituali di Google, quindi parti dallo stato che vedi davvero:

1. 1
   Modifiche non inviate per la revisione

   Controlla la Publishing overview: le modifiche sono state davvero inviate? Completa la configurazione richiesta e inviale per la revisione. L’ora del caricamento non è l’ora dell’invio.

2. 2
   In revisione

   Controlla Submission activity, le notifiche della Play Console e l’e-mail del titolare dell’account. Risolvi l’eventuale problema richiesto; altrimenti conserva la cronologia e contatta l’assistenza tramite il Centro assistenza Play Console. Lo stato non ti dà una data di decisione promessa.

3. 3
   Pronta per la pubblicazione

   Con la pubblicazione gestita attiva, le modifiche approvate aspettano te. Pubblicale quando sei pronto; l’approvazione da sola non porta la release davanti agli utenti.

4. 4
   Rifiutata, o azione richiesta

   Leggi il messaggio di decisione dell’invio interessato. Risolvi il problema indicato e invia una release corretta, oppure usa la procedura di ricorso indicata nel messaggio. Aprire altri ticket di assistenza non sostituisce un invio corretto.

5. 5
   Più test richiesti

   Leggi il feedback sul coinvolgimento dei tester e sulla prontezza per la produzione, migliora l’app e il test, poi ripresenta la richiesta come indicato. Come ripresentare la richiesta dopo una risposta che chiede più test.

6. 6
   Non riesci proprio ad aprire la Play Console

   Usa il modulo di contatto di Google per l’accesso all’account. È pensato per gli account che non riesci ad aprire, non per una coda di revisione su un account a cui accedi.

Perché la produzione risulta ancora inattiva?

L’accesso in produzione e una release di produzione pubblicata sono passaggi separati. Le pagine di Google sugli stati non definiscono un’etichetta di produzione “inattiva”, quindi controlla quale di questi quattro casi si applica:

• Accesso non ancora concesso. Non hai presentato la richiesta, oppure la richiesta è ancora in revisione. Controlla nella Dashboard la tua idoneità e lo stato della richiesta.
• Accesso concesso, ma nessuna release di produzione. L’accesso ti permette di pubblicare; non crea una release. Crea una release di produzione e inviala per la revisione.
• Release inviata. La release di produzione è in revisione. Seguila in Submission activity.
• Approvata, in attesa di te. Con la pubblicazione gestita attiva, le modifiche approvate aspettano finché non le pubblichi.

Dal primo invio all’online: un calendario realistico

La tua prossima tappa dipende dalla fase effettivamente completata, quindi non esiste un totale unico e onesto. Google indica i tempi delle revisioni, non di un intero lancio: le revisioni delle app vengono in genere completate entro 7 giorni ma potrebbero richiedere più tempo, il test chiuso richiede almeno 12 tester attivati continuamente per almeno 14 giorni, e la revisione dell’accesso in produzione in genere richiede al massimo 7 giorni dopo la richiesta. Le fasi possono sovrapporsi, e un rifiuto allunga il totale.

Google pubblica i tempi delle singole revisioni, non di un lancio. La verifica dell’identità segue le istruzioni che Google dà al tuo account. La prima release del test chiuso viene esaminata prima che i tester possano partecipare, in genere entro 7 giorni. Il test chiuso dura almeno 14 giorni una volta che 12 tester sono attivati continuamente. La revisione dell’accesso in produzione in genere richiede al massimo 7 giorni. Anche la release di produzione viene esaminata. Mettile in fila:

La differenza si decide in due punti: quanto in fretta i tuoi 12 tester attivano davvero il test, perché la finestra si apre con le attivazioni valide e non con il tuo caricamento, e se qualche revisione torna con una modifica richiesta, perché ogni rimbalzo ripete un ciclo di revisione. Invece di una data stimata, controlla cosa deve essere vero prima della tua fase successiva:

Come si inserisce PrimeTestLab

PrimeTestLab gestisce l’unico orologio che controlli. Le finestre di revisione di Google sono uguali per tutti; il test chiuso è la fase che un gruppo gestito può portare avanti per te: tester attivati entro 4-6 ore, tenuti attivi per tutti i 14 giorni, abbandoni sostituiti in giornata. Un tester sostitutivo inizia la propria attivazione continua, ed è per questo che i piani più grandi includono un margine sopra i 12.

Ecco come si divide il lavoro critico di calendario quando gestisci la finestra da solo rispetto a consegnarla a un roster gestito:

Domande frequenti sui tempi di revisione di Google Play

Conclusione