# Pubblicare un aggiornamento iOS: rilascio graduale > Pubblicare un aggiornamento iOS: nuova versione, nuova build, testo delle novità, poi rilascio manuale, automatico o graduale in 7 giorni. Pagina originale: [Pubblicare un aggiornamento iOS: rilascio graduale](https://devoria.fr/it/blog/pubblicare-aggiornamento-ios-rilascio-graduale) Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi) Pubblicazione: 2026-11-04 Ultima revisione dei contenuti: 2026-11-04 Per pubblicare un aggiornamento iOS crei una nuova versione in App Store Connect, con un numero più alto. Ci colleghi una nuova build, scrivi il testo "Novità" e poi la invii ad App Review. **Ogni nuova versione ripassa dalla revisione di Apple, anche per una semplice correzione.** Prima dell'invio scegli come uscirà dopo l'approvazione: a mano, subito, non prima di una certa data, oppure con un rilascio graduale in 7 giorni. Il rilascio graduale riguarda solo gli aggiornamenti automatici: l'1% di questi utenti il primo giorno, tutti il settimo. Puoi metterlo in pausa fino a 30 giorni in totale, oppure chiuderlo in un colpo solo. Questa guida segue le pagine di aiuto di Apple, ricontrollate il 3 novembre 2026. Pubblico gli aggiornamenti delle mie app iOS con Expo ed EAS, tra cui Solys, TradaZen e Nolera. I casi che cito più sotto vengono da questi rilasci. ## Pubblicare un aggiornamento iOS: i passaggi in ordine [L'aiuto di App Store Connect sulle nuove versioni](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version) indica questo percorso: 1. In Apps, scegli la tua app, poi clicca sul pulsante + accanto alla piattaforma. 2. Inserisci un numero di versione più alto del precedente, poi clicca su Create. 3. Rileggi i metadati: quelli della versione online vengono copiati in automatico. 4. Invia una nuova build, con un numero di build incrementato. 5. Testa questa build su [TestFlight](https://devoria.fr/it/blog/testflight-testare-app-iphone-prima-invio), aggiungila alla versione, poi inviala ad App Review. Due condizioni prima di iniziare. La versione online deve essere nello stato Ready for Distribution. E ti serve uno di questi ruoli: Account Holder, Admin, App Manager o Marketing. **Non esiste un modo per tornare indietro.** Apple lo scrive sulla stessa pagina: se una versione dà problemi, non puoi tornare alla precedente. Devi creare e inviare una nuova versione. ## Numero di versione e numero di build La versione è il numero che i tuoi clienti vedono sulla scheda. La build identifica ogni invio. **La coppia versione e build deve essere unica**: le regole e gli errori collegati sono in [versione e numero di build](https://devoria.fr/it/blog/build-number-app-store-connect-versione-numero-build). La mia convenzione, che non è una regola di Apple: l'ultima cifra sale per una correzione, da 1.4.0 a 1.4.1. Quella centrale sale per una nuova funzione, da 1.4.1 a 1.5.0. Il numero di build invece sale e basta, da una versione all'altra. Con Expo la versione sta in `app.json` ed EAS può incrementare la build a ogni compilazione di produzione. La configurazione è in [pubblicare un'app Expo con EAS](https://devoria.fr/it/blog/eas-submit-ios-pubblicare-app-expo-app-store). ## Il testo "Novità": cosa richiede Apple [La pagina delle informazioni di versione](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information) descrive il campo What's New in This Version: - **Al massimo 4.000 caratteri.** - **Assente per la prima versione, obbligatorio per tutte le successive.** - **Traducibile in ogni lingua della tua scheda.** La regola 2.3.12 delle [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.12) aggiunge un requisito: descrivere chiaramente le nuove funzioni e i cambiamenti del prodotto. Una formula generica basta per semplici correzioni di bug, di sicurezza o di prestazioni. **Un cambiamento importante va elencato.** "Correzioni di bug e miglioramenti" quindi non basta per una versione che cambia il tuo abbonamento o la tua schermata principale. Apple consiglia anche, nella [sua pagina dedicata alle recensioni](https://developer.apple.com/app-store/ratings-and-reviews/), di segnalare nelle note i problemi risolti che i clienti avevano descritto nelle loro recensioni. Ecco tre modelli da adattare, uno per tipo di versione. Per una correzione: ```text Correzioni e stabilità. - [Funzione]: [cosa non funzionava] è stato corretto. - [Schermata] si carica più velocemente. Grazie a chi ce lo ha segnalato. ``` Per una nuova funzione: ```text Novità: [la funzione, in cinque parole]. [Cosa puoi fare adesso, in una frase.] Dove trovarla: [scheda] > [pulsante]. Anche in questa versione: - [Miglioramento visibile]. - Correzioni di bug. ``` Per un percorso che cambia: ```text [Schermata o percorso] cambia. - Cosa cambia per te: [effetto concreto]. - Cosa conservi: [dati, impostazioni, acquisto]. Una domanda? [Impostazioni] > [Aiuto]. ``` L'ultima riga del modello di correzione vale solo se qualcuno ha davvero segnalato il problema. Non scrivere mai una novità che non è nella build: la regola 2.3 chiede metadati fedeli all'app. ## Rilascio manuale, automatico o a una data [L'aiuto sulle opzioni di rilascio](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) ne propone tre: | Opzione | Dopo l'approvazione di Apple | | ---------------------------- | ------------------------------------------------------ | | Manuale | Stato Pending Developer Release, pubblichi quando vuoi | | Automatica | La versione esce appena approvata | | Automatica, non prima del... | Aspetta la data scelta, poi esce da sola | Con il rilascio manuale apri la versione nello stato Pending Developer Release, clicchi su Release This Version e confermi. Apple avverte che può volerci fino a 24 ore perché compaia sull'App Store. Un messaggio sulla pagina della versione propone Cancel This Release per annullare. Se la versione resta in attesa per più di 30 giorni, Apple ti manda un promemoria via e-mail. **Il rilascio manuale serve a scegliere il momento**, per esempio per pubblicare il giorno di un annuncio. Solys 2.0.0, che includeva una nuova versione dell'abbonamento annuale, è andata in revisione a fine settembre 2026 con rilascio manuale. Per una versione di routine lascio il rilascio automatico. Nolera 1.0.2, approvata il 12 ottobre 2026, è comparsa sull'App Store meno di un minuto dopo l'e-mail di Apple, secondo l'API pubblica di ricerca di iTunes. È una sola osservazione: tieniti largo. ## Il rilascio graduale in 7 giorni [L'aiuto di Apple sul rilascio graduale](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases) dà il calendario esatto: | Giorno | Quota di utenti | | ------ | --------------- | | 1 | 1% | | 2 | 2% | | 3 | 5% | | 4 | 10% | | 5 | 20% | | 6 | 50% | | 7 | 100% | L'aggiornamento parte verso un campione casuale degli utenti che hanno attivato gli aggiornamenti automatici, sui dispositivi compatibili. Non vengono avvisati di farne parte. **Il rilascio graduale frena solo gli aggiornamenti automatici.** Apple precisa che chiunque può scaricare la nuova versione dall'App Store, in qualsiasi momento. Chi installa la tua app, o tocca "Update" sulla tua scheda, può quindi averla dal primo giorno. Non è un test sull'1% dei tuoi utenti: è un freno sugli altri. Per attivarlo, apri la versione, scendi fino alla sezione Phased Release for Automatic Updates, spunta "Release update over a 7-day period using phased release" e salva. Serve il ruolo Account Holder, Admin o App Manager. L'opzione resta disponibile fino allo stato Pending Developer Release: **puoi ancora attivarla dopo l'approvazione di Apple, finché la versione aspetta il tuo rilascio manuale.** Una volta approvata la versione, il suo stato Ready for Distribution riporta la dicitura "Phased Release". Alla fine dei 7 giorni, gli Admin e gli App Manager dell'app ricevono una notifica. ### Pausa, ripresa e rilascio per tutti - **Pausa**: fino a 30 giorni in totale, in quante volte vuoi. Una pausa di 10 giorni lascia 20 giorni per le successive. - **Ripresa**: il rilascio riparte dal giorno in cui l'avevi fermato. - **Rilascio per tutti**: il pulsante Release to All Users, in alto a destra nella versione, invia l'aggiornamento a tutti i dispositivi con aggiornamento automatico. - **Ritiro dalla vendita**: ferma il rilascio definitivamente, anche se la tua iscrizione al programma sviluppatori scade. Se l'app torna in vendita, la versione è disponibile per tutti in un colpo solo. Dopo il rilascio per tutti non si può più regolare nulla, precisa [la tabella delle proprietà modificabili](https://developer.apple.com/help/app-store-connect/reference/app-information/required-localizable-and-editable-properties). Nolera 1.0.2 è uscita senza rilascio graduale. Ecco come lo userei durante la settimana: | Cosa vedi | Cosa fai | Cosa succede | | ----------------------------------- | -------------------------- | ----------------------------------------- | | Crash o recensioni preoccupate | Pausa | Gli aggiornamenti automatici si fermano | | La correzione è pronta | Nuova versione | Ripassa in revisione, con il suo rilascio | | Niente di anomalo dopo 3 o 4 giorni | Release to All Users | La ricevono tutti | | Aspetti una risposta da Apple | Pausa, 30 giorni in totale | Ripresa dal giorno in cui ti sei fermato | Durante una pausa i download manuali continuano. **Spunta il rilascio graduale per ogni versione che tocca il pagamento o il primo avvio**: è lì che un difetto costa di più, e non potrai tornare indietro. ## Quando la correzione è urgente: la revisione accelerata Apple permette di chiedere una [revisione accelerata](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review). È riservata alle vere urgenze: un bug critico da correggere, o un rilascio legato a un evento. 1. Prima invia la tua versione. Descrivi il bug nel campo Notes destinato al reviewer. 2. Compila il modulo di richiesta di revisione accelerata, poi scegli la tua app e la sua piattaforma. 3. Apple accelera la revisione in base alla sua disponibilità. Niente è garantito. Per un evento, indica nelle note la data e il tuo legame con esso. I tempi abituali sono in [i tempi di approvazione dell'App Store](https://devoria.fr/it/blog/tempi-revisione-app-store). ## Cosa ripassa in revisione e cosa no | Modifica | Cosa serve | | ------------------------------------------------ | ----------------------------------------------- | | Codice nativo, autorizzazioni, versione dell'SDK | Nuova build, nuova versione, revisione completa | | Screenshot, descrizione, parole chiave, novità | Una nuova versione, revisionata insieme a essa | | Testo promozionale | Niente: cambia senza un nuovo invio | | Pausa, ripresa, rilascio per tutti | Niente: sono impostazioni di rilascio | | Intestazione della scheda iOS 27 | Da sola in Asset Library, o con una versione | | Correzione JavaScript, con Expo | È possibile un aggiornamento remoto | Il [testo promozionale](https://devoria.fr/it/blog/testo-promozionale-app-store-170-caratteri) cambia senza un nuovo invio, secondo la pagina delle informazioni di versione. Con Expo, un aggiornamento remoto cambia il JavaScript, i testi e le immagini senza passare dall'App Store. [La documentazione di Expo](https://docs.expo.dev/eas-update/introduction/) pone due limiti: codice nativo, autorizzazioni e versione dell'SDK richiedono un nuovo binario, e gli aggiornamenti devono rispettare le regole dell'App Store. ### Il mio caso: una correzione remota che il reviewer non ha mai visto A settembre 2026 una build di Nolera era in attesa di revisione. Avevo corretto un difetto della schermata di scansione e pubblicato la correzione come aggiornamento remoto durante l'attesa. La build è stata comunque rifiutata, per quel difetto già corretto. La spiegazione è nella [documentazione di expo-updates](https://docs.expo.dev/versions/latest/sdk/updates/): di default l'app scarica l'aggiornamento all'avvio e lo applica all'avvio successivo. Il reviewer installa l'app, la avvia una volta e testa il codice incluso nella build. **La stessa regola vale per i tuoi nuovi utenti: la loro prima sessione gira sul codice della build.** Da allora ogni modifica alla home, al paywall o alla funzione principale va in una nuova build. L'aggiornamento remoto serve solo a chi ha già l'app. ## Azzerare la valutazione con una versione Ogni nuova versione propone l'opzione Reset rating when this version is released. Secondo [l'aiuto di Apple sull'azzeramento](https://developer.apple.com/help/app-store-connect/monitor-ratings-and-reviews/reset-an-app-overview-rating), vale per tutti i paesi, conserva le recensioni scritte e non si può annullare dopo il rilascio. Apple consiglia di usarla con parsimonia, perché una scheda con poche valutazioni può scoraggiare. ## La checklist prima di inviare il tuo aggiornamento - Il numero di versione è più alto, la build è incrementata. - La build è testata su TestFlight, su un iPhone piccolo e su iPad se la tua app ci gira. - Le novità sono scritte in ogni lingua e i cambiamenti importanti sono elencati. - Gli screenshot mostrano l'interfaccia attuale, se è cambiata. - Le note per il reviewer dicono cosa è cambiato e dove trovarlo. - L'opzione di rilascio è scelta: manuale se devi rispettare una data. - Il rilascio graduale è spuntato se la versione tocca il pagamento o il primo avvio. - Sai se un'eventuale correzione può partire da remoto o se richiederà una build. ## Superare la revisione a ogni aggiornamento Ogni aggiornamento ripassa davanti ad App Review, e un rifiuto blocca la tua correzione. Il [Review Kit](https://devoria.fr/it/kits/app-review) raccoglie la mia checklist prima dell'invio, i miei rifiuti risolti e due skill di Claude Code che rileggono il tuo progetto e la tua scheda, poi preparano la tua risposta se Apple rifiuta. Il percorso completo è nella pagina [pubblicare un'app sull'App Store](https://devoria.fr/it/expertise/pubblicare-app-su-app-store). Se stai preparando il tuo primo rilascio, [fai la tua diagnosi gratuita](https://devoria.fr/it/diagnostic): rimette i passaggi in ordine e ti invia la mia checklist anti-rifiuto di Apple. ## Domande frequenti ### Quanto dura il rilascio graduale sull'App Store? Sette giorni: l'1% degli utenti con aggiornamento automatico il primo giorno, poi 2, 5, 10, 20 e 50%, e il 100% il settimo. Puoi metterlo in pausa fino a 30 giorni in totale, o chiuderlo in qualsiasi momento con Release to All Users. ### Un aggiornamento di un'app iOS ripassa dalla revisione di Apple? Sì. Ogni nuova versione, con la sua build e i suoi metadati, passa da App Review. Il testo promozionale e le impostazioni di rilascio invece si cambiano senza un nuovo invio. ### Si può tornare alla vecchia versione di un'app sull'App Store? No. Devi creare una nuova versione, con la correzione, e inviarla in revisione. Ecco perché il rilascio graduale e la sua pausa sono utili. ### I nuovi utenti ricevono l'aggiornamento durante il rilascio graduale? Sì, se scaricano l'app dall'App Store. Il rilascio graduale regola solo gli aggiornamenti automatici: chiunque può scaricare la nuova versione in qualsiasi momento. ### Si può attivare il rilascio graduale dopo l'approvazione di Apple? Sì, finché la versione è nello stato Pending Developer Release, cioè con rilascio manuale e non ancora pubblicata. Una volta uscita la versione, è troppo tardi per quella versione. ### Cosa scrivere nelle note di versione di un aggiornamento? Le nuove funzioni e i cambiamenti importanti, elencati chiaramente: è la regola 2.3.12. Per una semplice correzione di bug, di sicurezza o di prestazioni basta una formula generica. Il campo accetta 4.000 caratteri e si traduce in ogni lingua. ## Il tuo progetto [Review Kit](https://devoria.fr/it/kits/app-review): La mia checklist per la review dell'App Store, i rifiuti di Apple che ho risolto, quella di Google Play e tre skill per Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone e Android con Claude Code: il codice di partenza delle mie app, il percorso fino agli store e tutti i kit. 99 €. [Diagnosi: cosa ti separa dalla tua app per iPhone](https://devoria.fr/it/diagnostic): 7 domande, 60 secondi: scopri cosa ti blocca davvero nel pubblicare la tua app per iPhone, il tuo percorso in 4 tappe e il kit giusto per te.