# Build number i App Store Connect: version och build > Versionen är numret dina kunder ser, build number identifierar varje uppladdning. Paret måste vara unikt: med Expo räknar EAS upp builden åt dig. Originalsida: [Build number i App Store Connect: version och build](https://devoria.fr/sv/blog/app-store-connect-build-number-version) Författare: [Mehdi Azizi](https://devoria.fr/sv/mehdi-azizi) Publicerad: 2026-11-04 Innehållet senast granskat: 2026-11-04 Build number i App Store Connect är byggnumret: nyckeln `CFBundleVersion`, som identifierar varje uppladdning. Versionen, `CFBundleShortVersionString`, är numret dina kunder ser på App Store. **Apple kräver att paret version och byggnummer är unikt: ett byggnummer kan bara användas en gång för samma version.** Med Expo sätter du versionen själv, och EAS kan räkna upp byggnumret vid varje produktionsbygge. Den här guiden förklarar båda numren, Apples regler, felen ITMS-90062 och ITMS-90189, och vad du ska kontrollera när din build inte dyker upp. Jag publicerar mina iOS-appar med Expo och EAS, bland annat Solys, TradaZen och Nolera. Inställningarna längre ner är de som finns i deras `eas.json`-filer. ## Version och byggnummer: vad är skillnaden? Två nycklar i Info.plist identifierar din app. [Apples dokumentation om CFBundleShortVersionString](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) beskriver den som versionen användaren ser: tre heltal åtskilda av punkter, som 10.14.1. [Den om CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) talar om byggets version: ett till tre heltal, med bara siffror och punkter. | Del | iOS-nyckel | Vem ser den | Expo-fält | | ---------- | -------------------------- | ------------ | ----------------- | | Version | CFBundleShortVersionString | Dina kunder | `version` | | Byggnummer | CFBundleVersion | Du och Apple | `ios.buildNumber` | Ett påhittat exempel: för version 1.4.0 laddar du upp build 12, 13 och 14 under testerna och väljer sedan en av dem för granskning. [Hjälpen för App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) sammanfattar det: versionen kopplar builden till din appsida, byggnumret identifierar den överallt i systemet. ## Apples regler för uppräkning 1. **Paret måste vara unikt.** Enligt [dokumentationen för Xcode Cloud](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds) kräver App Store Connect en unik kombination av version och byggnummer. En iPhone-app kan alltså börja om på 1 för en ny version. En Mac-app kan inte det: dess nummer måste alltid öka. 2. **En godkänd version är stängd.** När Apple har godkänt version 1.4.0 kan du inte lägga till fler builds i den. Nästa måste ha ett högre nummer. 3. **Varje tal jämförs som ett heltal.** 1.10 kommer efter 1.9, eftersom 10 är större än 9. En version 1.9 som laddas upp efter en godkänd 1.20 kommer att avvisas. Mitt råd: **behåll ett heltal som byggnummer som alltid ökar, utan att nollställa det till 1.** Att börja om på 1 är tillåtet på iPhone, men ett unikt nummer under hela appens livstid gör att du inte blandar ihop två builds i TestFlight. Det är vad jag ser i mina appar i fjärrläge: räknaren fortsätter från en version till nästa. ## Hantera version och build med Expo och EAS [Expos sida om versioner](https://docs.expo.dev/build-reference/app-versions/), uppdaterad 25 september 2026, delar upp rollerna. Versionen (`version` i app.json) är din: du ändrar den när du förbereder en ny release. Byggnumret (`ios.buildNumber`) kan du överlåta åt EAS. Expo nämner för övrigt att glömma att räkna upp det som en vanlig orsak till att uppladdningen avvisas. Allt ställs in i eas.json: ```json { "cli": { "appVersionSource": "remote" }, "build": { "production": { "autoIncrement": true } } } ``` - **`"remote"`**: EAS servrar håller byggnumret. Det är det rekommenderade beteendet sedan EAS CLI 12. Räknaren startar från värdet i din konfiguration, eller från 1, och därefter ignoreras `ios.buildNumber`. - **`"local"`**: din konfiguration gäller. Med `autoIncrement` ändrar EAS `ios.buildNumber` i din fil, och du måste committa ändringen vid varje bygge. - **`autoIncrement`**: [referensen för eas.json](https://docs.expo.dev/eas/json/) accepterar `true` eller `"buildNumber"` för builden, och `"version"` för att räkna upp sista siffran i versionen. I fjärrläge påpekar Expo att `"version"` inte stöds. Hos mig kör TradaZen och Nolera med `remote`. Solys ligger kvar på `local`: dess byggnummer finns i app.json och varje produktionsbygge räknar upp det i filen. **Båda fungerar, men fjärrläget tar bort risken för en bortglömd commit.** Två kommandon kompletterar upplägget. `eas build:version:set` initierar fjärräknaren: ange det senaste numret du skickat till Apple. `eas build:version:sync` kopierar fjärrvärdena till ditt projekt, användbart om du någon gång bygger med Xcode. Med EAS Update fungerar fjärrläget inte med policyn `nativeVersion`: Expo rekommenderar `appVersion`. ## ITMS-90062: versionen är redan godkänd Meddelandet ser ut så här (påhittade nummer): ```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 har redan godkänt version 1.4.0: du kan inte lägga till fler builds i den. **Höj versionen i app.json, till exempel till 1.4.1, och kör ett nytt bygge.** Att bara ändra byggnumret räcker inte. Om felet kommer tillbaka trots att `version` är uppdaterad, leta efter ett fält `ios.version`. Enligt [referensen för Expo-konfigurationen](https://docs.expo.dev/versions/latest/config/app/) har det företräde framför `version` för iOS. Samma lösning gäller för det närbesläktade felet ITMS-90186, ”Invalid Pre-Release Train”, som signalerar en version som är stängd för nya builds. ## ITMS-90189: Redundant Binary Upload Här är det byggnumret som strular: ```text ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded a build with build number '12' for version number '1.4.0'. ``` Paret 1.4.0 (12) finns redan hos Apple. Med Expo är det fyra orsaker som återkommer: - **Profilen du använder saknar `autoIncrement`.** Om du skapar en separat profil för TestFlight, som den för Nolera, lägg till alternativet där också. - **Fjärräknaren ligger efter.** Du bytte till `remote` efter manuella uppladdningar: kör `eas build:version:set` med det senaste numret Apple känner till. - **Commiten glömdes bort i lokalt läge.** Nästa bygge utgår från det gamla numret. - **Du skickar samma binär igen.** Med `eas submit`, välj den nya builden, inte den gamla. **Lösningen är alltid densamma: ett nytt bygge med ett högre nummer.** ## ”No builds available”: din build dyker inte upp Builden har skickats, men din appsida erbjuder den inte. Kontrollera i den här ordningen. 1. **Den bearbetas fortfarande.** Apple bearbetar varje build innan den visas och skickar ett mejl när det är klart. [Expo](https://docs.expo.dev/submit/ios/) talar i regel om 10 till 15 minuter. [Enligt Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata) ska du öppna ett ärende i Feedback Assistant om bearbetningen pågått längre än 24 timmar. 2. **Den väntar på din krypteringsdeklaration.** Det är statusen Missing Compliance, som beskrivs längre ner. 3. **Versionen stämmer inte.** En build i 1.4.1 hamnar inte under en appsida som förberetts för 1.5.0 i App Store Connect. Se till att de matchar. 4. **En version har släppts under tiden.** Enligt [hjälpen om att välja build](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) visar listan då bara builds som laddats upp efter den releasen. 5. **Det är testaren som inte ser den.** I TestFlight-appen betyder ”no builds available” ofta att builden inte ligger i någon grupp, väntar på betagranskning eller har gått ut. Detaljerna finns i [TestFlight för att testa din iPhone-app](https://devoria.fr/sv/blog/testflight-testa-iphone-app). ### Statusarna du behöver känna till Statusarna som oftast förklarar en saknad build, enligt [Apples lista](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing och Failed finns inte med där: det är uppladdningsstatusar som beskrivs i [uppföljningen av builds](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | Status | Vad den betyder | Din åtgärd | | ------------------ | ------------------------------ | ---------------------- | | Processing | Apple bearbetar builden | Vänta på mejlet | | Failed | Fel vid bearbetningen | Läs felet, skicka igen | | Missing Compliance | Kryptering ej deklarerad | Svara eller Info.plist | | Invalid Binary | Uppladdningen följer ej krav | Rätta, nytt bygge | | Expired | Över 90 dagar | Nytt bygge | | Ready to Submit | Redo för test eller granskning | Lägg till i en grupp | ### Deklarera krypteringen en gång för alla Utan nyckeln `ITSAppUsesNonExemptEncryption` ställer [Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) efterlevnadsfrågorna vid varje ny version. Med Expo heter fältet `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` betyder: ingen kryptering, eller bara undantagen kryptering. [Apple förtydligar](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations) att kryptering som är inbyggd i systemet, som HTTPS-anslutningar, i regel är undantagen, och att svaret även gäller dina bibliotek. Alla tre av mina appar deklarerar `false`. **Sätt bara `false` om det stämmer för din app: deklarationen är bindande för dig.** ## Kan man ändra numret på en build som redan skickats? Nej. Numret finns i den signerade binären: för att rätta det behövs ett nytt bygge. Det du kan ändra är vilken build som är kopplad till din version. Apple tillåter en build per version, men [du kan byta ut den hur många gånger du vill](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) fram tills du skickar in för granskning: 1. Öppna versionen i App Store Connect, avsnittet Build. 2. Hovra över den nuvarande builden och klicka på ta bort-knappen, minustecknet. 3. Klicka på lägg till-knappen, plustecknet, välj rätt build och spara. Att ta bort en build från en version raderar den inte från ditt konto. Om versionen redan är under granskning, [dra först tillbaka inskickningen](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): granskningen börjar då om från noll. ## Före nästa uppladdning Byggnumret är bara en av kontrollerna vid uppladdning. Byggavbildningen kan utlösa [ITMS-90725](https://devoria.fr/sv/blog/itms-90725-sdk-version-issue-expo), och signeringen har sina egna fallgropar, som beskrivs i [iOS-utvecklarcertifikat och provisioning profile](https://devoria.fr/sv/blog/ios-utvecklarcertifikat-provisioning-profile-expo). Hela kedjan, från bygge till TestFlight, finns i [publicera en iOS-app utan Mac](https://devoria.fr/sv/blog/publicera-ios-app-utan-mac-expo-eas), och granskningstiderna i [hur lång tid App Store-granskningen tar](https://devoria.fr/sv/blog/granskningstid-app-store-hur-lange). Alla steg är samlade på sidan [publicera en app på App Store](https://devoria.fr/sv/expertise/publicera-app-pa-app-store). Om du förbereder din första release, [gör den gratis diagnosen](https://devoria.fr/sv/diagnostic): den visar vad som blockerar i ditt projekt och skickar dig min checklista mot avslag från Apple. För att bygga appen, koppla in prenumerationer och publicera den följer [iOS & Android Kit](https://devoria.fr/sv/kits/ios) processen i fyra steg med startkoden från mina appar, i din egen takt. ## Vanliga frågor ### Vad är skillnaden mellan version och build number i App Store Connect? Versionen är det publika numret för din release, som 1.4.0. Build number identifierar en specifik binär som skickats till Apple för den versionen. Du kan skicka flera builds för samma version, var och en med sitt eget nummer. ### Måste man ändra byggnumret vid varje uppladdning? Ja, för samma version. Apple avvisar en andra uppladdning med samma par av version och byggnummer, det är felet ITMS-90189. Med EAS sköter `autoIncrement` det vid varje produktionsbygge. ### Måste byggnumret börja om på 1 för varje version? Det är inte obligatoriskt. På iPhone accepterar Apple ett lägre nummer för en ny version, eftersom bara paret måste vara unikt. En räknare som alltid ökar är ändå enklare att hålla koll på. ### Hur ändrar man build number i App Store Connect? Du kan inte ändra numret på en build som redan skickats. Däremot kan du byta ut builden som är kopplad till din version, från avsnittet Build på appsidan, så länge den inte är under granskning. För ett nytt nummer gör du ett nytt bygge. ### Varför dyker min build inte upp i App Store Connect? Oftast bearbetas den fortfarande eller väntar på din krypteringsdeklaration. Kontrollera också att dess version matchar den på din appsida. Om bearbetningen pågått längre än 24 timmar ber Apple dig öppna ett ärende. ## Ditt projekt [Review Kit](https://devoria.fr/sv/kits/app-review): Min checklista för App Store-granskningen, mina avslag från Apple och hur jag fixade dem, en för Google Play och tre Claude Code-skills. 549 kr. [iOS & Android Kit](https://devoria.fr/sv/kits/ios): Bygg din app för iPhone och Android med Claude Code: startkoden från mina appar, hela vägen till butikerna och alla kit. 1 099 kr. [Diagnos: det som skiljer dig från din iPhone-app](https://devoria.fr/sv/diagnostic): 7 frågor, 60 sekunder: du får veta vad som egentligen hindrar dig från att publicera din iPhone-app, din väg i 4 steg och kitet som passar dig.