App Store Connect build number: version og buildnummer

App Store Connects build number er buildnummeret: nøglen CFBundleVersion, som identificerer hver upload. Versionen, CFBundleShortVersionString, er det nummer, dine kunder ser i App Store. Apple kræver, at parret af version og buildnummer er unikt: et buildnummer kan kun bruges én gang til den samme version.

Med Expo bestemmer du selv versionen, og EAS kan hæve buildnummeret ved hvert production-build. Denne guide forklarer de to numre, Apples regler, fejlene ITMS-90062 og ITMS-90189, og hvad du skal tjekke, når dit build ikke dukker op.

Jeg udgiver mine iOS-apps med Expo og EAS, blandt andet Solys, TradaZen og Nolera. Indstillingerne længere nede er dem fra deres eas.json-filer.

Version og buildnummer: hvad er forskellen?

To nøgler i Info.plist identificerer din app. Apples dokumentation om CFBundleShortVersionString beskriver den som den version, brugeren ser: tre heltal adskilt af punktummer, f.eks. 10.14.1. Dokumentationen om CFBundleVersion taler om buildets version: et til tre heltal, kun med cifre og punktummer.

Element	iOS-nøgle	Hvem ser den	Expo-felt
Version	CFBundleShortVersionString	Dine kunder	version
Buildnummer	CFBundleVersion	Dig og Apple	ios.buildNumber

Et opdigtet eksempel: til version 1.4.0 uploader du build 12, 13 og 14, mens du tester, og vælger så ét af dem til review. App Store Connects hjælp opsummerer det: versionen knytter buildet til dets side, og buildnummeret identificerer det overalt i systemet.

Apples regler for at hæve numrene

1. Parret skal være unikt. Ifølge Xcode Clouds dokumentation kræver App Store Connect en unik kombination af version og buildnummer. En iPhone-app kan altså starte forfra på 1 ved en ny version. En Mac-app kan ikke: dens nummer skal altid stige.
2. En godkendt version er lukket. Når Apple har godkendt version 1.4.0, kan du ikke længere tilføje builds til den. Den næste skal have et højere nummer.
3. Hvert tal sammenlignes som et heltal. 1.10 kommer efter 1.9, fordi 10 er større end 9. En version 1.9 uploadet efter en godkendt 1.20 bliver afvist.

Mit råd: brug et buildnummer i form af et heltal, der altid stiger, og nulstil det aldrig til 1. Det er tilladt at starte forfra på iPhone, men et unikt nummer gennem hele appens levetid gør, at du ikke forveksler to builds i TestFlight. Det er det, jeg ser på mine apps i remote-tilstand: tælleren fortsætter fra version til version.

Håndter version og build med Expo og EAS

Expos side om versioner, opdateret 25. september 2026, deler rollerne op. Versionen (version i app.json) er din: du ændrer den, når du forbereder en ny udgivelse. Buildnummeret (ios.buildNumber) kan du overlade til EAS. Expo nævner i øvrigt, at man glemmer at hæve det, som en almindelig årsag til afvisning ved upload.

Det hele indstilles i eas.json:

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

• "remote": EAS' servere holder styr på buildnummeret. Det er den anbefalede adfærd siden EAS CLI 12. Tælleren starter fra værdien i din konfiguration, eller fra 1, og derefter ignoreres ios.buildNumber.
• "local": din konfiguration er gældende. Med autoIncrement ændrer EAS ios.buildNumber i din fil, og du skal committe ændringen ved hvert build.
• autoIncrement: eas.json-referencen accepterer true eller "buildNumber" til buildet og "version" til at hæve versionens sidste ciffer. I remote-tilstand understøttes "version" ikke, præciserer Expo.

Hos mig kører TradaZen og Nolera med remote. Solys er blevet på local: dens buildnummer ligger i app.json, og hvert production-build hæver det i filen. Begge dele virker, men remote-tilstanden fjerner risikoen for et glemt commit.

To kommandoer gør opsætningen komplet. eas build:version:set initialiserer den eksterne tæller: indtast det sidste nummer, du har sendt til Apple. eas build:version:sync kopierer de eksterne værdier ind i dit projekt, hvilket er nyttigt, hvis du en dag bygger med Xcode. Med EAS Update virker remote-tilstanden ikke sammen med politikken nativeVersion: Expo anbefaler appVersion.

ITMS-90062: versionen er allerede godkendt

Beskeden ser sådan her ud (opdigtede numre):

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 godkendt version 1.4.0: du kan ikke længere tilføje builds til den. Hæv versionen i app.json, f.eks. til 1.4.1, og kør et nyt build. Det er ikke nok kun at ændre buildnummeret.

Hvis fejlen kommer igen, selvom version er opdateret, så led efter et ios.version-felt. Ifølge referencen for Expo-konfigurationen har det forrang frem for version på iOS. Samme løsning gælder for den beslægtede fejl ITMS-90186, "Invalid Pre-Release Train", som melder, at en version er lukket for nye builds.

ITMS-90189: Redundant Binary Upload

Her er det buildnummeret, der driller:

ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded
a build with build number '12' for version number '1.4.0'.

Parret 1.4.0 (12) findes allerede hos Apple. Med Expo går fire årsager igen:

• Den profil, du bruger, har ikke autoIncrement. Hvis du laver en separat profil til TestFlight, som den til Nolera, så tilføj indstillingen der også.
• Den eksterne tæller er bagud. Du skiftede til remote efter manuelle uploads: kør eas build:version:set med det sidste nummer, Apple kender.
• Commit'et blev glemt i local-tilstand. Det næste build starter igen fra det gamle nummer.
• Du sender den samme binærfil igen. Med eas submit skal du vælge det nye build, ikke det gamle.

Løsningen er altid den samme: et nyt build med et højere nummer.

"No builds available": dit build dukker ikke op

Buildet er sendt, men din side tilbyder det ikke. Tjek i denne rækkefølge.

1. Det bliver stadig behandlet. Apple behandler hvert build, før det vises, og sender dig en e-mail, når det er færdigt. Expo taler generelt om 10 til 15 minutter. Ifølge Apple skal du oprette en sag i Feedback Assistant, hvis det har været under behandling i over 24 timer.
2. Det venter på din krypteringserklæring. Det er statussen Missing Compliance, som gennemgås længere nede.
3. Versionen passer ikke. Et build i 1.4.1 havner ikke under en side, der er forberedt som 1.5.0 i App Store Connect. Gør de to ens.
4. En version er udkommet i mellemtiden. Ifølge hjælpen om valg af build viser listen så kun builds, der er uploadet siden den udgivelse.
5. Det er testeren, der ikke kan se det. I TestFlight-appen betyder "no builds available" ofte, at buildet ikke er i nogen gruppe, venter på beta-review eller er udløbet. Detaljerne finder du i TestFlight til at teste din iPhone-app.

De statusser, du skal kende

Her er de statusser, der oftest forklarer et manglende build, ifølge Apples liste. Processing og Failed står ikke på den: det er upload-statusser, der beskrives i opfølgningen på builds.

Status	Hvad den betyder	Din løsning
Processing	Apple behandler buildet	Vent på e-mailen
Failed	Fejl under behandlingen	Læs fejlen, send igen
Missing Compliance	Kryptering ikke erklæret	Svar eller Info.plist
Invalid Binary	Upload ikke i orden	Ret fejlen, nyt build
Expired	Over 90 dage gammelt	Nyt build
Ready to Submit	Klar til test eller review	Føj det til en gruppe

Erklær kryptering én gang for alle

Uden nøglen ITSAppUsesNonExemptEncryption stiller Apple dig compliance-spørgsmålene ved hver ny version. Med Expo hedder feltet ios.config.usesNonExemptEncryption:

{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}

false betyder: ingen kryptering eller kun undtaget kryptering. Apple præciserer, at kryptering indbygget i systemet, som HTTPS-forbindelser, generelt er undtaget, og at svaret også dækker dine biblioteker. Alle tre af mine apps erklærer false. Sæt kun false, hvis det er sandt for din app: erklæringen forpligter dig.

Kan man ændre nummeret på et build, der allerede er sendt?

Nej. Nummeret er skrevet ind i den signerede binærfil: for at rette det skal du lave et nyt build.

Det, du kan ændre, er det build, der er knyttet til din version. Apple tillader kun ét build pr. version, men du kan udskifte det så mange gange, du vil, indtil du sender til review:

1. Åbn versionen i App Store Connect, sektionen Build.
2. Hold musen over det nuværende build, og klik på slet-knappen, minustegnet.
3. Klik på tilføj-knappen, plustegnet, vælg det rigtige build, og gem.

Når du fjerner et build fra en version, bliver det ikke slettet fra din konto. Hvis versionen allerede er i review, skal du først trække indsendelsen tilbage: så starter reviewet forfra.

Før din næste upload

Buildnummeret er kun ét af tjekkene ved upload. Build-imaget kan udløse ITMS-90725, og signeringen har sine egne faldgruber, som gennemgås i iOS-udviklercertifikat og provisioning profile. Hele kæden, fra build til TestFlight, finder du i udgiv en iOS-app uden Mac, og review-tiderne i hvor lang tid tager App Store-godkendelse. Alle trinene er samlet på siden udgiv en app i App Store.

Hvis du forbereder din første udgivelse, så tag den gratis diagnose: den fortæller dig, hvad der blokerer i dit projekt, og sender dig min tjekliste mod afvisninger fra Apple. Til at bygge appen, koble abonnementer på og udgive den følger iOS & Android Kit forløbet i fire trin med startkoden fra mine apps, i dit eget tempo.

Ofte stillede spørgsmål

Hvad er forskellen på version og build number i App Store Connect?

Versionen er det offentlige nummer for din udgivelse, f.eks. 1.4.0. Build number identificerer en bestemt binærfil, der er sendt til Apple for den version. Du kan sende flere builds til den samme version, hver med sit eget nummer.

Skal man ændre buildnummeret ved hver upload?

Ja, for den samme version. Apple afviser en ny upload med det samme par af version og buildnummer, det er fejlen ITMS-90189. Med EAS klarer autoIncrement det ved hvert production-build.

Skal buildnummeret starte forfra på 1 ved hver version?

Det er ikke et krav. På iPhone accepterer Apple et lavere nummer til en ny version, fordi det kun er parret, der skal være unikt. En tæller, der altid stiger, er dog nemmere at holde styr på.

Hvordan ændrer man build number i App Store Connect?

Du kan ikke ændre nummeret på et build, der allerede er sendt. Til gengæld kan du udskifte det build, der er knyttet til din version, fra sektionen Build på siden, så længe den ikke er i review. Vil du have et nyt nummer, skal du lave et nyt build.

Hvorfor dukker mit build ikke op i App Store Connect?

Oftest bliver det stadig behandlet eller venter på din krypteringserklæring. Tjek også, at dets version passer til den på din side. Har det været under behandling i over 24 timer, beder Apple dig oprette en sag.