# Build number App Store Connect: versione e numero di build > La versione è il numero che vedono i tuoi clienti, il build number identifica ogni invio. La coppia deve essere unica: con Expo, EAS incrementa il build per te. Pagina originale: [Build number App Store Connect: versione e numero di build](https://devoria.fr/it/blog/build-number-app-store-connect-versione-numero-build) Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi) Pubblicazione: 2026-11-04 Ultima revisione dei contenuti: 2026-11-04 Il build number di App Store Connect è il numero di build: la chiave `CFBundleVersion`, che identifica ogni invio. La versione, `CFBundleShortVersionString`, è il numero che i tuoi clienti vedono sull'App Store. **Apple richiede che la coppia versione e numero di build sia unica: un numero di build si usa una sola volta per la stessa versione.** Con Expo, la versione la imposti tu ed EAS può incrementare il numero di build a ogni build di produzione. Questa guida spiega i due numeri, le regole di Apple, gli errori ITMS-90062 e ITMS-90189, e cosa controllare quando il tuo build non compare. Pubblico le mie app iOS con Expo ed EAS, tra cui Solys, TradaZen e Nolera. Le impostazioni che vedi più sotto sono quelle dei loro file `eas.json`. ## Versione e numero di build: che differenza c'è? Due chiavi dell'Info.plist identificano la tua app. [La documentazione di Apple su CFBundleShortVersionString](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) la descrive come la versione visibile all'utente: tre interi separati da punti, come 10.14.1. [Quella su CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) parla della versione del build: da uno a tre interi, solo cifre e punti. | Elemento | Chiave iOS | Chi la vede | Campo Expo | | --------------- | -------------------------- | -------------- | ----------------- | | Versione | CFBundleShortVersionString | I tuoi clienti | `version` | | Numero di build | CFBundleVersion | Tu e Apple | `ios.buildNumber` | Esempio fittizio: per la versione 1.4.0 invii i build 12, 13 e 14 durante i test, poi ne scegli uno per la revisione. [L'aiuto di App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) lo riassume così: la versione collega il build alla sua scheda, il numero di build lo identifica ovunque nel sistema. ## Le regole di incremento di Apple 1. **La coppia deve essere unica.** Secondo [la documentazione di Xcode Cloud](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds), App Store Connect richiede una combinazione unica di versione e numero di build. Un'app iPhone può quindi ripartire da 1 per una nuova versione. Un'app Mac no: il suo numero deve sempre salire. 2. **Una versione approvata è chiusa.** Una volta che Apple ha approvato la versione 1.4.0, non puoi più aggiungerle build. La successiva deve avere un numero più alto. 3. **Ogni numero si confronta come un intero.** 1.10 viene dopo 1.9, perché 10 è maggiore di 9. Una versione 1.9 inviata dopo una 1.20 approvata verrà rifiutata. Il mio consiglio: **tieni un numero di build intero che sale sempre, senza riportarlo a 1.** Ripartire da 1 è consentito su iPhone, ma un numero unico per tutta la vita dell'app evita di confondere due build in TestFlight. È quello che vedo sulle mie app in modalità remota: il contatore continua da una versione all'altra. ## Gestire versione e build con Expo ed EAS [La pagina di Expo sulle versioni](https://docs.expo.dev/build-reference/app-versions/), aggiornata il 25 settembre 2026, separa i ruoli. La versione (`version` in app.json) resta a te: la cambi quando prepari una nuova release. Il numero di build (`ios.buildNumber`) puoi affidarlo a EAS. Expo cita tra l'altro la dimenticanza dell'incremento come una causa frequente di rifiuto all'invio. Si configura tutto in eas.json: ```json { "cli": { "appVersionSource": "remote" }, "build": { "production": { "autoIncrement": true } } } ``` - **`"remote"`**: i server di EAS conservano il numero di build. È il comportamento consigliato da EAS CLI 12. Il contatore parte dal valore della tua configurazione, o da 1, e poi `ios.buildNumber` viene ignorato. - **`"local"`**: fa fede la tua configurazione. Con `autoIncrement`, EAS modifica `ios.buildNumber` nel tuo file, e devi fare commit di questa modifica a ogni build. - **`autoIncrement`**: [il riferimento di eas.json](https://docs.expo.dev/eas/json/) accetta `true` o `"buildNumber"` per il build, e `"version"` per incrementare l'ultima cifra della versione. In modalità remota, Expo precisa che `"version"` non è supportato. Nel mio caso, TradaZen e Nolera sono in `remote`. Solys è rimasta in `local`: il suo numero di build vive in app.json e ogni build di produzione lo fa salire nel file. **Funzionano entrambe, ma la modalità remota elimina il rischio di un commit dimenticato.** Due comandi completano il quadro. `eas build:version:set` inizializza il contatore remoto: inserisci l'ultimo numero inviato ad Apple. `eas build:version:sync` copia i valori remoti nel tuo progetto, utile se un giorno compili con Xcode. Con EAS Update, la modalità remota non funziona con la policy `nativeVersion`: Expo consiglia `appVersion`. ## ITMS-90062: la versione è già approvata Il messaggio è simile a questo (numeri fittizi): ```text ERROR ITMS-90062: This bundle is invalid. The value for key CFBundleShortVersionString [1.4.0] in the Info.plist file must contain a higher version than that of the previously approved version [1.4.0]. ``` Apple ha già approvato la versione 1.4.0: non puoi più aggiungerle build. **Alza la versione in app.json, per esempio a 1.4.1, poi rilancia un build.** Cambiare solo il numero di build non basta. Se l'errore torna anche con `version` aggiornato, cerca un campo `ios.version`. Secondo [il riferimento della configurazione Expo](https://docs.expo.dev/versions/latest/config/app/), ha la precedenza su `version` per iOS. Stesso rimedio per l'errore cugino ITMS-90186, "Invalid Pre-Release Train", che segnala una versione chiusa a nuovi build. ## ITMS-90189: Redundant Binary Upload Qui il problema è il numero di build: ```text ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded a build with build number '12' for version number '1.4.0'. ``` La coppia 1.4.0 (12) esiste già da Apple. Con Expo, le cause ricorrenti sono quattro: - **Il profilo usato non ha `autoIncrement`.** Se crei un profilo separato per TestFlight, come quello di Nolera, rimettici l'opzione. - **Il contatore remoto è indietro.** Sei passato a `remote` dopo degli invii manuali: lancia `eas build:version:set` con l'ultimo numero noto ad Apple. - **Hai dimenticato il commit in modalità locale.** Il build successivo riparte dal vecchio numero. - **Stai reinviando lo stesso binario.** Con `eas submit`, scegli il nuovo build, non quello vecchio. **La soluzione è sempre la stessa: un nuovo build con un numero più alto.** ## "No builds available": il tuo build non compare Il build è partito, ma la tua scheda non lo propone. Controlla in quest'ordine. 1. **È ancora in elaborazione.** Apple elabora ogni build prima di mostrarlo e ti manda un'e-mail alla fine. [Expo](https://docs.expo.dev/submit/ios/) parla in genere di 10-15 minuti. [Secondo Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata), oltre le 24 ore in elaborazione bisogna aprire un ticket su Feedback Assistant. 2. **Aspetta la tua dichiarazione sulla crittografia.** È lo stato Missing Compliance, spiegato più sotto. 3. **La versione non corrisponde.** Un build 1.4.1 non finisce sotto una scheda preparata come 1.5.0 in App Store Connect. Allinea le due. 4. **Nel frattempo è uscita una versione.** Secondo [l'aiuto sulla scelta del build](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit), l'elenco mostra allora solo i build inviati dopo quella release. 5. **È il tester a non vederlo.** Nell'app TestFlight, "no builds available" spesso significa che il build non è in nessun gruppo, aspetta la revisione beta o è scaduto. I dettagli sono in [TestFlight per testare la tua app iPhone](https://devoria.fr/it/blog/testflight-testare-app-iphone-prima-invio). ### Gli stati da conoscere Gli stati che spiegano più spesso un build mancante, secondo [l'elenco di Apple](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing e Failed non ci sono: sono gli stati di invio descritti nel [monitoraggio dei build](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | Stato | Cosa significa | Come risolvere | | ------------------ | ----------------------------- | --------------------------- | | Processing | Apple sta elaborando il build | Aspettare l'e-mail | | Failed | Errore in elaborazione | Leggere l'errore, reinviare | | Missing Compliance | Crittografia non dichiarata | Rispondere o Info.plist | | Invalid Binary | Invio non conforme | Correggere, nuovo build | | Expired | Superati i 90 giorni | Nuovo build | | Ready to Submit | Pronto per test o revisione | Aggiungerlo a un gruppo | ### Dichiarare la crittografia una volta per tutte Senza la chiave `ITSAppUsesNonExemptEncryption`, [Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) ti fa le domande di conformità a ogni nuova versione. Con Expo, il campo si chiama `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` significa: nessuna crittografia, o solo crittografia esente. [Apple precisa](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations) che la crittografia integrata nel sistema, come le connessioni HTTPS, è in genere esente, e che la risposta copre anche le tue librerie. Le mie tre app dichiarano `false`. **Metti `false` solo se è vero per la tua app: la dichiarazione ti impegna.** ## Si può cambiare il numero di un build già inviato? No. Il numero è scritto nel binario firmato: per correggerlo serve un nuovo build. Quello che puoi cambiare è il build collegato alla tua versione. Apple consente un solo build per versione, ma [puoi sostituirlo tutte le volte che vuoi](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) fino all'invio in revisione: 1. Apri la versione in App Store Connect, sezione Build. 2. Passa sopra il build attuale e clicca sul pulsante di rimozione, il segno meno. 3. Clicca sul pulsante di aggiunta, il segno più, scegli il build giusto, poi salva. Togliere un build da una versione non lo elimina dal tuo account. Se la versione è già in revisione, [ritira prima l'invio](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): la revisione ripartirà da zero. ## Prima del tuo prossimo invio Il numero di build è solo uno dei controlli all'invio. L'immagine di build può far scattare [ITMS-90725](https://devoria.fr/it/blog/itms-90725-sdk-version-issue-expo), e la firma ha le sue trappole, spiegate in [certificato sviluppatore iOS e provisioning profile](https://devoria.fr/it/blog/certificato-sviluppatore-ios-provisioning-profile-expo). La catena completa, dal build a TestFlight, è in [pubblicare un'app iOS senza Mac](https://devoria.fr/it/blog/pubblicare-app-ios-senza-mac-expo-eas), e i tempi di revisione in [tempi di approvazione App Store](https://devoria.fr/it/blog/tempi-revisione-app-store). Tutti i passaggi sono riuniti nella pagina [pubblicare un'app sull'App Store](https://devoria.fr/it/expertise/pubblicare-app-su-app-store). Se stai preparando la tua prima release, [fai il diagnostic gratuito](https://devoria.fr/it/diagnostic): ti dice cosa blocca il tuo progetto e ti manda la mia checklist anti-rifiuto Apple. Per costruire l'app, collegare gli abbonamenti e pubblicarla, l'[iOS & Android Kit](https://devoria.fr/it/kits/ios) segue il percorso in quattro tappe con lo Starter Code delle mie app, al tuo ritmo. ## Domande frequenti ### Che differenza c'è tra versione e build number su App Store Connect? La versione è il numero pubblico della tua release, come 1.4.0. Il build number identifica un binario preciso inviato ad Apple per quella versione. Puoi inviare più build per la stessa versione, ognuno con il suo numero. ### Bisogna cambiare il numero di build a ogni invio? Sì, per la stessa versione. Apple rifiuta un secondo invio con la stessa coppia versione e numero di build: è l'errore ITMS-90189. Con EAS, `autoIncrement` se ne occupa a ogni build di produzione. ### Il numero di build deve ripartire da 1 a ogni versione? Non è obbligatorio. Su iPhone, Apple accetta un numero più basso per una nuova versione, perché deve essere unica solo la coppia. Un contatore che sale sempre resta più semplice da seguire. ### Come si cambia il build number in App Store Connect? Non puoi modificare il numero di un build già inviato. Puoi invece sostituire il build collegato alla tua versione, dalla sezione Build della scheda, finché non è in revisione. Per un nuovo numero, rifai un build. ### Perché il mio build non compare in App Store Connect? Il più delle volte è ancora in elaborazione o aspetta la tua dichiarazione sulla crittografia. Controlla anche che la sua versione corrisponda a quella della tua scheda. Oltre le 24 ore in elaborazione, Apple chiede di aprire un ticket. ## 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.