ITMS-90034: „Missing or invalid signature“ beheben

ITMS-90034 taucht auf, wenn du deinen Build an App Store Connect schickst. Die Meldung sagt: Deine App oder eine ihrer Komponenten ist nicht mit einem Apple-Submission-Zertifikat signiert, also mit einem gültigen Distributionszertifikat. Die Lösung: herausfinden, welches Bundle falsch signiert ist und warum, und dann einen neuen, für den App Store signierten Build erstellen.

Dieser Guide bleibt beim Fehler selbst. Wenn dir Begriffe wie Zertifikat und Profil noch unklar sind, lies zuerst iOS-Entwicklerzertifikat und Provisioning Profile. Hier findest du die Meldung, die du lesen musst, einen Entscheidungsbaum, die Befehle, mit denen du deine IPA untersuchst, und die Lösung mit den von EAS verwalteten Credentials. Für den EAS-Teil habe ich den Code von EAS CLI 24.10.0 gelesen, der das Zertifikat auswählt.

Was bedeutet der Fehler ITMS-90034?

So sieht er klassischerweise aus, mit Beispielnamen:

ITMS-90034: Missing or invalid signature. The bundle 'com.example.myapp' at bundle path 'Payload/MyApp.app' is not signed using an Apple submission certificate.

Im Jahr 2026 taucht er im Apple-Forum auch als „Validation failed (409) Missing or invalid signature“ auf, gefolgt vom selben Text und „(ID: 90034)“.

Das „Submission-Zertifikat“ ist das Distributionszertifikat. Apples Hilfe zu Zertifikaten sagt es klar: Entwicklungszertifikate dienen dazu, deine App auf deinen Geräten zu starten, Distributionszertifikate dazu, sie zu verteilen oder an App Store Connect zu schicken.

Lies den genannten Pfad: Er zeigt auf das fehlerhafte Bundle. Payload/MyApp.app meint die App selbst. Ein Pfad, der auf .appex endet, meint eine Extension, zum Beispiel ein Widget. Ein Pfad auf .framework meint eine eingebettete Bibliothek.

Das ist keine Ablehnung durch einen Reviewer. Die Validierung schlägt beim Upload oder während der Verarbeitung des Builds fehl, noch vor TestFlight: Dieser Build wird deine Tester nie erreichen.

Der Entscheidungsbaum: von der Meldung zur Lösung

Jede Zeile entspricht einem Hinweis, den du in der Meldung, in den Befehlen aus dem nächsten Abschnitt oder in den EAS-Logs findest. Geh sie der Reihe nach durch: Die erste, die passt, ist deine Spur.

Was du siehst	Wahrscheinliche Ursache	Lösung
Pfad auf .appex	Extension falsch signiert	Extension deklarieren
Signature=adhoc	Build nicht signiert	Build mit Store-Profil
Apple Development	Entwicklungs-Build	Build mit Store-Profil
ProvisionedDevices lesbar	Interner Build (ad hoc)	Build mit Store-Profil
sealed resource	IPA nachträglich verändert	Neu bauen
EAS: „no longer valid“	Zertifikat widerrufen	Neues Zertifikat
Alles gültig	Problem auf Apples Seite	Erneut senden, dann melden

Deine IPA mit vier Befehlen untersuchen

Lade die IPA von der Build-Seite auf expo.dev herunter und öffne dann ein Terminal auf deinem Mac.

1. Wer hat die App signiert?

unzip -q MyApp.ipa -d ipa
codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)="

codesign schreibt auf die Fehlerausgabe, daher das 2>&1. Laut Apples Technical Note TN3161 ist jede Authority-Zeile ein Glied der Vertrauenskette. Die erste muss mit Apple Distribution: oder iPhone Distribution: beginnen, gefolgt vom Namen deines Teams. Die zweite Bezeichnung gehört zum alten Typ iOS Distribution: Laut seinem Code erstellt EAS CLI 24.10.0 immer noch Zertifikate dieses Typs. Steht da Apple Development:, ist es ein Entwicklungs-Build. Steht da Signature=adhoc ohne eine einzige Authority-Zeile, ist das Binary von keinem Zertifikat signiert.

2. Wurde die App nach dem Signieren verändert?

codesign --verify --deep --strict -vv ipa/Payload/*.app

Du willst valid on disk lesen, dann satisfies its Designated Requirement. TN3161 erklärt, was diese Prüfung garantiert: Alle erwarteten Dateien sind da, keine wurde hinzugefügt, keine verändert. Bei einem Test-Bundle, das ich signiert und danach angepasst habe, antwortet der Befehl mit a sealed resource is missing or invalid, dann file modified: gefolgt von der geänderten Datei. Die Option --deep dient hier nur zum Prüfen, niemals zum Signieren: Im Apple-Forum rät ein Ingenieur aus dem Support-Team davon ab, damit zu signieren.

3. Welches Profil ist eingebettet?

security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profil.plist
plutil -extract ProvisionedDevices xml1 -o - profil.plist
plutil -extract ExpirationDate raw profil.plist

Das sind die Befehle aus der Technical Note TN3125 zu Profilen. Ein App-Store-Profil enthält keine Geräteliste: Die zweite Zeile muss Could not extract value ausgeben. Zeigt sie Geräte-IDs an, ist es ein Ad-hoc-Profil, also das eines internen Builds. Die dritte Zeile liefert das Ablaufdatum des Profils.

4. Sind Extensions und Frameworks genauso signiert?

find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \
  -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \;

Jede Komponente muss dieselbe Authority-Zeile zeigen wie die App. Weicht eine davon ab, ist sie es, die in der Meldung genannt wird.

Wenn du vor dem Upload prüfen willst, empfiehlt TN3161 altool, also dieselbe Prüfung wie der Button Validate App in Xcode. Dafür brauchst du einen App Store Connect API-Schlüssel, dessen Datei AuthKey_<KEY_ID>.p8 in ~/.appstoreconnect/private_keys liegt:

xcrun altool --validate-app -f MyApp.ipa -t ios --api-key <KEY_ID> --api-issuer <ISSUER_ID>

Mit EAS beheben, Ursache für Ursache

Ein interner oder Entwicklungs-Build wurde an Apple geschickt

Laut Expos Dokumentation zu eas.json sind Builds mit "distribution": "internal" nicht für die Stores signiert: Sie nutzen ein Ad-hoc-Profil. Nur ein Profil mit Distribution store, dem Standardwert, erzeugt einen Build, den du hochladen kannst. Am sichersten schickst du den Build, den du gerade gebaut hast, ohne ihn von Hand auszuwählen:

eas build --platform ios --profile production --auto-submit

Wenn du eas submit --path nutzt, prüf, dass die Datei wirklich dein letzter Store-Build ist. Im Apple-Forum hat ein Team entdeckt, dass sein Upload-Tool jedes Mal eine alte, in git eingecheckte IPA hochgeladen hat.

Eine vergessene Extension

Jede Extension ist ein eigenes Bundle, mit eigener ID und eigenem Profil. In einem Expo-Projekt mit nativer Generierung verlangt Expos Seite zu iOS-Extensions, sie in extra.eas.build.experimental.ios.appExtensions zu deklarieren. Dann kennt EAS CLI sie schon vor dem Build und erstellt oder validiert ihre Credentials. Die meisten Bibliotheken, die eine Extension hinzufügen, schreiben diese Deklaration über ihr Plugin für dich.

Solys, mein Wecker mit Minispielen, enthält vier Extensions: ein Widget und drei Bildschirmzeit-Extensions. Alle vier sind in der Konfiguration deklariert, und EAS hat für jede ein Profil. Eine Extension, die von Hand in Xcode hinzugefügt wurde, ohne diese Deklaration, ist der ideale Kandidat für einen Pfad auf .appex in der Meldung.

Ein widerrufenes oder abgelaufenes Zertifikat

Apples Seite zu Zertifikaten ist eindeutig: Mit einem abgelaufenen oder widerrufenen Zertifikat signierte Builds kannst du nicht mehr hochladen. Ein bereits hochgeladener, aber noch nicht eingereichter Build kann sogar auf Invalid Binary wechseln, wenn sein Zertifikat widerrufen wurde.

Der Code von EAS CLI 24.10.0 zeigt, wann dieser Fall unbemerkt bleibt:

• Interaktiver Build, mit Apple verbunden: EAS vergleicht sein Zertifikat mit denen, die bei Apple noch gültig sind. Ist es dort nicht mehr dabei, zeigt es „Current distribution certificate is no longer valid in Apple Dev Portal“ an und bietet dir an, eins auszuwählen oder zu erstellen.
• Interaktiver Build, ohne Verbindung: EAS prüft nur die Daten und warnt, dass es die Validierung bei Apple überspringt.
• Nicht interaktiver Build, in der CI: EAS zeigt „Distribution Certificate is not validated for non-interactive builds“ an und signiert trotzdem.

In der CI prüft EAS das Zertifikat selbst nicht erneut: Ein Widerruf fällt womöglich erst beim Upload auf. Die Lösung: Starte einen interaktiven Build, verbunden mit deinem Apple-Account, oder geh über eas credentials --platform ios, Menü Build Credentials, dann „Distribution Certificate: Add a new one to your account“. Die Profile, die das alte Zertifikat enthielten, werden ungültig: EAS prüft sie beim nächsten Build und erstellt sie neu. Apples Limits für die Anzahl der Zertifikate findest du im Guide zum iOS-Entwicklerzertifikat.

Ein nach dem Signieren verändertes Binary

Die Signatur versiegelt Code, Ressourcen und Metadaten über Hashes, wie Apples Technical Note TN3126 erklärt. Die IPA zu entpacken, um eine Datei zu ändern, und sie dann wieder zu packen, bricht dieses Siegel. Nimm die Änderung in deiner Konfiguration vor und bau dann neu. Fass die von EAS erzeugte IPA niemals nachträglich an.

Dasselbe gilt für Code am falschen Ort, zum Beispiel in einem .zip-Archiv: Der App Store kann ihn nicht neu signieren. Apple beschreibt die erlaubten Orte auf seiner Seite über den Inhalt eines Bundles.

Lokale Credentials

Wenn dein EAS-Profil "credentialsSource": "local" nutzt, zeigt deine Datei credentials.json auf ein .p12-Zertifikat und ein .mobileprovision-Profil. Prüf das Profil mit den Befehlen aus Schritt 3: Es muss vom Typ App Store sein und dein aktuelles Distributionszertifikat enthalten. Und halte diese Dateien aus dem Repository heraus, genau wie die API-Schlüssel einer Expo-App.

Wenn alles gültig ist

Bleibt ein frustrierender Fall. Im Apple-Forum sehen Entwickler, wie der Fehler verschwindet, wenn sie denselben Build ohne Änderung noch einmal schicken. Im August und September 2026 beschreiben zwei Threads das Gegenteil: neues Zertifikat und neues Profil, Signatur geprüft, und der Fehler bleibt. In einem davon rät ein Apple-Ingenieur zu einem Bug-Report mit der IPA, der Signaturanalyse und den Transporter-Logs und danach zu einem Kontakt mit App Store Connect.

Schick also einmal neu, mit einer neuen Build-Nummer. Kommt der Fehler wieder, obwohl deine vier Befehle sauber sind, melde ihn Apple mit diesen Infos. Widerruf dein Zertifikat nicht reflexartig: Das löst nichts zusätzlich und macht deine Profile ungültig.

Deinen Build ohne böse Überraschung hochladen

Eine Signatur prüfst du in zwei Minuten vor dem Upload. Die anderen automatischen Prüfungen verlangen dieselbe Sorgfalt, etwa ITMS-90725 für die Xcode-Version oder ITMS-90683 für die Berechtigungstexte. Den kompletten Weg vom Build bis zum Upload, ohne Mac, findest du in eine iOS-App ohne Mac veröffentlichen.

Ablehnungen durch einen Reviewer brauchen mehr Abstand: Das Vorgehen steht auf der Seite App von Apple abgelehnt, die häufigsten Gründe in warum Apple eine App ablehnt.

Um dein Projekt vor dem Upload zu prüfen, vereint das Review Kit meine Checkliste und Claude-Code-Skills, die dein Projekt durchgehen. Wenn dein Upload hängt und du einen menschlichen Blick willst, buch eine Stunde mit mir: Wir gehen dein Projekt per Video auf deinem Bildschirm durch. Und wenn du deinen ersten Release vorbereitest, mach deine kostenlose Diagnose: Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen.

Häufige Fragen

Ist ITMS-90034 eine Ablehnung durch App Review?

Nein. Es ist eine automatische Validierung beim Upload des Builds, vor TestFlight und vor jedem Review. Niemand hat deine App geöffnet: Apple hat nur festgestellt, dass ihre Signatur nicht von einem gültigen Distributionszertifikat stammt.

Muss ich mein Distributionszertifikat widerrufen, um ITMS-90034 zu beheben?

Nur wenn es kompromittiert oder schon ungültig ist. Ein funktionierendes Zertifikat zu widerrufen macht deine Profile ungültig, ohne die Ursache zu beheben. Lies zuerst die Signatur deiner IPA mit codesign und behebe dann, worauf der Entscheidungsbaum zeigt.

Kann man ITMS-90034 mit einem Remote-Update beheben?

Nein. Die Signatur ist Teil des Binarys, und der abgelehnte Build wird nie nutzbar sein. Du musst ein neues, korrekt signiertes Binary erstellen und es neu hochladen.

Warum nennt der Fehler mein Widget und nicht meine App?

Weil das Widget ein eigenes Bundle ist, mit eigenem Profil signiert. Ist es EAS nicht bekannt oder wurde es anders signiert, lässt es den ganzen Upload scheitern. Deklarier die Extension in deiner Konfiguration und bau neu.

Was tun, wenn codesign sagt, dass alles gültig ist?

Prüf auch das eingebettete Profil und jede Extension. Ist alles sauber, schick einmal neu mit einer neuen Build-Nummer. Bleibt der Fehler, schick Apple einen Report mit der IPA, der Ausgabe von codesign und den Upload-Logs.