Quanto dura davvero la revisione di Google Play nel 2026?

Ogni tappa di un lancio su Google Play ha il proprio orologio, e confonderli è come un piano di tre settimane diventa sei in silenzio. Questo post percorre il pipeline 2026 tappa per tappa: i numeri che Google dichiara davvero, le tappe senza termine promesso, la finestra che è lavoro tuo e non di Google, e il conto per una stima realistica dal primo invio all’app live. Aggiornato l’11 luglio 2026; dove il numero conta, usiamo la formulazione di Google stessa invece di indovinelli da 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?

Tra minuti e circa una settimana per revisione, a seconda di quale revisione stai aspettando. Le versioni di test interno di solito diventano disponibili in minuti. La prima versione del test chiuso può richiedere fino a 7 giorni di revisione manuale. La revisione di accesso in produzione in genere richiede al massimo 7 giorni, secondo il testo di Google. E le revisioni standard di versione o update di solito sono rapide, ma senza termine promesso. I famosi 14 giorni stanno tra queste revisioni e non sono 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

   I build di solito diventano disponibili per i tester interni in minuti, anche se la prima versione può essere esaminata e il link del test può impiegare qualche ora a funzionare dopo la prima pubblicazione.

2. 02
   Prima versione del test chiuso Fino a 7 giorni

   Una revisione manuale di Google sta tra te e i tester. Quei 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 in 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

   Le revisioni standard di solito sono rapide, ma alcune richiedono fino a 7 giorni o più in casi eccezionali. Non lasciare mai l’invio a ridosso della 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 dopo. La verifica di identità arriva prima e richiede alcuni giorni. Poi la prima versione del test chiuso passa da una revisione manuale che può richiedere fino a 7 giorni. Solo dopo il test di 14 giorni arrivi alla revisione di accesso in produzione. Al primo lancio, pianifica dal lato lento di ogni fascia.

Un primo invio non viene esaminato una sola volta: passa da una catena di controlli, ognuno con il proprio orologio. Prima di qualsiasi pubblicazione, Google verifica la tua identità, il che di solito richiede alcuni giorni. Il primo upload su un canale chiuso poi attende la revisione manuale della prima versione. Dopo la finestra di test, la richiesta di accesso in produzione e la revisione della versione finale restano ancora tra te e lo store. Nessuna di queste tappe è opzionale per un account personale nuovo, e nessuna si sovrappone alla successiva.

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 il calendario reale si avvicina al doppio. La buona notizia è che le tappe intorno alle revisioni possono sovrapporsi: puoi finire la scheda dello store, le dichiarazioni e gli screenshot mentre una revisione è in corso, e Google incoraggia a iniziare subito la verifica di identità.

Quanto durano le revisioni sul canale di test chiuso?

La prima versione del test chiuso passa da una revisione manuale di Google che può richiedere fino a 7 giorni. I build successivi sullo stesso canale seguono il flusso normale di revisione di Google, senza termine promesso. Il punto critico: i giorni di revisione della prima versione non contano per il requisito di 14 giorni. Quell’orologio parte solo dopo che la versione è approvata sul canale chiuso e i tester attivano davvero.

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 in 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 (in inglese). Questo post risponde a una domanda più stretta: quanto durano le revisioni intorno a quel test.

La trappola è la prima versione. Il test interno abitua lo sviluppatore ad aspettarsi build in minuti; la prima versione su canale chiuso si comporta diversamente, restando in revisione manuale che può arrivare a 7 giorni. Non c’è nulla di sbagliato nell’app mentre resta lì. Ma se hai convocato i tester per «domani», ora aspettano Google con te, e la finestra di 14 giorni non è 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

Nulla viene esaminato durante i 14 giorni. La finestra è un requisito di test che gestisci tu: i tester restano attivati e usano davvero l’app per 14 giorni consecutivi. I revisori di Google tornano in scena solo quando richiedi l’accesso in produzione dopo. Aspettare in silenzio non fa avanzare; tenere i tester attivi 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 in produzione: in genere al massimo 7 giorni

Questa è l’unica revisione in cui Google mette un numero. Dopo che il test chiuso soddisfa i requisiti, richiedi l’accesso in produzione con un modulo in tre parti, e Google esamina la richiesta: in genere questa operazione richiede al massimo 7 giorni, ma a volte può essere necessario più tempo. La decisione viene inviata via email 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 in 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 termine fisso di revisione per gli update. Le revisioni standard di solito sono rapide, ma alcune richiedono fino a 7 giorni o più in casi eccezionali. Gli update di un’app che ha già l’accesso in produzione non hanno bisogno di un test chiuso nuovo di 12 tester: passano solo dalla revisione normale.

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

Update dopo l’accesso in produzione. Il requisito di test si soddisfa una volta per app, quindi un update di routine di un’app online non riattiva mai il test di 14 giorni. Passa dalla revisione standard di versione di Google, quella senza termine promesso. In pratica, il timing degli update è questione di pianificazione, non di policy: se la versione conta per una data, una spinta di marketing o una correzione con utenti in attesa, invia 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)

La maggior parte delle revisioni lente è ritardata dall’invio, non dalla coda. Dichiarazioni incomplete, un login che il revisore non riesce a superare, permessi sensibili o una storia di test debole aggiungono tempo o forzano un secondo passaggio. La leva che non esiste: pagare o chiedere a Google di sbrigarsi. Nessun percorso di priorità è documentato 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 fasce a pagamento, richieste di priorità né canali di supporto che facciano salire una revisione standard in coda. Chi promette di accelerare il lato di Google promette ciò che Google non vende. La tua leva vive solo nella preparazione, ed è perché i lanci più rapidi sono quelli che non vedono mai un secondo ciclo di revisione.

La tua app è bloccata in revisione? Quando agire

Entro 7 giorni, una revisione silenziosa è normale, non bloccata. La formulazione di Google consente esplicitamente che le revisioni a volte impiegano più della finestra abituale. Agisci quando la finestra abituale è chiaramente passata: conferma che la versione sia stata davvero inviata per la revisione, controlla l’email del titolare dell’account incluso lo spam e solo allora contatta il supporto della Play Console.

«Bloccata» è quasi sempre una di tre cose: una revisione ancora entro la fascia normale, una versione che non è mai stata inviata davvero, o una decisione già arrivata in una casella che nessuno ha controllato. Passa la tua situazione dal verificatore prima di assumere il 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 versione salvata come bozza, o modifiche mai inviate per la revisione, non esamina nulla. Questo passaggio da solo risolve buona parte dei casi «bloccata».

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

   Google invia le decisioni al titolare dell’account, non necessariamente all’indirizzo che guardi ogni giorno. Un rifiuto di una settimana nello spam sembra esattamente una revisione bloccata dall’interno della Console.

3. 3
   Aspetta la finestra dichiarata prima di scalare

   Entro 7 giorni, scalare non compra nulla: la revisione si comporta come documentato. Segna il giorno in cui la finestra scade e agisci allora, non prima.

4. 4
   Contatta il supporto della Play Console

   Passata la finestra abituale, con invio confermato e casella vuota, usa il menu Aiuto nella Play Console per parlare con il supporto. Se la risposta che arriva è un rifiuto, parti da perché il test chiuso viene rifiutato prima di reinviare.

Dal primo invio all’online: un calendario realistico

Somma le tappe e un account personale nuovo di solito ha bisogno di 3-5+ settimane dalla creazione dell’account all’app online. La fase di test in sé è un’aritmetica più stretta: con i tester attivati il giorno 1, la richiesta di accesso in produzione cade intorno al giorno 15, e la revisione in genere al massimo 7 giorni di Google mette la decisione di solito entro la terza settimana di test. Le tappe possono sovrapporsi, e un rifiuto estende il totale.

Quel numero non è statistica inventata: sono i componenti di Google stesso sommati. La verifica di identità richiede alcuni giorni. La revisione della prima versione del test chiuso richiede fino a 7 giorni. Il test chiuso richiede esattamente 14 giorni quando parte. La revisione di accesso in produzione in genere richiede al massimo 7 giorni. La revisione della versione finale di solito è rapida, ma può aggiungere giorni. Metti tutto in sequenza:

La differenza tra tre settimane e cinque o più si decide quasi tutta in due punti: quanto in fretta i 12 tester attivano davvero, perché la finestra si apre con il 12° e non con il tuo upload, e se qualche revisione torna come rifiuto, perché ogni rifiuto ripete un ciclo di revisione. Tutto il resto è matematica fissa. Proietta le tue date:

Come si inserisce PrimeTestLab

PrimeTestLab comprime l’unico orologio che controlli. Le finestre di revisione di Google sono uguali per tutti; la tappa che separa davvero un lancio di tre settimane da uno di sei è il test chiuso, ed è la tappa che un roster gestito fa correre sui binari: tester che attivano in 4-6 ore, tenuti attivi per tutti i 14 giorni, uscite rimpiazzate lo stesso giorno.

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