# App Store Connect Build-Nummer: Version und Build erklärt > Die Version sehen deine Kunden, die Build-Nummer kennzeichnet jeden Upload. Die Kombination muss eindeutig sein: Mit Expo zählt EAS den Build für dich hoch. Originalseite: [App Store Connect Build-Nummer: Version und Build erklärt](https://devoria.fr/de/blog/app-store-connect-build-nummer-version) Autor: [Mehdi Azizi](https://devoria.fr/de/mehdi-azizi) Veröffentlicht: 2026-11-04 Letzte inhaltliche Überarbeitung: 2026-11-04 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](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) beschreibt sie als die für Nutzer sichtbare Version: drei durch Punkte getrennte Ganzzahlen, etwa 10.14.1. [Die Seite zu CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/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](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) 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](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds) 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](https://docs.expo.dev/build-reference/app-versions/), 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: ```json { "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](https://docs.expo.dev/eas/json/) 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): ```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 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](https://docs.expo.dev/versions/latest/config/app/) 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: ```text 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](https://docs.expo.dev/submit/ios/) spricht meist von 10 bis 15 Minuten. [Laut Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata) 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](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) 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](https://devoria.fr/de/blog/testflight-iphone-app-testen). ### Die wichtigsten Status Die Status, die einen fehlenden Build am häufigsten erklären, laut [Apples Liste](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing und Failed stehen nicht darin: Das sind Upload-Status, beschrieben in [der Build-Übersicht](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | 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](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) bei jeder neuen Version die Compliance-Fragen. Mit Expo heißt das Feld `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` bedeutet: keine Verschlüsselung oder nur eine ausgenommene. [Apple stellt klar](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations), 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](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit), 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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): 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](https://devoria.fr/de/blog/itms-90725-sdk-version-issue-expo-beheben) auslösen, und die Signierung hat ihre eigenen Fallen, erklärt in [iOS-Entwicklerzertifikat und Provisioning Profile](https://devoria.fr/de/blog/ios-zertifikat-provisioning-profile-expo). Die komplette Kette vom Build bis TestFlight steht in [iOS-App ohne Mac veröffentlichen](https://devoria.fr/de/blog/ios-app-ohne-mac-veroeffentlichen-expo-eas), die Review-Dauer in [Wie lange dauert das App-Store-Review](https://devoria.fr/de/blog/app-store-review-dauer). Alle Schritte sind auf der Seite [App im App Store veröffentlichen](https://devoria.fr/de/expertise/app-im-app-store-veroeffentlichen) gebündelt. Wenn du dein erstes Release vorbereitest, [mach die kostenlose Diagnose](https://devoria.fr/de/diagnostic): 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](https://devoria.fr/de/kits/ios) 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. ## Dein Projekt [Review Kit](https://devoria.fr/de/kits/app-review): Meine Checkliste für die App Store Review, meine von Apple abgelehnten und korrigierten Fälle, die für Google Play und drei Claude Code Skills. 49 €. [iOS & Android Kit](https://devoria.fr/de/kits/ios): Bau deine iPhone- und Android-App mit Claude Code: der Startcode meiner Apps, der Weg bis in die Stores und alle Kits. 99 €. [Diagnose: Was dich von deiner iPhone-App trennt](https://devoria.fr/de/diagnostic): 7 Fragen, 60 Sekunden: Du erfährst, was dich wirklich davon abhält, deine iPhone-App zu veröffentlichen, bekommst deinen Weg in 4 Schritten und das passende Kit.