App Store Connect Build-Nummer: Version und Build erklärt

Die Build-Nummer in App Store Connect ist der Schlüssel CFBundleVersion, der jeden Upload kennzeichnet. Die Version, CFBundleShortVersionString, ist die Nummer, die deine Kunden im App Store sehen. Apple verlangt, dass die Kombination aus Version und Build-Nummer eindeutig ist: Eine Build-Nummer gibt es pro Version nur einmal.

Mit Expo legst du die Version selbst fest, und EAS kann die Build-Nummer bei jedem Production-Build hochzählen. Dieser Guide erklärt beide Nummern, Apples Regeln, die Fehler ITMS-90062 und ITMS-90189 und was du prüfen solltest, wenn dein Build nicht auftaucht.

Ich veröffentliche meine iOS-Apps mit Expo und EAS, darunter Solys, TradaZen und Nolera. Die Einstellungen weiter unten stammen aus ihren eas.json-Dateien.

Version und Build-Nummer: Was ist der Unterschied?

Zwei Schlüssel in der Info.plist identifizieren deine App. Apples Dokumentation zu CFBundleShortVersionString beschreibt sie als die für Nutzer sichtbare Version: drei durch Punkte getrennte Ganzzahlen, etwa 10.14.1. Die Seite zu CFBundleVersion spricht von der Build-Version: eine bis drei Ganzzahlen, nur Ziffern und Punkte.

Element	iOS-Schlüssel	Wer sie sieht	Expo-Feld
Version	CFBundleShortVersionString	Deine Kunden	version
Build-Nummer	CFBundleVersion	Du und Apple	ios.buildNumber

Fiktives Beispiel: Für Version 1.4.0 lädst du während deiner Tests die Builds 12, 13 und 14 hoch und wählst dann einen davon für das Review aus. Die Hilfe von App Store Connect fasst es so zusammen: Die Version ordnet den Build seinem Eintrag zu, die Build-Nummer identifiziert ihn überall im System.

Apples Regeln zum Hochzählen

1. Die Kombination muss eindeutig sein. Laut der Xcode-Cloud-Dokumentation verlangt App Store Connect eine eindeutige Kombination aus Version und Build-Nummer. Eine iPhone-App kann bei einer neuen Version also wieder bei 1 anfangen. Eine Mac-App nicht: Ihre Nummer muss immer steigen.
2. Eine freigegebene Version ist geschlossen. Sobald Apple Version 1.4.0 freigegeben hat, kannst du ihr keinen Build mehr hinzufügen. Die nächste muss eine höhere Nummer tragen.
3. Jede Zahl wird als Ganzzahl verglichen. 1.10 kommt nach 1.9, weil 10 größer als 9 ist. Eine Version 1.9, die nach einer freigegebenen 1.20 hochgeladen wird, wird abgelehnt.

Mein Tipp: Nutze eine ganzzahlige Build-Nummer, die immer steigt, und setz sie nie auf 1 zurück. Auf dem iPhone ist der Neustart bei 1 erlaubt, aber eine eindeutige Nummer über die ganze Lebensdauer der App verhindert, dass du in TestFlight zwei Builds verwechselst. Genau das sehe ich bei meinen Apps im Remote-Modus: Der Zähler läuft von Version zu Version weiter.

Version und Build mit Expo und EAS verwalten

Expos Seite zu Versionen, aktualisiert am 25. September 2026, trennt die Rollen. Die Version (version in app.json) bleibt bei dir: Du änderst sie, wenn du ein neues Release vorbereitest. Die Build-Nummer (ios.buildNumber) kannst du EAS überlassen. Expo nennt das vergessene Hochzählen übrigens als häufigen Grund für abgelehnte Uploads.

Alles wird in eas.json eingestellt:

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

• "remote": Die EAS-Server verwalten die Build-Nummer. Das ist seit EAS CLI 12 das empfohlene Verhalten. Der Zähler startet beim Wert aus deiner Konfiguration oder bei 1, danach wird ios.buildNumber ignoriert.
• "local": Deine Konfiguration ist maßgeblich. Mit autoIncrement ändert EAS ios.buildNumber in deiner Datei, und du musst diese Änderung bei jedem Build committen.
• autoIncrement: Die eas.json-Referenz akzeptiert true oder "buildNumber" für den Build und "version", um die letzte Stelle der Version hochzuzählen. Im Remote-Modus wird "version" laut Expo nicht unterstützt.

Bei mir laufen TradaZen und Nolera auf remote. Solys ist auf local geblieben: Ihre Build-Nummer steht in app.json, und jeder Production-Build zählt sie in der Datei hoch. Beides funktioniert, aber der Remote-Modus beseitigt das Risiko eines vergessenen Commits.

Zwei Befehle ergänzen das Ganze. eas build:version:set initialisiert den Remote-Zähler: Gib die letzte an Apple gesendete Nummer ein. eas build:version:sync kopiert die Remote-Werte in dein Projekt, praktisch, falls du irgendwann mit Xcode kompilierst. Mit EAS Update funktioniert der Remote-Modus nicht mit der Policy nativeVersion: Expo empfiehlt appVersion.

ITMS-90062: Die Version ist bereits freigegeben

Die Meldung sieht so aus (fiktive Nummern):

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 hat Version 1.4.0 schon freigegeben: Du kannst keinen Build mehr hinzufügen. Erhöhe die Version in app.json, zum Beispiel auf 1.4.1, und starte einen neuen Build. Nur die Build-Nummer zu ändern reicht nicht.

Kommt der Fehler wieder, obwohl version aktuell ist, such nach einem Feld ios.version. Laut der Referenz der Expo-Konfiguration hat es auf iOS Vorrang vor version. Dieselbe Lösung gilt für den verwandten Fehler ITMS-90186, „Invalid Pre-Release Train“, der eine für neue Builds geschlossene Version meldet.

ITMS-90189: Redundant Binary Upload

Hier hakt es an der Build-Nummer:

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

Die Kombination 1.4.0 (12) existiert bei Apple bereits. Mit Expo gibt es vier typische Ursachen:

• Das verwendete Profil hat kein autoIncrement. Wenn du ein eigenes Profil für TestFlight anlegst, wie bei Nolera, setz die Option dort ebenfalls.
• Der Remote-Zähler hinkt hinterher. Du bist nach manuellen Uploads auf remote umgestiegen: Führe eas build:version:set mit der letzten Apple bekannten Nummer aus.
• Im lokalen Modus wurde der Commit vergessen. Der nächste Build startet wieder bei der alten Nummer.
• Du schickst dasselbe Binary erneut. Wähle bei eas submit den neuen Build, nicht den alten.

Die Lösung ist immer dieselbe: ein neuer Build mit höherer Nummer.

„No builds available“: Dein Build taucht nicht auf

Der Build ist hochgeladen, aber dein Eintrag bietet ihn nicht an. Prüfe in dieser Reihenfolge.

1. Er wird noch verarbeitet. Apple verarbeitet jeden Build, bevor er angezeigt wird, und schickt dir am Ende eine E-Mail. Expo spricht meist von 10 bis 15 Minuten. Laut Apple solltest du nach mehr als 24 Stunden in Verarbeitung ein Ticket im Feedback Assistant eröffnen.
2. Er wartet auf deine Verschlüsselungsangabe. Das ist der Status Missing Compliance, weiter unten erklärt.
3. Die Version passt nicht. Ein Build mit 1.4.1 landet nicht unter einem Eintrag, der in App Store Connect als 1.5.0 vorbereitet ist. Gleiche beide an.
4. Zwischendurch wurde eine Version veröffentlicht. Laut der Hilfe zur Build-Auswahl zeigt die Liste dann nur Builds, die seit diesem Release hochgeladen wurden.
5. Der Tester sieht ihn nicht. In der TestFlight-App bedeutet „no builds available“ oft, dass der Build in keiner Gruppe ist, auf das Beta-Review wartet oder abgelaufen ist. Details findest du in TestFlight zum Testen deiner iPhone-App.

Die wichtigsten Status

Die Status, die einen fehlenden Build am häufigsten erklären, laut Apples Liste. Processing und Failed stehen nicht darin: Das sind Upload-Status, beschrieben in der Build-Übersicht.

Status	Bedeutung	Deine Lösung
Processing	Apple verarbeitet den Build	Auf die E-Mail warten
Failed	Fehler bei der Verarbeitung	Fehler lesen, neu senden
Missing Compliance	Verschlüsselung nicht angegeben	Antworten oder Info.plist
Invalid Binary	Upload nicht konform	Korrigieren, neuer Build
Expired	90 Tage überschritten	Neuer Build
Ready to Submit	Bereit für Test oder Review	Zu einer Gruppe hinzufügen

Verschlüsselung ein für alle Mal angeben

Ohne den Schlüssel ITSAppUsesNonExemptEncryption stellt dir Apple bei jeder neuen Version die Compliance-Fragen. Mit Expo heißt das Feld ios.config.usesNonExemptEncryption:

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

false bedeutet: keine Verschlüsselung oder nur eine ausgenommene. Apple stellt klar, dass die ins System integrierte Verschlüsselung, etwa HTTPS-Verbindungen, in der Regel ausgenommen ist und dass die Antwort auch deine Bibliotheken abdeckt. Alle drei meiner Apps geben false an. Setz false nur, wenn es für deine App stimmt: Die Angabe ist verbindlich.

Kann man die Nummer eines hochgeladenen Builds ändern?

Nein. Die Nummer steckt im signierten Binary: Um sie zu korrigieren, brauchst du einen neuen Build.

Ändern kannst du den Build, der deiner Version zugeordnet ist. Apple erlaubt einen Build pro Version, aber du kannst ihn beliebig oft austauschen, bis du ihn zum Review einreichst:

1. Öffne die Version in App Store Connect, Bereich Build.
2. Fahr mit der Maus über den aktuellen Build und klick auf den Entfernen-Button, das Minuszeichen.
3. Klick auf den Hinzufügen-Button, das Pluszeichen, wähle den richtigen Build und speichere.

Ein Build, den du von einer Version entfernst, wird nicht aus deinem Account gelöscht. Ist die Version schon im Review, zieh zuerst die Einreichung zurück: Das Review beginnt dann von vorn.

Vor deinem nächsten Upload

Die Build-Nummer ist nur eine der Prüfungen beim Upload. Das Build-Image kann ITMS-90725 auslösen, und die Signierung hat ihre eigenen Fallen, erklärt in iOS-Entwicklerzertifikat und Provisioning Profile. Die komplette Kette vom Build bis TestFlight steht in iOS-App ohne Mac veröffentlichen, die Review-Dauer in Wie lange dauert das App-Store-Review. Alle Schritte sind auf der Seite App im App Store veröffentlichen gebündelt.

Wenn du dein erstes Release vorbereitest, mach die kostenlose Diagnose: Sie zeigt dir, was in deinem Projekt blockiert, und schickt dir meine Checkliste gegen Apple-Ablehnungen. Um die App zu bauen, Abos einzubinden und sie zu veröffentlichen, begleitet dich das iOS & Android Kit in vier Schritten mit dem Starter Code meiner Apps, in deinem Tempo.

Häufige Fragen

Was ist der Unterschied zwischen Version und Build-Nummer in App Store Connect?

Die Version ist die öffentliche Nummer deines Releases, etwa 1.4.0. Die Build-Nummer identifiziert ein bestimmtes Binary, das du für diese Version an Apple schickst. Du kannst für eine Version mehrere Builds hochladen, jeder mit eigener Nummer.

Muss ich die Build-Nummer bei jedem Upload ändern?

Ja, innerhalb derselben Version. Apple lehnt einen zweiten Upload mit derselben Kombination aus Version und Build-Nummer ab, das ist der Fehler ITMS-90189. Mit EAS übernimmt autoIncrement das bei jedem Production-Build.

Muss die Build-Nummer bei jeder Version wieder bei 1 anfangen?

Nein, das ist keine Pflicht. Auf dem iPhone akzeptiert Apple für eine neue Version eine niedrigere Nummer, weil nur die Kombination eindeutig sein muss. Ein Zähler, der immer steigt, ist trotzdem einfacher zu verfolgen.

Wie ändere ich die Build-Nummer in App Store Connect?

Die Nummer eines bereits hochgeladenen Builds kannst du nicht ändern. Du kannst aber den Build, der deiner Version zugeordnet ist, im Bereich Build des Eintrags austauschen, solange sie nicht im Review ist. Für eine neue Nummer machst du einen neuen Build.

Warum taucht mein Build nicht in App Store Connect auf?

Meistens wird er noch verarbeitet oder wartet auf deine Verschlüsselungsangabe. Prüfe auch, ob seine Version zu der deines Eintrags passt. Nach mehr als 24 Stunden in Verarbeitung bittet Apple dich, ein Ticket zu eröffnen.