eas submit iOS: häufige Fehler und ihre Lösung

Wenn eas submit --platform ios fehlschlägt, sagt dir die Meldung fast immer, wo du suchen musst. Entweder ist deine EAS-Konfiguration unvollständig, dein Apple-Konto blockiert, oder Apple lehnt das Binary ab. Die ersten beiden Fälle behebst du in wenigen Minuten, ohne neuen Build. Den dritten erkennst du an einem ITMS-Code, und er erfordert fast immer einen neuen Build.

Ich veröffentliche meine iOS-Apps, darunter Solys, TradaZen und Nolera, mit Expo und EAS. Die hier zitierten Meldungen stammen aus dem Quellcode von EAS CLI, aus dem offiziellen GitHub-Repository von Expo, zuletzt geprüft am 3. November 2026. Das alte Expo-Forum verweist inzwischen auf Discord: Der Code bleibt die zuverlässigste Quelle. Für den kompletten Ablauf, von der Datei eas.json bis zur Einreichung zur Prüfung, lies zuerst EAS Submit iOS: eine Expo-App im App Store veröffentlichen. Hier wird repariert.

Was eas submit macht und was es braucht

Laut der Expo-Dokumentation schickt der Befehl deine .ipa-Datei an App Store Connect. Der Build erscheint in TestFlight, nachdem Apple ihn verarbeitet hat, meist nach 10 bis 15 Minuten. Er reicht deine App nicht zur Prüfung ein: Diesen Schritt machst du weiterhin in App Store Connect.

Die Expo-Seite zum iOS-Upload nennt drei Voraussetzungen:

• ein kostenpflichtiges Apple-Developer-Konto, Pflicht für jeden Upload in den App Store;
• die Bundle-ID in ios.bundleIdentifier;
• EAS CLI installiert und mit deinem Expo-Konto verbunden.

Für einen Upload ohne Interaktion nennt dieselbe Seite zwei weitere Einstellungen:

• ascAppId im submit-Profil von eas.json, die Nummer deines App-Store-Connect-Eintrags;
• einen App-Store-Connect-API-Schlüssel, von EAS verwaltet oder von dir bereitgestellt. Erstellung, Rolle und Widerruf erkläre ich in App-Store-Connect-API-Schlüssel (.p8).

Das minimale Profil passt in ein paar Zeilen. Der Wert ist ein Platzhalter:

{
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

Wenn EAS deinen API-Schlüssel schon verwaltet, reicht dieses Profil. Bei den meisten meiner Apps ist das so.

Die Meldung lesen: drei Fehlerfamilien

Bevor du nach der Lösung suchst, finde heraus, an welcher Stelle der Befehl abbricht. Diese Tabelle ist das Raster, das ich bei jedem Fehlschlag anwende.

Zeitpunkt des Fehlers	Familie	Neuer Build?
Vor jedem Upload	EAS-Konfiguration	Nein
Verbindung zu Apple, Anlegen des Eintrags	Apple-Konto	Nein
Nach dem Upload, Code ITMS-90xxx	Binary abgelehnt	Fast immer

Die Details findest du auf der Seite der Einreichung im Expo-Dashboard. Expo empfiehlt, dort die Logs zu lesen und auf die Box „Build Annotations“ zu achten, die häufige Fehlerursachen anzeigt. Im Terminal zeigt die Option --verbose laut der EAS-CLI-Referenz immer die Logs von EAS Submit an.

Fehler in der EAS-Konfiguration

„Set ascAppId in the submit profile (eas.json) or re-run this command in interactive mode.“

Du hast den Befehl mit --non-interactive gestartet, zum Beispiel in der CI, und dein Profil enthält kein ascAppId. Der Code von EAS CLI bricht dann ab: Er kann dich weder fragen noch den Eintrag für dich anlegen.

Lösung: Trag die Nummer deines Eintrags in ascAppId ein. Expo zeigt, wo du sie findest: In App Store Connect öffnest du deine App, dann App Information. Es ist das Feld Apple ID unter General Information, eine etwa zehnstellige Zahl. Es ist weder deine Apple-E-Mail-Adresse noch deine Bundle-ID.

Bei Nolera wollte der Befehl ohne ascAppId eine Apple-Developer-Sitzung, die abläuft. Seit die Nummer in eas.json steht, fragt der Upload nichts mehr.

Füge ascAppId vor dem Build hinzu, nicht danach. Bis SDK 57 schließt der von Expo berechnete Fingerprint immer eas.json ein. Bei Vigie, dessen Runtime-Version der Policy fingerprint folgt, hat das Hinzufügen dieser Nummer nach einem Build den Fingerprint verändert: Ein danach veröffentlichtes Update hätte den installierten Build nie erreicht. Seit SDK 58 ignoriert das Standard-Preset des Fingerprints, balanced, die Datei eas.json, laut dem Changelog von Expo.

„App Store Connect API Keys cannot be set up in --non-interactive mode.“

Dein Profil enthält keinen Schlüssel, und EAS hat keinen mit deiner App verknüpft. Expo stellt klar: Im nicht interaktiven Modus kann der Befehl dich nicht nach einem Schlüssel fragen und schlägt mit dieser Meldung fehl.

Zwei mögliche Lösungen:

• Lass EAS den Schlüssel erstellen und verwalten. Führe einmal eas credentials --platform ios im interaktiven Modus auf deinem Rechner aus und lass es einen App-Store-Connect-API-Schlüssel für deine App einrichten.
• Bring deinen eigenen Schlüssel mit in ascApiKeyPath, ascApiKeyIssuerId und ascApiKeyId. Laut der eas.json-Referenz akzeptieren diese drei Felder Umgebungsvariablen wie $ASC_API_KEY_PATH.

Bei meiner letzten App wollte die Option --auto-submit eine Apple-ID, um ihren Upload-Schlüssel zu erstellen. Ich habe die drei Felder meines eigenen Schlüssels ins Profil meiner Arbeitskopie gesetzt, nie committet. Dann habe ich den fertigen Build mit --id und --non-interactive hochgeladen.

„EXPO_APPLE_APP_SPECIFIC_PASSWORD must be in the format xxxx-xxxx-xxxx-xxxx, where x is a lowercase letter.“

Die Variable enthält etwas anderes als ein app-spezifisches Passwort, oft dein eigentliches Apple-Passwort. EAS CLI prüft dieses Format vor jedem Upload.

Laut Apples Hilfe erzeugst du ein app-spezifisches Passwort auf account.apple.com im Bereich App-Specific Passwords, mit aktivierter Zwei-Faktor-Authentifizierung. Es wird widerrufen, sobald du das Passwort deines Apple-Kontos änderst. Expo hält diese Methode für weniger sicher als den API-Schlüssel, seine Standard- und empfohlene Methode.

Fehler im Apple-Konto

„… agree to the latest Program License Agreement in your developer account.“

Die vollständige Meldung beginnt mit „You currently don't have access to this membership resource“. Auf Apples Seite kann die Rohantwort „Unable to process request - PLA Update available“ enthalten. Die neueren Upload-Schritte von EAS zeigen eher „A required Apple agreement is missing or has expired“.

Die Ursache ist dieselbe: Apple hat einen Vertrag aktualisiert, und niemand hat ihn akzeptiert. Nur der Kontoinhaber, der Account Holder, kann Verträge akzeptieren, laut Apples Rollentabelle. Der Code von EAS schickt ihn auf die Business-Seite von App Store Connect und dann, falls Apple es anbietet, in sein Konto auf developer.apple.com. Starte den Befehl danach neu. Der Vertrag für kostenpflichtige Apps hat einen eigenen Guide: Paid Apps Agreement in App Store Connect.

„App Store Connect rejected the API authentication credentials.“

Apple hat mit einem 401-Fehler geantwortet, NOT_AUTHORIZED. EAS nennt drei Ursachen: ein Schlüssel, der nicht mehr aktiv ist, ein Schlüssel aus einem anderen App-Store-Connect-Konto oder eine falsche Key ID, ein falscher Schlüsselinhalt oder eine falsche Issuer ID.

Prüf die beiden IDs in App Store Connect, Menü Users and Access, Tab Integrations. Laut Apple steht die Issuer ID oben auf der Seite und die Key ID in der Liste der aktiven Schlüssel. Ein widerrufener Schlüssel lässt sich nie wieder aktivieren. Apple zeigt ihn 30 Tage lang unter Revoked an: Du musst einen neuen erzeugen.

„App Store Connect app for application identifier … was not found.“

Der Eintrag, auf den ascAppId zeigt, ist mit deinem Schlüssel nicht auffindbar. EAS bittet dich, diese Nummer zu prüfen und ob der Schlüssel im richtigen Konto wirklich Zugriff auf die App hat. Es listet sogar einige Apps auf, die mit diesem Schlüssel sichtbar sind. Mit Apples eigenen Upload-Tools erscheint dasselbe Problem als „No suitable application records were found“.

Drei Ursachen tauchen immer wieder auf, zwei davon aus diesem Thread in Apples Foren:

• Der Eintrag existiert nicht. Leg ihn in App Store Connect an oder entferne ascAppId, damit der Befehl ihn anlegt.
• Die Nummer stammt aus einem anderen Konto. Du hast die ascAppId eines anderen Teams oder eines anderen Projekts kopiert.
• Der Nutzer hat keinen Zugriff auf die App. Ein App Manager oder Developer kann auf bestimmte Apps beschränkt sein. Ein Team-Schlüssel dagegen hat Zugriff auf alle Apps des Kontos.

„… is not available to team“ oder „… is not available to provider“

Diese Meldung erscheint, wenn EAS den Eintrag für dich anlegt, weil ascAppId fehlt. Die Bundle-ID ist schon von einem anderen Team belegt. EAS bittet dich, sie in der Konfiguration deiner App zu ändern und neu zu starten.

„App name "…" is already taken. Using generated name "…"“

Das ist kein Fehlschlag. Wenn der Name im App Store schon vergeben ist, hängt EAS sechs zufällige Zeichen an und versucht es erneut, bis zu fünfmal. Du benennst den Eintrag später in App Store Connect um. Um das zu vermeiden, trag appName und language vor dem ersten Upload ins Profil ein: Ohne language ist die Hauptsprache en-US.

Fehler im Binary: die ITMS-Codes

Nach dem Upload verarbeitet Apple den Build. Lehnt Apple ihn ab, nennt das Log einen oder mehrere ITMS-Codes. Hier sind die, die der Upload-Schritt von EAS erkennt und übersetzt:

ITMS-Code	Was Apple ablehnt	Lösung
90189	Build-Nummer schon vergeben	autoIncrement
90062, 90186, 90478	Version geschlossen oder schon überholt	version erhöhen
90683	Berechtigungstext fehlt	ios.infoPlist
90725	iOS-SDK zu alt	iOS-Image oder Expo-SDK
90054, 90055	Bundle passt nicht zum Ziel-Eintrag	ascAppId korrigieren
90022, 90023, 90391, 90713	Icons fehlen oder falsch deklariert	Icons überarbeiten
90771	IDs für Hintergrundaufgaben fehlen	ios.infoPlist

Drei Hinweise aus diesen Meldungen:

• Die Build-Nummer ist pro Version eindeutig. Bei 90189 empfiehlt EAS "autoIncrement": true in eas.json. Alles dazu in Build-Nummer und Version.
• Bei 90725 rät EAS, in eas.json ein neueres iOS-Image zu wählen und bei Bedarf auf ein unterstütztes Expo-SDK zu wechseln.
• Bei 90771 deklariert deine Info.plist den Hintergrundmodus processing, aber nicht den Schlüssel BGTaskSchedulerPermittedIdentifiers.

Außer bei 90054 und 90055, wo es reicht, den richtigen Eintrag oder einen anderen Build anzusteuern, betrifft die Lösung das Binary: Mach einen neuen Build und lade ihn erneut hoch. Zwei Codes haben einen eigenen Guide: ITMS-90683 mit Expo und ITMS-90725.

Ende September 2026 wurde ein Build von Solys bei der Auslieferung wegen ITMS-90683 abgelehnt. Ich hatte beim Aufräumen der Konfigurationsdatei einen Berechtigungstext für Fotos entfernt. Solys nutzt keine Fotos, aber eine Bibliothek im Projekt ruft die Photos-API von iOS auf. Apple analysiert das Binary, nicht die tatsächliche Nutzung: Seitdem entferne ich diese Texte nie mehr.

Der Status Missing Compliance ist dagegen kein Upload-Fehler. Es fehlt deine Angabe zur Verschlüsselung, erklärt in dem Veröffentlichungs-Guide mit EAS.

Meine Checkliste vor jedem Upload

• ascAppId steht im submit-Profil, vor dem Build hinzugefügt.
• Der API-Schlüssel wird von EAS verwaltet, oder seine drei Felder zeigen auf eine .p8 außerhalb des Repositorys.
• Der Account Holder hat die neuesten Verträge in App Store Connect akzeptiert.
• autoIncrement ist aktiv, mit "appVersionSource": "remote", von Expo empfohlen seit EAS CLI 12.
• Die version ist höher als die zuletzt freigegebene Version.
• Jede sensible API im Binary hat ihren Berechtigungstext.
• Bei einer neuen App sind appName und language vor dem ersten Upload eingetragen.

Deine erste App hochladen, ohne hängen zu bleiben

Der Befehl ist nur ein Schritt. Das iOS & Android Kit basiert auf dem Starter Code meiner Apps, Abos inklusive, und führt dich in vier Schritten bis in den App Store, in deinem Tempo.

Wenn du deinen ersten Release vorbereitest, mach deine kostenlose Diagnose: Sie zeigt dir, was dich wirklich blockiert, und schickt dir meine Checkliste gegen Apple-Ablehnungen. Für Eintrag, Screenshots und Freigabe geht die Seite eine App im App Store veröffentlichen jeden Schritt durch.

Häufige Fragen

Warum schlägt eas submit nur in der CI fehl?

Im Modus --non-interactive kann der Befehl dich nichts fragen. Er braucht ascAppId im Profil und einen API-Schlüssel, der schon mit der App verknüpft ist, oder dessen drei Felder in eas.json. Auf deinem Rechner hätte er dir diese Fragen gestellt.

Muss ich nach einem Fehler bei eas submit neu builden?

Nur wenn Apple das Binary mit einem ITMS-Code ablehnt. Ausnahme: Bei ITMS-90054 und 90055 zielte der Build auf den falschen Eintrag, du musst ihn nur an den richtigen schicken. Konfigurations- und Kontofehler behebst du in eas.json, in App Store Connect oder in deinem Apple-Konto. Danach lädst du denselben Build erneut hoch, zum Beispiel mit --latest oder --id.

Wo sehe ich die Logs eines EAS-Submit-Uploads?

Auf der Seite der Einreichung im Expo-Dashboard. Expo empfiehlt, dort die Logs und die Box „Build Annotations“ zu lesen. Im Terminal fügst du --verbose hinzu, damit die Logs immer angezeigt werden.

Kann ich eas submit mit einem kostenlosen Apple-Konto nutzen?

Nein. Expo verlangt ein kostenpflichtiges Apple-Developer-Konto, um eine App in den App Store hochzuladen. Mit dem kostenlosen Konto kannst du auf deinem eigenen iPhone testen, aber nicht App Store Connect nutzen.

Welche Rolle braucht der API-Schlüssel für eas submit?

Der Expo-Guide gibt dem Schlüssel die Rolle Admin. Laut Apples Rollentabelle dürfen auch die Rollen App Manager und Developer Builds hochladen. Meine Expo-Builds laufen mit einem Team-Schlüssel mit der Rolle App Manager. Nur der Account Holder und Admins können einen Team-Schlüssel erzeugen.

Was bedeutet „Increment Build Number“ in EAS?

Apple hat den Build mit dem Code ITMS-90189 abgelehnt: Diese Build-Nummer existiert für diese Version schon. Aktiviere "autoIncrement": true in eas.json oder erhöhe ios.buildNumber und mach dann einen neuen Build.