eas submit iOS: veelvoorkomende fouten en oplossingen
Door Mehdi Azizi
Gepubliceerd op , 10 min
Mislukt eas submit? De echte meldingen van EAS en App Store Connect, hun oorzaak en oplossing: ascAppId, API-sleutel, Apple-overeenkomst, ITMS-codes.
Als eas submit --platform ios mislukt, vertelt de melding je bijna altijd waar je moet kijken. Of je EAS-configuratie is onvolledig, of je Apple-account blokkeert, of Apple weigert de binary. De eerste twee gevallen los je in een paar minuten op, zonder nieuwe build. Het derde herken je aan een ITMS-code, en dan heb je bijna altijd een nieuwe build nodig.
Ik publiceer mijn iOS-apps, waaronder Solys, TradaZen en Nolera, met Expo en EAS. De meldingen hier zijn gekopieerd uit de broncode van EAS CLI, in de officiële GitHub-repository van Expo, nagelezen op 3 november 2026. Het oude forum van Expo verwijst nu door naar Discord: de code blijft de betrouwbaarste bron. Voor het volledige traject, van het bestand eas.json tot het indienen voor review, lees eerst EAS Submit iOS: een Expo-app publiceren in de App Store. Hier gaan we repareren.
Wat eas submit doet, en wat het nodig heeft
Volgens de documentatie van Expo stuurt het commando je .ipa-bestand naar App Store Connect. De build verschijnt in TestFlight nadat Apple hem heeft verwerkt, meestal na 10 tot 15 minuten. Het dient je app niet in voor review: die stap doe je zelf in App Store Connect.
De pagina van Expo over iOS-uploads noemt drie vereisten:
- een betaald Apple Developer-account, verplicht voor elke upload naar de App Store;
- de bundle identifier in
ios.bundleIdentifier; - EAS CLI geïnstalleerd en ingelogd op je Expo-account.
Om zonder interactie te uploaden, voegt dezelfde pagina twee instellingen toe:
ascAppIdin hetsubmit-profiel vaneas.json, het nummer van je app in App Store Connect;- een App Store Connect API-sleutel, beheerd door EAS of door jou aangeleverd. Het aanmaken, de rol en het intrekken ervan lees je in App Store Connect API-sleutel (.p8).
Het minimale profiel past in een paar regels. De waarde is fictief:
{
"submit": {
"production": {
"ios": {
"ascAppId": "1234567890"
}
}
}
}
Als EAS je API-sleutel al bewaart, is dit profiel genoeg. Dat is bij de meeste van mijn apps zo.
De melding lezen: drie soorten fouten
Voordat je een oplossing zoekt, kijk je op welk moment het commando stopt. Deze tabel is het schema dat ik bij elke mislukking gebruik.
| Moment van de fout | Soort | Nieuwe build? |
|---|---|---|
| Vóór elke upload | EAS-configuratie | Nee |
| Verbinding met Apple, aanmaken van de app | Apple-account | Nee |
| Na de upload, code ITMS-90xxx | Binary geweigerd | Bijna altijd |
De details staan op de pagina van de submission, in het dashboard van Expo. Expo raadt aan daar de logs te lezen en te letten op de ballon "Build Annotations", die veelvoorkomende oorzaken van fouten aangeeft. In de terminal toont de optie --verbose altijd de logs van EAS Submit, volgens de referentie van EAS CLI.
Fouten in de EAS-configuratie
"Set ascAppId in the submit profile (eas.json) or re-run this command in interactive mode."
Je hebt het commando gestart met --non-interactive, bijvoorbeeld in CI, en je profiel bevat geen ascAppId. De code van EAS CLI stopt dan: hij kan je niets vragen en kan de app ook niet voor je aanmaken.
Oplossing: kopieer het nummer van je app naar ascAppId. Expo legt uit waar je het vindt: open je app in App Store Connect en ga naar App Information. Het is het veld Apple ID, onder General Information, een getal van ongeveer tien cijfers. Het is niet je Apple-e-mailadres en ook niet je bundle identifier.
Bij Nolera vroeg het commando zonder ascAppId om een Apple Developer-sessie, en die verloopt. Sinds het nummer in eas.json staat, vraagt de upload niets meer.
Voeg
ascAppIdtoe vóór de build, niet erna. Tot en met SDK 57 neemt de fingerprint die Expo berekent altijdeas.jsonmee. Bij Vigie, waarvan de runtime version hetfingerprint-beleid volgt, veranderde het toevoegen van dit nummer na een build de fingerprint: een daarna gepubliceerde update zou de geïnstalleerde build nooit hebben bereikt. Sinds SDK 58 negeert de standaardpreset van de fingerprint,balanced, het bestandeas.json, volgens de changelog van Expo.
"App Store Connect API Keys cannot be set up in --non-interactive mode."
Je profiel bevat geen sleutel, en EAS heeft er geen gekoppeld aan je app. Expo zegt het duidelijk: in niet-interactieve modus kan het commando je niet om een sleutel vragen, en mislukt het met deze melding.
Twee mogelijke oplossingen:
- Laat EAS de sleutel aanmaken en bewaren. Draai één keer
eas credentials --platform iosin interactieve modus op je eigen machine, en laat het een App Store Connect API-sleutel voor je app instellen. - Gebruik je eigen sleutel in
ascApiKeyPath,ascApiKeyIssuerIdenascApiKeyId. Volgens de referentie van eas.json accepteren deze drie velden omgevingsvariabelen, zoals$ASC_API_KEY_PATH.
Bij mijn laatste app wilde de optie --auto-submit een Apple-login om zijn uploadsleutel aan te maken. Ik heb de drie velden van mijn eigen sleutel in het profiel van mijn werkkopie gezet, nooit gecommit. Daarna heb ik de afgeronde build verstuurd met --id en --non-interactive.
"EXPO_APPLE_APP_SPECIFIC_PASSWORD must be in the format xxxx-xxxx-xxxx-xxxx, where x is a lowercase letter."
De variabele bevat iets anders dan een app-specifiek wachtwoord, vaak je Apple-wachtwoord zelf. EAS CLI controleert dit formaat vóór elke upload.
Volgens de hulp van Apple maak je een app-specifiek wachtwoord aan op account.apple.com, onder App-Specific Passwords, met tweestapsverificatie ingeschakeld. Het wordt ingetrokken zodra je het wachtwoord van je Apple-account wijzigt. Expo vindt deze methode minder veilig dan de API-sleutel, de standaard en aanbevolen methode.
Fouten in het Apple-account
"… agree to the latest Program License Agreement in your developer account."
De volledige melding begint met "You currently don't have access to this membership resource". Aan de kant van Apple kan het ruwe antwoord "Unable to process request - PLA Update available" bevatten. De recente uploadstappen van EAS tonen eerder "A required Apple agreement is missing or has expired".
De oorzaak is dezelfde: Apple heeft een overeenkomst bijgewerkt, en niemand heeft die geaccepteerd. Alleen de eigenaar van het account, de Account Holder, kan overeenkomsten accepteren, volgens de rollentabel van Apple. De code van EAS vraagt hem naar de Business-pagina van App Store Connect te gaan, en daarna, als Apple dat aanbiedt, naar zijn account op developer.apple.com. Start het commando daarna opnieuw. De overeenkomst voor betaalde apps heeft een eigen gids: Paid Apps Agreement in App Store Connect.
"App Store Connect rejected the API authentication credentials."
Apple antwoordde met een 401-fout, NOT_AUTHORIZED. EAS noemt drie oorzaken: een sleutel die niet meer actief is, een sleutel van een ander App Store Connect-account, of een verkeerde Key ID, sleutelinhoud of Issuer ID.
Controleer beide ID's in App Store Connect, menu Users and Access, tabblad Integrations. Volgens Apple staat de Issuer ID bovenaan de pagina, en de Key ID in de lijst met actieve sleutels. Een ingetrokken sleutel wordt nooit meer actief. Apple toont hem 30 dagen onder Revoked: je moet een nieuwe genereren.
"App Store Connect app for application identifier … was not found."
De app waar ascAppId naar verwijst, is met jouw sleutel niet te vinden. EAS vraagt je dit nummer te controleren, en of de sleutel wel toegang heeft tot de app in het juiste account. Het toont zelfs een paar apps die met deze sleutel zichtbaar zijn. Met de uploadtools van Apple verschijnt hetzelfde probleem als "No suitable application records were found".
Drie oorzaken komen vaak terug, waarvan twee genoemd in deze thread op de forums van Apple:
- De app bestaat niet. Maak hem aan in App Store Connect, of haal
ascAppIdweg zodat het commando hem aanmaakt. - Het nummer komt uit een ander account. Je hebt de
ascAppIdvan een ander team of een ander project gekopieerd. - De gebruiker heeft geen toegang tot de app. Een App Manager of Developer kan beperkt zijn tot bepaalde apps. Een teamsleutel daarentegen heeft toegang tot alle apps van het account.
"… is not available to team" of "… is not available to provider"
Deze melding verschijnt als EAS de app voor je aanmaakt, omdat ascAppId ontbreekt. De bundle identifier is al bezet door een ander team. EAS vraagt je hem te wijzigen in de configuratie van je app en het opnieuw te proberen.
"App name "…" is already taken. Using generated name "…""
Dit is geen fout. Als de naam al bezet is in de App Store, voegt EAS zes willekeurige tekens toe en probeert het opnieuw, tot vijf keer. Je hernoemt de app later in App Store Connect. Om dit te voorkomen vul je appName en language in het profiel in vóór de eerste upload: zonder language is de primaire taal en-US.
Fouten in de binary: de ITMS-codes
Na de upload verwerkt Apple de build. Als Apple hem weigert, noemt de log een of meer ITMS-codes. Dit zijn de codes die de uploadstap van EAS herkent en vertaalt:
| ITMS-code | Wat Apple weigert | Oplossing |
|---|---|---|
| 90189 | Buildnummer al in gebruik | autoIncrement |
| 90062, 90186, 90478 | Versie gesloten of al gepasseerd | version verhogen |
| 90683 | Toestemmingstekst ontbreekt | ios.infoPlist |
| 90725 | iOS SDK te oud | iOS-image of Expo SDK |
| 90054, 90055 | Bundle wijkt af van de beoogde app | ascAppId corrigeren |
| 90022, 90023, 90391, 90713 | Iconen ontbreken of verkeerd gedeclareerd | Iconen nakijken |
| 90771 | ID's van achtergrondtaken ontbreken | ios.infoPlist |
Drie verduidelijkingen uit deze meldingen:
- Het buildnummer is uniek per versie. Voor 90189 raadt EAS
"autoIncrement": trueaan ineas.json. Alles staat in buildnummer en versie. - Voor 90725 raadt EAS aan een recentere iOS-image te kiezen in
eas.json, en zo nodig over te stappen op een ondersteunde Expo SDK. - Voor 90771 declareert je Info.plist de achtergrondmodus
processing, maar niet de sleutelBGTaskSchedulerPermittedIdentifiers.
Behalve bij 90054 en 90055, waar je alleen de juiste app of een andere build hoeft te kiezen, raakt de oplossing de binary: maak een nieuwe build en upload die opnieuw. Twee codes hebben een eigen gids: ITMS-90683 met Expo en ITMS-90725.
Eind september 2026 werd een build van Solys bij de levering geweigerd met ITMS-90683. Ik had een toestemmingstekst voor foto's verwijderd tijdens het opruimen van het configuratiebestand. Solys gebruikt geen foto's, maar een library in het project roept de Photos-API van iOS aan. Apple analyseert de binary, niet het echte gebruik: sindsdien verwijder ik die teksten nooit meer.
De status Missing Compliance is geen uploadfout. Je verklaring over encryptie ontbreekt, uitgelegd in de gids voor publiceren met EAS.
Mijn checklist vóór elke upload
ascAppIdstaat in hetsubmit-profiel, toegevoegd vóór de build.- De API-sleutel wordt beheerd door EAS, of de drie velden wijzen naar een
.p8buiten de repository. - De Account Holder heeft de nieuwste overeenkomsten geaccepteerd in App Store Connect.
autoIncrementstaat aan, met"appVersionSource": "remote", aanbevolen door Expo sinds EAS CLI 12.- De
versionis hoger dan de laatst goedgekeurde versie. - Elke gevoelige API in de binary heeft een toestemmingstekst.
- Voor een nieuwe app zijn
appNameenlanguageingevuld vóór de eerste upload.
Je eerste app uploaden zonder vast te lopen
Het commando is maar één stap. De iOS & Android Kit vertrekt vanuit de startcode van mijn apps, abonnementen inbegrepen, en volgt vier stappen tot aan de App Store, in je eigen tempo.
Bereid je je eerste release voor? Doe je gratis diagnose: die vertelt je wat je echt tegenhoudt en stuurt je mijn checklist tegen afwijzingen door Apple. Voor de productpagina, de screenshots en de goedkeuring loopt de pagina een app publiceren in de App Store elke stap door.
Veelgestelde vragen
Waarom mislukt eas submit alleen in CI?
In --non-interactive-modus kan het commando je niets vragen. Het heeft ascAppId in het profiel nodig en een API-sleutel die al aan de app gekoppeld is, of de drie velden ervan in eas.json. Op je eigen machine had het je die vragen gesteld.
Moet ik een nieuwe build maken na een fout in eas submit?
Alleen als Apple de binary weigert, met een ITMS-code. Uitzondering: bij ITMS-90054 en 90055 was de build op de verkeerde app gericht, en hoef je hem alleen naar de juiste te sturen. Configuratie- en accountfouten los je op in eas.json, in App Store Connect of in je Apple-account. Daarna stuur je dezelfde build opnieuw, bijvoorbeeld met --latest of --id.
Waar zie ik de logs van een EAS Submit-upload?
Op de pagina van de submission, in het dashboard van Expo. Expo raadt aan daar de logs en de ballon "Build Annotations" te lezen. Voeg in de terminal --verbose toe om de logs altijd te tonen.
Kan ik eas submit gebruiken met een gratis Apple-account?
Nee. Expo vereist een betaald Apple Developer-account om een app naar de App Store te sturen. Met het gratis account kun je testen op je eigen iPhone, maar niet App Store Connect gebruiken.
Welke rol geef ik de API-sleutel voor eas submit?
De gids van Expo geeft de sleutel de rol Admin. Volgens de rollentabel van Apple kunnen ook de rollen App Manager en Developer builds uploaden. Mijn Expo-builds draaien met een teamsleutel met de rol App Manager. Alleen de Account Holder en Admins kunnen een teamsleutel genereren.
Wat betekent "Increment Build Number" in EAS?
Apple heeft de build geweigerd met code ITMS-90189: dit buildnummer bestaat al voor deze versie. Zet "autoIncrement": true aan in eas.json, of verhoog ios.buildNumber, en maak daarna een nieuwe build.

