Rilascio graduale App Store: come funziona in 7 giorni, quando sospenderlo e come rilasciare un fix (2026)

Un rilascio graduale dell'App Store (phased release) invia un aggiornamento di versione a una quota crescente di utenti con gli aggiornamenti automatici attivi nell'arco di sette giorni, partendo dall'1% il primo giorno e arrivando al 100% il settimo. Se controlli ogni giorno crash ed email di supporto e metti in pausa appena qualcosa non va, una build difettosa raggiunge un piccolo gruppo di persone invece di tutta la tua base utenti. Il rilascio graduale ha però un grosso limite: controlla solo gli aggiornamenti automatici. Chiunque può comunque scaricare la nuova versione manualmente.

Cosa controlla il rilascio graduale dell'App Store, e cosa no?

Il rilascio graduale controlla solo quali utenti con gli aggiornamenti automatici attivi ricevono l'aggiornamento di versione, e quando. Non nasconde la nuova versione ai download manuali e non riporta alla versione precedente chi l'ha già installata.

Secondo l'App Store Connect Help di Apple, "un campione casuale di utenti con gli aggiornamenti automatici attivi su dispositivi idonei riceverà l'aggiornamento, senza alcuna notifica della loro partecipazione al rilascio graduale". Funziona per gli aggiornamenti di versione iOS, macOS e tvOS, quindi non puoi usarlo per il primo rilascio di un'app. Per configurarlo serve il ruolo Account Holder, Admin o App Manager. Apple afferma inoltre: "Le app e gli aggiornamenti delle app in rilascio graduale possono essere scaricati manualmente dall'App Store da chiunque e in qualsiasi momento."

Qual è il calendario del rilascio graduale dell'App Store?

A novembre 2026 il calendario è fisso: 1%, 2%, 5%, 10%, 20%, 50% e 100% in sette giorni, e non si può modificare. Quello che controlli tu è quando mettere in pausa e quando passare direttamente al 100%.

Tratta ogni giorno come un checkpoint che si chiude con una sola decisione: proseguire o mettere in pausa.

Come si attiva il rilascio graduale in App Store Connect?

Il rilascio graduale si attiva dalla pagina della versione, nella sezione Phased Release for Automatic Updates, in qualsiasi momento prima che l'aggiornamento sia pubblicato. Non devi decidere prima dell'invio.

Apple lo consente mentre la versione è negli stati Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected o Metadata Rejected.

1. In Apps, seleziona la tua app, poi fai clic nella barra laterale sulla versione che stai inviando.
2. Scorri fino a Phased Release for Automatic Updates.
3. Seleziona Release update over a 7-day period using phased release.
4. Fai clic su Save. Dopo l'approvazione, lo stato mostra Ready for Distribution con accanto Phased Release.

Puoi gestire i rilasci graduali anche tramite l'App Store Connect API, comodo se la tua pipeline di rilascio è già automatizzata con script.

Quando mettere in pausa un rilascio graduale, e come funziona il limite di 30 giorni?

Metti in pausa non appena scatta uno dei trigger concordati in anticipo. Le pause possono sommare fino a 30 giorni in totale e, quando riprendi, il rollout continua dal giorno in cui si era fermato.

Metti per iscritto i trigger prima del giorno del lancio, così nessuno ne discute mentre gli utenti stanno incappando nel bug. I buoni trigger sono concreti: le sessioni senza crash scendono sotto il valore di riferimento della versione precedente, checkout o login falliscono per una quota misurabile di tentativi, oppure più utenti segnalano lo stesso bug.

Per mettere in pausa, apri la versione in Ready for Distribution, seleziona Pause Phased Release e fai clic su Save. Per riprendere, seleziona Use Phased Release. L'esempio di Apple: se metti in pausa per 10 giorni e poi riprendi, ti restano 20 giorni di pausa. Puoi mettere in pausa tutte le volte che vuoi entro quel totale. Per saltare le fasi rimanenti, fai clic su Release to All Users in alto a destra nella pagina della versione.

Come si svolge un rilascio graduale quando emerge un bug?

Quando emerge un bug, metti in pausa, lo correggi e pubblichi una nuova versione, di nuovo con il rilascio graduale attivo. Gli utenti ancora in attesa dell'aggiornamento automatico restano sulla versione precedente mentre lavori.

Supponiamo che la versione 3.4 sostituisca il tuo motore di sincronizzazione. Il primo giorno la riceve l'1% degli utenti con aggiornamento automatico, e tu controlli due volte il crash reporter e i log degli errori di sincronizzazione. Il terzo giorno, al 5%, compare un gruppo di errori di sincronizzazione su una versione di iOS meno recente. Metti subito in pausa. Gli utenti colpiti sono molti meno che se l'avessero ricevuta tutti, e gli utenti con aggiornamento automatico non ancora raggiunti restano sulla 3.3.

Poi correggi il bug e invii la 3.4.1 con il rilascio graduale attivo. Testa la correzione in una build di release, non solo in debug; il nostro piano di test sulla build di release copre questo passaggio. Scrivi chiaramente nelle note di rilascio della 3.4.1 che la sincronizzazione è stata corretta; i nostri esempi di note di rilascio mostrano come fare. Se la correzione è urgente e ne sei sicuro, dopo l'approvazione usa Release to All Users invece di aspettare un'altra settimana.

Un'altra protezione: metti il nuovo motore di sincronizzazione dietro un flag lato server. La pausa impedisce all'aggiornamento di diffondersi, ma un flag ti permette di disattivare il codice rischioso per chi ha già installato la 3.4. Le due cose funzionano bene insieme.

Quali problemi hanno incontrato altri sviluppatori mettendo in pausa un rilascio graduale?

Le discussioni pubbliche mostrano sempre lo stesso schema: gli sviluppatori mettono in pausa una versione difettosa, poi non sanno bene cosa succeda con un rilascio graduale successivo per gli utenti che l'avevano già ricevuta. La documentazione di Apple non risponde a questa domanda, quindi pianifica come se la correzione avesse bisogno di un rollout tutto suo.

• Uno sviluppatore sugli Apple Developer Forums ha raccontato di aver "notato un crash, messo in pausa il rollout dell'aggiornamento, corretto l'app, caricata e avviato un altro rollout graduale" con meno del 10% degli utenti sulla build difettosa. Chiedeva se gli stessi utenti avrebbero ricevuto il nuovo rollout. La discussione non ha mai avuto una risposta ufficiale; una risposta sosteneva che gli utenti della 8.0 "dovrebbero ricevere l'avviso che è disponibile l'aggiornamento 8.1 non appena esce".
• In una discussione separata del forum, uno sviluppatore ha scritto di essersi "fermato all'1%" con la versione 15.0.1 a causa di un bug critico e di voler scaglionare anche la 15.0.2, sperando che la 15.0.1 venisse "praticamente saltata dalla maggior parte degli utenti". Una risposta precedente nella stessa discussione suggeriva di richiedere una revisione accelerata mentre la versione difettosa era in pausa, ed eventualmente di togliere l'app dalla vendita "così che nessun nuovo utente scarichi la versione guasta". Prima di farlo, ricorda la regola sulla rimozione dalla vendita descritta nel riquadro qui sopra.
• Il team di strumenti di rilascio dietro le note store-quirks di Tramline documenta che avviare un nuovo rilascio "annullerà semplicemente il rollout esistente", e la versione precedente passa a REPLACED_WITH_NEW_VERSION con il rilascio graduale contrassegnato come COMPLETE. Le stesse note dicono che una pausa "non potrà fare nulla per gli utenti che hanno già ricevuto l'aggiornamento".

In tutti e tre i casi la pausa è servita solo a guadagnare tempo. La soluzione è sempre stata una nuova versione, e nessuno poteva contare sul fatto che lo stesso gruppo di utenti venisse aggiornato per primo. Ecco perché i flag lato server e un branch di hotfix pubblicabile in fretta contano più del pulsante di pausa.

Come si confronta l'implementazione graduale di Google Play?

L'implementazione graduale (staged rollout) di Google Play usa una percentuale che scegli tu e aumenti manualmente. Dopo un'interruzione, la ripresa raggiunge lo stesso gruppo di utenti. Pianifica i rollout dei due store separatamente.

Secondo il Centro assistenza Play Console, "la percentuale di implementazione graduale della tua app non aumenterà automaticamente", e le implementazioni graduali "possono essere utilizzate solo per gli aggiornamenti delle app, non quando si pubblica un'app per la prima volta". Dopo un'interruzione, gli utenti che hanno già ricevuto la versione la mantengono, e Google consiglia di rilasciare una nuova versione con un bundle corretto invece di riprendere quella difettosa. I rollout in produzione possono essere limitati a paesi specifici, ma una volta avviati non puoi rimuovere paesi. Se il tuo prossimo aggiornamento Android deve anche rispettare il nuovo target SDK, consulta la nostra guida al livello API target 36 su Google Play.

Cosa controllare prima di avviare un rilascio graduale?

Prima che il rollout parta, assicurati che il rilascio graduale sia salvato sulla versione, che i valori di riferimento e i trigger di pausa siano messi per iscritto e che una correzione possa essere pubblicata in fretta. Usa questa checklist:

• Rilascio graduale selezionato e salvato nella pagina della versione
• Dashboard di crash reporting ed errori del backend nei preferiti, con i valori di riferimento della versione precedente
• Trigger di pausa scritti e concordati da tutti quelli che possono premere il pulsante
• Funzionalità rischiose dietro flag lato server
• Una persona designata che controlla le metriche in ognuno dei 7 giorni
• Un branch di hotfix pronto, più la nostra checklist per l'invio all'App Store per la build successiva
• Modifiche alla scheda dello store rimandate finché il rollout non raggiunge tutti

Se preferisci delegare il rilascio stesso, il nostro servizio di pubblicazione su App Store copre la configurazione di App Store Connect e Play Console, la preparazione alla revisione e i rilasci su entrambi gli store per $599 (le quote degli account sviluppatore sono a parte). Per un secondo parere su un aggiornamento rischioso, scrivi a yagyeshsrbobde@gmail.com indicando la tua app e cosa cambia.