ITMS-90034: løs “Missing or invalid signature”

ITMS-90034 dukker op, når du sender dit build til App Store Connect. Fejlen betyder, at din app eller en af dens komponenter ikke er signeret med et Apple submission certificate, altså et gyldigt distributionscertifikat. Løsningen: find ud af, hvilket bundle der er forkert signeret og hvorfor, og lav så et nyt build, der er signeret til App Store.

Den her guide handler kun om fejlen. Hvis ordene certifikat og profil er lidt uklare for dig, så læs først iOS-udviklercertifikat og provisioning profile. Her får du beskeden, du skal læse, et beslutningstræ, kommandoerne, der undersøger din IPA, og løsningen med de credentials, EAS håndterer. Til EAS-delen har jeg læst koden i EAS CLI 24.10.0, der vælger certifikatet.

Hvad betyder fejlen ITMS-90034?

Her er den klassiske form, med eksempelnavne:

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.

I 2026 ses den også på Apples forum som "Validation failed (409) Missing or invalid signature", efterfulgt af samme tekst og "(ID: 90034)".

"Submission certificate" er distributionscertifikatet. Apples hjælp om certifikater skriver det direkte: udviklingscertifikater bruges til at køre din app på dine egne enheder, distributionscertifikater til at distribuere den eller sende den til App Store Connect.

Læs stien i beskeden: den peger på det bundle, der fejler. Payload/MyApp.app er selve appen. En sti, der ender på .appex, er en extension, fx en widget. En sti med .framework er et indlejret bibliotek.

Det er ikke en afvisning fra en reviewer. Valideringen fejler ved upload eller under behandlingen af buildet, før TestFlight: det her build når aldrig ud til dine testere.

Beslutningstræet: fra besked til løsning

Hver række svarer til et spor, du kan læse i beskeden, i kommandoerne i næste afsnit eller i EAS' logs. Tag dem i rækkefølge: den første, der passer, giver dig retningen.

Det, du ser	Sandsynlig årsag	Løsning
Sti med .appex	Extension forkert signeret	Deklarér extensionen
Signature=adhoc	Build ikke signeret	Build med store-profil
Apple Development	Udviklingsbuild	Build med store-profil
ProvisionedDevices læst	Internt build (ad hoc)	Build med store-profil
sealed resource	IPA ændret bagefter	Byg igen
EAS: "no longer valid"	Certifikat tilbagekaldt	Nyt certifikat
Alt er gyldigt	Fejl hos Apple	Send igen, og rapportér

Undersøg din IPA med fire kommandoer

Download IPA'en fra buildets side på expo.dev, og åbn en terminal på din Mac.

1. Hvem har signeret appen?

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

codesign skriver til fejloutputtet, derfor 2>&1. Ifølge Apples tekniske note TN3161 er hver Authority-linje et led i tillidskæden. Den første skal starte med Apple Distribution: eller iPhone Distribution: efterfulgt af dit teams navn. Den anden betegnelse hører til den gamle type iOS Distribution: ifølge koden opretter EAS CLI 24.10.0 stadig certifikater af den type. Står der Apple Development:, er det et udviklingsbuild. Står der Signature=adhoc uden nogen Authority-linje, er binæren ikke signeret med noget certifikat.

2. Er appen blevet ændret efter signeringen?

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

Du vil se valid on disk og derefter satisfies its Designated Requirement. TN3161 præciserer, hvad tjekket garanterer: alle forventede filer er der, ingen er tilføjet, ingen er ændret. På et testbundle, som jeg signerede og derefter rettede i, svarer kommandoen a sealed resource is missing or invalid og så file modified: efterfulgt af den ændrede fil. Optionen --deep bruges her kun til at verificere, aldrig til at signere: på Apples forum fraråder en ingeniør fra supportteamet at bruge den til signering.

3. Hvilken profil er indlejret?

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

Det er kommandoerne fra noten TN3125 om profiler. En App Store-profil indeholder ingen liste over enheder: anden linje skal svare Could not extract value. Viser den enheds-id'er, er det en ad hoc-profil fra et internt build. Tredje linje giver profilens udløbsdato.

4. Er extensions og frameworks signeret på samme måde?

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

Hver komponent skal vise samme Authority-linje som appen. Afviger en af dem, er det den, beskeden nævner.

Vil du tjekke før upload, anbefaler TN3161 altool, samme kontrol som knappen Validate App i Xcode. Den kræver en App Store Connect API-nøgle, hvis fil AuthKey_<KEY_ID>.p8 skal ligge i ~/.appstoreconnect/private_keys:

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

Løs det med EAS, årsag for årsag

Et internt build eller udviklingsbuild sendt til Apple

Ifølge Expos dokumentation om eas.json bliver builds med "distribution": "internal" ikke signeret til stores: de bruger en ad hoc-profil. Kun en profil med distribution store, som er standardværdien, giver et build, der kan sendes. Det sikreste er at sende det build, du lige har bygget, uden at vælge det manuelt:

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

Bruger du eas submit --path, så tjek, at filen virkelig er dit seneste store-build. På Apples forum opdagede et team, at deres uploadværktøj hver gang sendte en gammel IPA, der lå versioneret i git.

En glemt extension

Hver extension er et separat bundle med sit eget id og sin egen profil. I et Expo-projekt med native generering beder Expos side om iOS-extensions dig om at deklarere dem i extra.eas.build.experimental.ios.appExtensions. Så kender EAS CLI dem før buildet og opretter eller validerer deres credentials. De fleste biblioteker, der tilføjer en extension, skriver den deklaration for dig via deres plugin.

Solys, min vækkeur-app med minispil, har fire extensions: en widget og tre Screen Time-extensions. Alle fire er deklareret i konfigurationen, og EAS har en profil til hver. En extension, der er tilføjet manuelt i Xcode uden den deklaration, er den oplagte mistænkte, når beskeden nævner en sti med .appex.

Et tilbagekaldt eller udløbet certifikat

Apples side om certifikater er klar: du kan ikke længere sende et build, der er signeret med et udløbet eller tilbagekaldt certifikat. Et build, der allerede er sendt, men endnu ikke indsendt til review, kan endda få status Invalid Binary, hvis dets certifikat er blevet tilbagekaldt.

Koden i EAS CLI 24.10.0 viser, hvornår det her tilfælde går ubemærket hen:

• Interaktivt build, logget ind hos Apple: EAS sammenligner sit certifikat med dem, der stadig er gyldige hos Apple. Er det der ikke længere, viser den "Current distribution certificate is no longer valid in Apple Dev Portal" og lader dig vælge eller oprette et.
• Interaktivt build, uden login: EAS tjekker kun datoerne og advarer om, at den springer valideringen hos Apple over.
• Ikke-interaktivt build, i CI: EAS viser "Distribution Certificate is not validated for non-interactive builds" og signerer alligevel.

I CI tjekker EAS ikke selve certifikatet igen: en tilbagekaldelse viser sig måske først ved upload. Løsningen: kør et interaktivt build logget ind på din Apple-konto, eller brug eas credentials --platform ios, menuen Build Credentials og derefter "Distribution Certificate: Add a new one to your account". Profilerne med det gamle certifikat bliver ugyldige: EAS tjekker dem ved næste build og laver dem igen. Apples grænser for antal certifikater står i guiden om iOS-udviklercertifikatet.

En binær ændret efter signering

Signaturen forsegler koden, ressourcerne og metadataene med hashes, som Apples note TN3126 forklarer. Pakker du IPA'en ud for at ændre en fil og pakker den sammen igen, bryder du forseglingen. Lav ændringen i din konfiguration, og byg igen. Ret aldrig i den IPA, EAS har produceret.

Samme logik gælder kode, der ligger det forkerte sted, fx i et .zip-arkiv: App Store kan ikke gen-signere den. Apple beskriver de tilladte placeringer på sin side om indholdet af et bundle.

Lokale credentials

Bruger din EAS-profil "credentialsSource": "local", peger din credentials.json på et .p12-certifikat og en .mobileprovision-profil. Tjek profilen med kommandoerne fra trin 3: den skal være af typen App Store og indeholde dit nuværende distributionscertifikat. Og hold de filer ude af repoet, ligesom API-nøglerne i en Expo-app.

Når alt er gyldigt

Der er ét frustrerende tilfælde tilbage. På Apples forum ser udviklere fejlen forsvinde ved at sende det samme build igen uden at ændre noget. I august og september 2026 beskriver to tråde det modsatte: nyt certifikat og ny profil, signatur verificeret, og fejlen bliver ved. I den ene anbefaler en Apple-ingeniør en fejlrapport med IPA'en, signaturanalysen og logs fra Transporter, og derefter at kontakte App Store Connect.

Send derfor igen én gang med et nyt buildnummer. Kommer fejlen igen, selvom dine fire kommandoer er rene, så rapportér den til Apple med de oplysninger. Tilbagekald ikke dit certifikat på refleks: det løser ikke mere og gør dine profiler ugyldige.

Send dit build uden ubehagelige overraskelser

En signatur kan tjekkes på to minutter før upload. De andre automatiske kontroller kræver samme omhu, fx ITMS-90725 for Xcode-versionen eller ITMS-90683 for tilladelsesteksterne. Hele forløbet fra build til upload, uden Mac, finder du i udgiv en iOS-app uden Mac.

Afvisninger fra en reviewer kræver mere overblik: fremgangsmåden står på siden app afvist af Apple, og de hyppigste årsager står i hvorfor Apple afviser en app.

Vil du tjekke dit projekt før upload, samler Review Kit min tjekliste og Claude Code-skills, der gennemgår dit projekt. Sidder din upload fast, og vil du have et menneskeligt blik på det, så book en time med mig: vi gennemgår dit projekt over video, på din skærm. Og forbereder du din første udgivelse, så tag din gratis diagnose: den sætter trinene i rækkefølge og sender dig min tjekliste mod afvisninger fra Apple.

Ofte stillede spørgsmål

Er ITMS-90034 en afvisning fra App Review?

Nej. Det er en automatisk validering ved upload af buildet, før TestFlight og før enhver review. Ingen har åbnet din app: Apple har kun konstateret, at signaturen ikke kommer fra et gyldigt distributionscertifikat.

Skal jeg tilbagekalde mit distributionscertifikat for at løse ITMS-90034?

Kun hvis det er kompromitteret eller allerede ugyldigt. Tilbagekalder du et certifikat, der virker, gør du dine profiler ugyldige uden at løse årsagen. Start med at læse signaturen på din IPA med codesign, og ret så det, beslutningstræet peger på.

Kan man løse ITMS-90034 med en opdatering over luften?

Nej. Signaturen er en del af binæren, og det afviste build kan aldrig bruges. Du skal lave en ny, korrekt signeret binær og sende den igen.

Hvorfor nævner fejlen min widget og ikke min app?

Fordi widgetten er et separat bundle, signeret med sin egen profil. Er den ikke deklareret over for EAS, eller er den signeret på en anden måde, får den hele uploaden til at fejle. Deklarér extensionen i din konfiguration, og byg igen.

Hvad gør jeg, hvis codesign siger, at alt er gyldigt?

Tjek også den indlejrede profil og hver extension. Er alt rent, så send igen én gang med et nyt buildnummer. Fortsætter fejlen, så send en rapport til Apple med IPA'en, outputtet fra codesign og upload-loggene.