Buildnummer App Store Connect: versie en buildnummer

Het build number van App Store Connect is het buildnummer: de sleutel CFBundleVersion, die elke upload identificeert. De versie, CFBundleShortVersionString, is het nummer dat je klanten in de App Store zien. Apple eist dat het paar versie en buildnummer uniek is: een buildnummer gebruik je maar één keer per versie.

Met Expo stel je de versie zelf in en kan EAS het buildnummer bij elke productiebuild verhogen. Deze gids legt beide nummers uit, de regels van Apple, de fouten ITMS-90062 en ITMS-90189, en wat je moet checken als je build niet verschijnt.

Ik publiceer mijn iOS-apps met Expo en EAS, waaronder Solys, TradaZen en Nolera. De instellingen hieronder komen uit hun eas.json-bestanden.

Versie en buildnummer: wat is het verschil?

Twee sleutels in de Info.plist identificeren je app. De documentatie van Apple over CFBundleShortVersionString beschrijft die als de versie die de gebruiker ziet: drie gehele getallen gescheiden door punten, zoals 10.14.1. Die over CFBundleVersion gaat over de versie van de build: één tot drie gehele getallen, alleen cijfers en punten.

Onderdeel	iOS-sleutel	Wie ziet het	Expo-veld
Versie	CFBundleShortVersionString	Je klanten	version
Buildnummer	CFBundleVersion	Jij en Apple	ios.buildNumber

Fictief voorbeeld: voor versie 1.4.0 upload je tijdens het testen builds 12, 13 en 14, en daarna kies je er één voor de review. De hulp van App Store Connect vat het samen: de versie koppelt de build aan je app-pagina, het buildnummer identificeert hem overal in het systeem.

De ophoogregels van Apple

1. Het paar moet uniek zijn. Volgens de documentatie van Xcode Cloud eist App Store Connect een unieke combinatie van versie en buildnummer. Een iPhone-app mag dus voor een nieuwe versie weer bij 1 beginnen. Een Mac-app niet: daar moet het nummer altijd omhoog.
2. Een goedgekeurde versie is gesloten. Zodra Apple versie 1.4.0 heeft goedgekeurd, kun je er geen build meer aan toevoegen. De volgende moet een hoger nummer hebben.
3. Elk getal wordt als geheel getal vergeleken. 1.10 komt na 1.9, want 10 is groter dan 9. Een versie 1.9 die je na een goedgekeurde 1.20 uploadt, wordt geweigerd.

Mijn advies: houd één geheel buildnummer aan dat altijd stijgt, zonder het terug te zetten naar 1. Opnieuw bij 1 beginnen mag op iPhone, maar een uniek nummer over de hele levensduur van de app voorkomt dat je twee builds in TestFlight door elkaar haalt. Dat zie ik ook bij mijn apps in remote-modus: de teller loopt door van versie naar versie.

Versie en build beheren met Expo en EAS

De pagina van Expo over versies, bijgewerkt op 25 september 2026, scheidt de rollen. De versie (version in app.json) blijft van jou: die pas je aan als je een nieuwe release voorbereidt. Het buildnummer (ios.buildNumber) kun je aan EAS overlaten. Expo noemt vergeten op te hogen trouwens als een veelvoorkomende reden dat een upload wordt geweigerd.

Alles stel je in via eas.json:

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

• "remote": de servers van EAS bewaren het buildnummer. Dit is het aanbevolen gedrag sinds EAS CLI 12. De teller start vanaf de waarde in je configuratie, of vanaf 1, en daarna wordt ios.buildNumber genegeerd.
• "local": je configuratie is leidend. Met autoIncrement past EAS ios.buildNumber in je bestand aan, en die wijziging moet je bij elke build committen.
• autoIncrement: de referentie van eas.json accepteert true of "buildNumber" voor de build, en "version" om het laatste cijfer van de versie te verhogen. In remote-modus geeft Expo aan dat "version" niet wordt ondersteund.

Bij mij staan TradaZen en Nolera op remote. Solys staat nog op local: het buildnummer staat in app.json en elke productiebuild verhoogt het in het bestand. Beide werken, maar de remote-modus haalt het risico van een vergeten commit weg.

Twee commando's maken het compleet. eas build:version:set initialiseert de remote teller: vul het laatste nummer in dat je naar Apple hebt gestuurd. eas build:version:sync kopieert de remote waarden naar je project, handig als je ooit met Xcode compileert. Met EAS Update werkt de remote-modus niet met het beleid nativeVersion: Expo raadt appVersion aan.

ITMS-90062: de versie is al goedgekeurd

De melding ziet er zo uit (fictieve nummers):

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 heeft versie 1.4.0 al goedgekeurd: je kunt er geen build meer aan toevoegen. Verhoog de versie in app.json, bijvoorbeeld naar 1.4.1, en start een nieuwe build. Alleen het buildnummer aanpassen is niet genoeg.

Komt de fout terug terwijl version klopt, zoek dan naar een veld ios.version. Volgens de referentie van de Expo-configuratie gaat dat voor iOS boven version. Dezelfde oplossing geldt voor de verwante fout ITMS-90186, "Invalid Pre-Release Train", die een versie aangeeft die gesloten is voor nieuwe builds.

ITMS-90189: Redundant Binary Upload

Hier is het buildnummer het probleem:

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

Het paar 1.4.0 (12) bestaat al bij Apple. Met Expo zie je vier oorzaken terugkomen:

• Het gebruikte profiel heeft geen autoIncrement. Maak je een apart profiel voor TestFlight, zoals dat van Nolera, zet de optie er dan weer in.
• De remote teller loopt achter. Je bent naar remote overgestapt na handmatige uploads: draai eas build:version:set met het laatste nummer dat Apple kent.
• De commit is vergeten in local-modus. De volgende build start weer vanaf het oude nummer.
• Je stuurt dezelfde binary opnieuw. Kies bij eas submit de nieuwe build, niet de oude.

De oplossing is altijd dezelfde: een nieuwe build met een hoger nummer.

"No builds available": je build verschijnt niet

De build is verstuurd, maar je app-pagina biedt hem niet aan. Check in deze volgorde.

1. Hij wordt nog verwerkt. Apple verwerkt elke build voordat hij zichtbaar wordt en stuurt je aan het eind een e-mail. Expo noemt meestal 10 tot 15 minuten. Volgens Apple moet je na meer dan 24 uur verwerking een ticket openen via Feedback Assistant.
2. Hij wacht op je versleutelingsverklaring. Dat is de status Missing Compliance, verderop uitgelegd.
3. De versie komt niet overeen. Een build met 1.4.1 komt niet terecht onder een pagina die in App Store Connect als 1.5.0 is voorbereid. Zorg dat ze gelijk zijn.
4. Er is intussen een versie uitgebracht. Volgens de hulp over het kiezen van een build toont de lijst dan alleen builds die sinds die release zijn geüpload.
5. De tester ziet hem niet. In de TestFlight-app betekent "no builds available" vaak dat de build in geen enkele groep zit, op de bètareview wacht of verlopen is. De details staan in TestFlight om je iPhone-app te testen.

De statussen die je moet kennen

De statussen die een ontbrekende build het vaakst verklaren, volgens de lijst van Apple. Processing en Failed staan er niet in: dat zijn uploadstatussen, beschreven in het volgen van builds.

Status	Wat het betekent	Jouw oplossing
Processing	Apple verwerkt de build	Wachten op de e-mail
Failed	Fout bij verwerking	Fout lezen, opnieuw sturen
Missing Compliance	Versleuteling niet gemeld	Antwoorden of Info.plist
Invalid Binary	Upload voldoet niet	Corrigeren, nieuwe build
Expired	Meer dan 90 dagen	Nieuwe build
Ready to Submit	Klaar voor test of review	Aan een groep toevoegen

Versleuteling voor eens en altijd melden

Zonder de sleutel ITSAppUsesNonExemptEncryption stelt Apple je bij elke nieuwe versie de compliancevragen. In Expo heet het veld ios.config.usesNonExemptEncryption:

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

false betekent: geen versleuteling, of alleen vrijgestelde versleuteling. Apple geeft aan dat versleuteling die in het systeem zit, zoals HTTPS-verbindingen, meestal vrijgesteld is, en dat het antwoord ook je bibliotheken dekt. Mijn drie apps geven false op. Zet alleen false als het voor jouw app klopt: je bent gebonden aan die verklaring.

Kun je het nummer van een al geüploade build wijzigen?

Nee. Het nummer zit in de ondertekende binary: om het te corrigeren heb je een nieuwe build nodig.

Wat je wel kunt wijzigen, is welke build aan je versie gekoppeld is. Apple staat één build per versie toe, maar je kunt die zo vaak vervangen als je wilt tot je hem voor review indient:

1. Open de versie in App Store Connect, sectie Build.
2. Ga met je muis over de huidige build en klik op de verwijderknop, het minteken.
3. Klik op de toevoegknop, het plusteken, kies de juiste build en sla op.

Een build loskoppelen van een versie verwijdert hem niet uit je account. Staat de versie al in review, trek dan eerst de inzending in: de review begint dan opnieuw.

Voor je volgende upload

Het buildnummer is maar één van de controles bij het uploaden. De build-image kan ITMS-90725 veroorzaken, en het ondertekenen heeft zijn eigen valkuilen, uitgelegd in iOS-ontwikkelaarscertificaat en provisioning profile. De volledige keten, van build tot TestFlight, staat in een iOS-app publiceren zonder Mac, en de reviewtijden in hoe lang duurt de App Store-review. Alle stappen staan bij elkaar op de pagina een app publiceren in de App Store.

Bereid je je eerste release voor? Doe de gratis diagnose: die vertelt je wat er in je project blokkeert en stuurt je mijn checklist tegen afwijzingen door Apple. Om de app te bouwen, abonnementen te koppelen en te publiceren, volgt de iOS & Android Kit het traject in vier stappen met de Starter Code van mijn apps, in je eigen tempo.

Veelgestelde vragen

Wat is het verschil tussen versie en build number in App Store Connect?

De versie is het openbare nummer van je release, zoals 1.4.0. Het build number identificeert een specifieke binary die je voor die versie naar Apple stuurt. Je kunt meerdere builds voor dezelfde versie uploaden, elk met een eigen nummer.

Moet je het buildnummer bij elke upload veranderen?

Ja, voor dezelfde versie. Apple weigert een tweede upload met hetzelfde paar versie en buildnummer, dat is fout ITMS-90189. Met EAS regelt autoIncrement dat bij elke productiebuild.

Moet het buildnummer bij elke versie weer bij 1 beginnen?

Dat hoeft niet. Op iPhone accepteert Apple een lager nummer voor een nieuwe versie, want alleen het paar moet uniek zijn. Een teller die altijd stijgt is wel makkelijker bij te houden.

Hoe verander je het build number in App Store Connect?

Het nummer van een al geüploade build kun je niet wijzigen. Je kunt wel de build vervangen die aan je versie hangt, via de sectie Build van de app-pagina, zolang die niet in review is. Voor een nieuw nummer maak je een nieuwe build.

Waarom verschijnt mijn build niet in App Store Connect?

Meestal wordt hij nog verwerkt of wacht hij op je versleutelingsverklaring. Check ook of de versie overeenkomt met die van je app-pagina. Na meer dan 24 uur verwerking vraagt Apple je een ticket te openen.