# App Store Connect build number: versjon og buildnummer > Versjonen er nummeret kundene dine ser, build number identifiserer hver opplasting. Paret må være unikt: med Expo øker EAS buildnummeret for deg. Opprinnelig side: [App Store Connect build number: versjon og buildnummer](https://devoria.fr/no/blog/app-store-connect-build-number-versjon-buildnummer) Forfatter: [Mehdi Azizi](https://devoria.fr/no/mehdi-azizi) Publisert: 2026-11-04 Innhold sist revidert: 2026-11-04 Build number i App Store Connect er buildnummeret: nøkkelen `CFBundleVersion`, som identifiserer hver opplasting. Versjonen, `CFBundleShortVersionString`, er nummeret kundene dine ser i App Store. **Apple krever at paret versjon og buildnummer er unikt: et buildnummer kan bare brukes én gang for samme versjon.** Med Expo setter du versjonen selv, og EAS kan øke buildnummeret ved hvert produksjonsbuild. Denne guiden forklarer de to numrene, Apples regler, feilene ITMS-90062 og ITMS-90189, og hva du bør sjekke når buildet ditt ikke dukker opp. Jeg publiserer iOS-appene mine med Expo og EAS, blant dem Solys, TradaZen og Nolera. Innstillingene du ser lenger ned, er hentet fra `eas.json`-filene deres. ## Versjon og buildnummer: hva er forskjellen? To nøkler i Info.plist identifiserer appen din. [Apples dokumentasjon om CFBundleShortVersionString](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) beskriver den som versjonen brukeren ser: tre heltall skilt med punktum, som 10.14.1. [Dokumentasjonen om CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) handler om buildversjonen: ett til tre heltall, med bare sifre og punktum. | Element | iOS-nøkkel | Hvem ser den | Expo-felt | | ----------- | -------------------------- | ------------ | ----------------- | | Versjon | CFBundleShortVersionString | Kundene dine | `version` | | Buildnummer | CFBundleVersion | Du og Apple | `ios.buildNumber` | Et oppdiktet eksempel: for versjon 1.4.0 laster du opp build 12, 13 og 14 mens du tester, og så velger du ett av dem til gjennomgangen. [Hjelpesidene til App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) oppsummerer det slik: versjonen knytter buildet til oppføringen, buildnummeret identifiserer det overalt i systemet. ## Apples regler for økning 1. **Paret må være unikt.** Ifølge [dokumentasjonen til Xcode Cloud](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds) krever App Store Connect en unik kombinasjon av versjon og buildnummer. En iPhone-app kan altså starte på 1 igjen for en ny versjon. En Mac-app kan ikke: der må nummeret alltid øke. 2. **En godkjent versjon er stengt.** Når Apple har godkjent versjon 1.4.0, kan du ikke legge til flere build i den. Den neste må ha et høyere nummer. 3. **Hvert tall sammenlignes som et heltall.** 1.10 kommer etter 1.9, fordi 10 er større enn 9. En versjon 1.9 lastet opp etter en godkjent 1.20 blir avvist. Mitt råd: **behold et buildnummer som er et heltall og alltid øker, uten å nullstille det til 1.** Å starte på 1 igjen er lov på iPhone, men et nummer som er unikt gjennom hele appens levetid gjør at du ikke blander to build i TestFlight. Det er det jeg ser på appene mine i remote-modus: telleren fortsetter fra én versjon til den neste. ## Håndter versjon og build med Expo og EAS [Expos side om versjoner](https://docs.expo.dev/build-reference/app-versions/), oppdatert 25. september 2026, skiller rollene. Versjonen (`version` i app.json) er ditt ansvar: du endrer den når du forbereder en ny utgivelse. Buildnummeret (`ios.buildNumber`) kan du overlate til EAS. Expo nevner for øvrig at det å glemme å øke det er en vanlig grunn til at opplastingen avvises. Alt stilles inn i eas.json: ```json { "cli": { "appVersionSource": "remote" }, "build": { "production": { "autoIncrement": true } } } ``` - **`"remote"`**: EAS-serverne tar vare på buildnummeret. Det er anbefalt oppførsel siden EAS CLI 12. Telleren starter fra verdien i konfigurasjonen din, eller fra 1, og deretter ignoreres `ios.buildNumber`. - **`"local"`**: konfigurasjonen din gjelder. Med `autoIncrement` endrer EAS `ios.buildNumber` i filen din, og du må committe endringen ved hvert build. - **`autoIncrement`**: [referansen for eas.json](https://docs.expo.dev/eas/json/) godtar `true` eller `"buildNumber"` for buildet, og `"version"` for å øke det siste sifferet i versjonen. Expo presiserer at `"version"` ikke støttes i remote-modus. Hos meg kjører TradaZen og Nolera med `remote`. Solys står fortsatt på `local`: buildnummeret ligger i app.json, og hvert produksjonsbuild øker det i filen. **Begge fungerer, men remote-modus fjerner risikoen for en glemt commit.** To kommandoer fullfører oppsettet. `eas build:version:set` initialiserer den eksterne telleren: skriv inn det siste nummeret du sendte til Apple. `eas build:version:sync` kopierer de eksterne verdiene inn i prosjektet ditt, nyttig hvis du en dag bygger med Xcode. Med EAS Update fungerer ikke remote-modus sammen med policyen `nativeVersion`: Expo anbefaler `appVersion`. ## ITMS-90062: versjonen er allerede godkjent Meldingen ser slik ut (oppdiktede numre): ```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 allerede godkjent versjon 1.4.0: du kan ikke legge til flere build i den. **Øk versjonen i app.json, for eksempel til 1.4.1, og kjør et nytt build.** Det holder ikke å bare endre buildnummeret. Hvis feilen kommer tilbake selv om `version` er oppdatert, se etter et `ios.version`-felt. Ifølge [referansen for Expo-konfigurasjonen](https://docs.expo.dev/versions/latest/config/app/) overstyrer det `version` for iOS. Samme løsning gjelder for søsterfeilen ITMS-90186, «Invalid Pre-Release Train», som betyr at versjonen er stengt for nye build. ## ITMS-90189: Redundant Binary Upload Her er det buildnummeret som er problemet: ```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) finnes allerede hos Apple. Med Expo går fire årsaker igjen: - **Profilen du bruker, mangler `autoIncrement`.** Hvis du lager en egen profil for TestFlight, slik som den til Nolera, legg til innstillingen der også. - **Den eksterne telleren henger etter.** Du byttet til `remote` etter manuelle opplastinger: kjør `eas build:version:set` med det siste nummeret Apple kjenner til. - **Committen ble glemt i local-modus.** Neste build starter fra det gamle nummeret. - **Du sender den samme binærfilen på nytt.** Med `eas submit` velger du det nye buildet, ikke det gamle. **Løsningen er alltid den samme: et nytt build med et høyere nummer.** ## «No builds available»: buildet ditt dukker ikke opp Buildet er lastet opp, men oppføringen din tilbyr det ikke. Sjekk i denne rekkefølgen. 1. **Det behandles fortsatt.** Apple behandler hvert build før det vises, og sender deg en e-post når det er ferdig. [Expo](https://docs.expo.dev/submit/ios/) snakker vanligvis om 10 til 15 minutter. [Ifølge Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata) bør du åpne en sak i Feedback Assistant hvis behandlingen tar over 24 timer. 2. **Det venter på krypteringserklæringen din.** Det er statusen Missing Compliance, forklart lenger ned. 3. **Versjonen stemmer ikke.** Et build med 1.4.1 havner ikke under en oppføring som er satt opp som 1.5.0 i App Store Connect. Få dem til å samsvare. 4. **En versjon ble utgitt i mellomtiden.** Ifølge [hjelpesiden om valg av build](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) viser listen da bare build som er lastet opp etter den utgivelsen. 5. **Det er testeren som ikke ser det.** I TestFlight-appen betyr «no builds available» ofte at buildet ikke er i noen gruppe, venter på betagjennomgang eller har utløpt. Detaljene finner du i [TestFlight for å teste iPhone-appen din](https://devoria.fr/no/blog/testflight-teste-iphone-app-for-innsending). ### Statusene du bør kjenne Statusene som oftest forklarer et build som mangler, ifølge [Apples liste](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing og Failed står ikke der: de er opplastingsstatuser beskrevet i [oversikten over build](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | Status | Hva den betyr | Hva du gjør | | ------------------ | -------------------------- | ------------------------- | | Processing | Apple behandler buildet | Vent på e-posten | | Failed | Feil under behandlingen | Les feilen, last opp nytt | | Missing Compliance | Kryptering ikke oppgitt | Svar eller Info.plist | | Invalid Binary | Opplasting ikke godkjent | Rett opp, nytt build | | Expired | Over 90 dager | Nytt build | | Ready to Submit | Klar for test eller review | Legg det til i en gruppe | ### Oppgi kryptering én gang for alle Uten nøkkelen `ITSAppUsesNonExemptEncryption` stiller [Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) deg samsvarsspørsmålene ved hver nye versjon. I Expo heter feltet `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` betyr: ingen kryptering, eller bare unntatt kryptering. [Apple presiserer](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations) at kryptering innebygd i systemet, som HTTPS-tilkoblinger, vanligvis er unntatt, og at svaret også dekker bibliotekene dine. Alle de tre appene mine oppgir `false`. **Sett bare `false` hvis det stemmer for appen din: erklæringen er bindende for deg.** ## Kan man endre nummeret på et build som allerede er lastet opp? Nei. Nummeret er skrevet inn i den signerte binærfilen: for å rette det trenger du et nytt build. Det du kan endre, er hvilket build som er knyttet til versjonen din. Apple tillater bare ett build per versjon, men [du kan bytte det ut så mange ganger du vil](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) frem til du sender den til gjennomgang: 1. Åpne versjonen i App Store Connect, under Build. 2. Hold musen over det nåværende buildet og klikk på sletteknappen, minustegnet. 3. Klikk på legg til-knappen, plusstegnet, velg riktig build og lagre. Å fjerne et build fra en versjon sletter det ikke fra kontoen din. Hvis versjonen allerede er til gjennomgang, [trekk først tilbake innsendingen](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): gjennomgangen starter da helt på nytt. ## Før neste opplasting Buildnummeret er bare én av kontrollene ved opplasting. Build-imaget kan utløse [ITMS-90725](https://devoria.fr/no/blog/itms-90725-sdk-version-issue-expo), og signeringen har sine egne feller, forklart i [iOS-utviklersertifikat og provisioning profile](https://devoria.fr/no/blog/ios-utviklersertifikat-provisioning-profile-expo). Hele kjeden, fra build til TestFlight, finner du i [publisere en iOS-app uten Mac](https://devoria.fr/no/blog/publisere-ios-app-uten-mac-expo-eas), og ventetiden for gjennomgang i [hvor lang tid App Store-gjennomgangen tar](https://devoria.fr/no/blog/app-store-godkjenning-hvor-lang-tid). Alle stegene er samlet på siden [publisere en app i App Store](https://devoria.fr/no/expertise/publisere-app-pa-app-store). Hvis du forbereder din første utgivelse, [ta den gratis diagnosen](https://devoria.fr/no/diagnostic): den forteller deg hva som stopper prosjektet ditt, og sender deg sjekklisten min mot avvisning fra Apple. For å bygge appen, koble på abonnementer og publisere den følger [iOS & Android Kit](https://devoria.fr/no/kits/ios) løpet i fire steg med startkoden fra appene mine, i ditt eget tempo. ## Ofte stilte spørsmål ### Hva er forskjellen på versjon og build number i App Store Connect? Versjonen er det offentlige nummeret på utgivelsen din, som 1.4.0. Build number identifiserer én bestemt binærfil sendt til Apple for den versjonen. Du kan laste opp flere build for samme versjon, hvert med sitt eget nummer. ### Må jeg endre buildnummeret ved hver opplasting? Ja, innenfor samme versjon. Apple avviser en ny opplasting med samme par av versjon og buildnummer, det er feilen ITMS-90189. Med EAS tar `autoIncrement` seg av det ved hvert produksjonsbuild. ### Må buildnummeret starte på 1 igjen for hver versjon? Nei, det er ikke påkrevd. På iPhone godtar Apple et lavere nummer for en ny versjon, fordi det bare er paret som må være unikt. En teller som alltid øker, er likevel enklere å holde oversikt over. ### Hvordan endrer jeg build number i App Store Connect? Du kan ikke endre nummeret på et build som allerede er lastet opp. Du kan derimot bytte ut buildet som er knyttet til versjonen, under Build i oppføringen, så lenge den ikke er til gjennomgang. Vil du ha et nytt nummer, må du lage et nytt build. ### Hvorfor dukker ikke buildet mitt opp i App Store Connect? Som oftest behandles det fortsatt, eller det venter på krypteringserklæringen din. Sjekk også at versjonen samsvarer med versjonen i oppføringen. Tar behandlingen over 24 timer, ber Apple deg åpne en sak. ## Prosjektet ditt [Review Kit](https://devoria.fr/no/kits/app-review): Sjekklisten min for App Store-gjennomgang, Apples avslag på appene mine med rettelser, sjekklisten for Google Play og tre Claude Code-skills. 499 kr. [iOS & Android Kit](https://devoria.fr/no/kits/ios): Lag din iPhone- og Android-app med Claude Code: startkoden fra appene mine, veien helt til butikkene og alle kitene. 999 kr. [Diagnose: dette står mellom deg og iPhone-appen din](https://devoria.fr/no/diagnostic): 7 spørsmål, 60 sekunder: du får vite hva som egentlig hindrer deg i å publisere iPhone-appen din, veien din i 4 steg og kitet som passer deg.