ITMS-90034: åtgärda “Missing or invalid signature”

ITMS-90034 dyker upp när du skickar ditt build till App Store Connect. Felet säger att din app, eller någon av dess komponenter, inte är signerad med ett Apple submission certificate, alltså ett giltigt distributionscertifikat. Lösningen: ta reda på vilket bundle som är felsignerat och varför, och gör sedan ett nytt build som är signerat för App Store.

Den här guiden håller sig till själva felet. Om orden certifikat och profil känns luddiga, läs först iOS-utvecklarcertifikat och provisioning profile. Här hittar du meddelandet att läsa, ett beslutsträd, kommandona som inspekterar din IPA och lösningen med credentials som hanteras av EAS. För EAS-delen har jag läst koden i EAS CLI 24.10.0 som väljer certifikat.

Vad betyder felet ITMS-90034?

Så här ser det klassiska felet ut, med exempelnamn:

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.

Under 2026 dyker det på Apples forum även upp i formen "Validation failed (409) Missing or invalid signature", följt av samma text och "(ID: 90034)".

"Submission certificate" är distributionscertifikatet. Apples hjälp om certifikat skriver det rakt ut: utvecklingscertifikat används för att köra appen på dina enheter, distributionscertifikat för att distribuera den eller skicka den till App Store Connect.

Läs sökvägen i meddelandet: den pekar ut det felaktiga bundlet. Payload/MyApp.app gäller själva appen. En sökväg som slutar på .appex gäller en extension, till exempel en widget. En sökväg med .framework gäller ett inbäddat bibliotek.

Det här är inget avslag från en granskare. Valideringen sker vid uppladdningen eller när buildet bearbetas, före TestFlight: det här buildet kommer aldrig att nå dina testare.

Beslutsträdet: från meddelande till lösning

Varje rad motsvarar en ledtråd du hittar i meddelandet, i kommandona i nästa avsnitt eller i EAS-loggarna. Gå igenom dem i ordning: den första som stämmer visar vägen.

Det du ser	Trolig orsak	Lösning
Sökväg med .appex	Felsignerad extension	Deklarera extensionen
Signature=adhoc	Osignerat build	Build med store-profil
Apple Development	Utvecklingsbuild	Build med store-profil
ProvisionedDevices hittas	Internt build (ad hoc)	Build med store-profil
sealed resource	IPA ändrad i efterhand	Gör om buildet
EAS: "no longer valid"	Återkallat certifikat	Nytt certifikat
Allt är giltigt	Problem hos Apple	Skicka igen, rapportera sedan

Inspektera din IPA med fyra kommandon

Ladda ner IPA-filen från buildets sida på expo.dev och öppna sedan en terminal på din Mac.

1. Vem har signerat appen?

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

codesign skriver till standard error, därav 2>&1. Enligt Apples tekniska not TN3161 är varje Authority-rad en länk i förtroendekedjan. Den första ska börja med Apple Distribution: eller iPhone Distribution:, följt av ditt teams namn. Den andra etiketten hör till den äldre typen iOS Distribution: enligt koden skapar EAS CLI 24.10.0 fortfarande certifikat av den typen. Ser du Apple Development: är det ett utvecklingsbuild. Ser du Signature=adhoc utan någon Authority-rad är binären inte signerad med något certifikat alls.

2. Har appen ändrats efter signeringen?

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

Du vill se valid on disk och sedan satisfies its Designated Requirement. TN3161 förklarar vad kontrollen garanterar: alla förväntade filer finns, ingen har lagts till och ingen har ändrats. På ett testbundle som jag signerade och sedan ändrade svarar kommandot a sealed resource is missing or invalid, följt av file modified: och den ändrade filen. Flaggan --deep används här för att verifiera, aldrig för att signera: på Apples forum avråder en ingenjör från supportteamet från att använda den vid signering.

3. Vilken profil är inbäddad?

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

Det här är kommandona från noten TN3125 om profiler. En App Store-profil innehåller ingen lista över enheter: andra raden ska svara Could not extract value. Visar den enhets-ID:n är det en ad hoc-profil, alltså ett internt build. Tredje raden ger profilens utgångsdatum.

4. Är extensions och frameworks signerade på samma sätt?

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

Varje komponent ska visa samma Authority-rad som appen. Om någon avviker är det den som nämns i meddelandet.

Vill du kontrollera före uppladdningen rekommenderar TN3161 altool, samma kontroll som knappen Validate App i Xcode. Den kräver en App Store Connect API-nyckel, vars fil AuthKey_<KEY_ID>.p8 ska ligga i ~/.appstoreconnect/private_keys:

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

Åtgärda med EAS, orsak för orsak

Ett internt build eller utvecklingsbuild skickat till Apple

Enligt Expos dokumentation om eas.json är builds med "distribution": "internal" inte signerade för butikerna: de använder en ad hoc-profil. Bara en profil med distribution store, som är standardvärdet, ger ett build som går att skicka in. Säkrast är att skicka buildet du precis har byggt, utan att välja det för hand:

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

Om du använder eas submit --path, kontrollera att filen verkligen är ditt senaste store-build. På Apples forum upptäckte ett team att deras uppladdningsverktyg skickade en gammal IPA varje gång, en som låg versionshanterad i git.

En bortglömd extension

Varje extension är ett eget bundle, med eget ID och egen profil. I ett Expo-projekt med native-generering kräver Expos sida om iOS-extensions att du deklarerar dem i extra.eas.build.experimental.ios.appExtensions. Då känner EAS CLI till dem före buildet och skapar eller validerar deras credentials. De flesta bibliotek som lägger till en extension skriver den här deklarationen åt dig via sitt plugin.

Solys, min väckarklocka med minispel, har fyra extensions: en widget och tre extensions för Skärmtid. Alla fyra är deklarerade i konfigurationen och EAS har en profil för var och en. En extension som lagts till för hand i Xcode, utan den här deklarationen, är den perfekta kandidaten för en sökväg med .appex i meddelandet.

Ett återkallat eller utgånget certifikat

Apples sida om certifikat är tydlig: du kan inte längre skicka in ett build som är signerat med ett utgånget eller återkallat certifikat. Ett build som redan laddats upp men ännu inte skickats in för granskning kan till och med hamna i Invalid Binary om dess certifikat har återkallats.

Koden i EAS CLI 24.10.0 visar när det här passerar obemärkt:

• Interaktivt build, inloggad hos Apple: EAS jämför sitt certifikat med de som fortfarande är giltiga hos Apple. Finns det inte kvar visar EAS "Current distribution certificate is no longer valid in Apple Dev Portal" och låter dig välja eller skapa ett.
• Interaktivt build, utan inloggning: EAS kontrollerar bara datumen och varnar att valideringen hos Apple hoppas över.
• Icke-interaktivt build, i CI: EAS visar "Distribution Certificate is not validated for non-interactive builds" och signerar ändå.

I CI kontrollerar EAS inte själva certifikatet igen: en återkallelse kanske först märks vid uppladdningen. Lösningen: kör ett interaktivt build inloggad på ditt Apple-konto, eller kör eas credentials --platform ios, menyn Build Credentials och sedan "Distribution Certificate: Add a new one to your account". Profilerna som innehöll det gamla certifikatet blir ogiltiga: EAS kontrollerar dem vid nästa build och gör om dem. Apples gränser för antalet certifikat beskrivs i guiden om iOS-utvecklarcertifikat.

En binär som ändrats efter signeringen

Signaturen förseglar kod, resurser och metadata med hashvärden, som Apples not TN3126 förklarar. Att packa upp IPA-filen för att ändra en fil och sedan packa ihop den igen bryter förseglingen. Gör ändringen i din konfiguration och bygg sedan om. Ändra aldrig i IPA-filen som EAS har skapat.

Samma logik gäller kod som ligger på fel ställe, till exempel i ett .zip-arkiv: App Store kan inte signera om den. Apple beskriver de tillåtna platserna på sin sida om innehållet i ett bundle.

Lokala credentials

Om din EAS-profil använder "credentialsSource": "local" pekar filen credentials.json på ett .p12-certifikat och en .mobileprovision-profil. Kontrollera profilen med kommandona i steg 3: den ska vara av typen App Store och innehålla ditt nuvarande distributionscertifikat. Och håll de här filerna utanför repot, precis som API-nycklarna i en Expo-app.

När allt är giltigt

Det finns ett frustrerande fall kvar. På Apples forum ser utvecklare felet försvinna när de skickar samma build igen, utan att ändra något. I augusti och september 2026 beskriver två trådar motsatsen: nytt certifikat och ny profil, verifierad signatur, men felet kvarstår. I en av dem rekommenderar en Apple-ingenjör en buggrapport med IPA-filen, signaturanalysen och loggarna från Transporter, och sedan att kontakta App Store Connect.

Skicka alltså igen en gång med ett nytt buildnummer. Om felet kommer tillbaka trots att dina fyra kommandon ser rena ut, rapportera det till Apple med de här underlagen. Återkalla inte ditt certifikat av ren reflex: det löser ingenting mer och gör dina profiler ogiltiga.

Skicka ditt build utan obehagliga överraskningar

En signatur kontrollerar du på två minuter före uppladdningen. De andra automatiska kontrollerna kräver samma noggrannhet, till exempel ITMS-90725 för Xcode-versionen eller ITMS-90683 för behörighetstexterna. Hela vägen från build till uppladdning, utan Mac, finns i publicera en iOS-app utan Mac.

Avslag från en granskare kräver mer eftertanke: arbetsgången finns på sidan app avvisad av Apple, och de vanligaste skälen finns i varför Apple avvisar en app.

För att kontrollera ditt underlag före inskickningen samlar Review Kit min checklista och Claude Code-skills som går igenom ditt projekt. Om uppladdningen fastnar och du vill ha ett mänskligt öga, boka en timme med mig: vi går igenom ditt projekt i ett videosamtal, på din skärm. Och om du förbereder din första release, gör din gratis diagnostik: den lägger stegen i rätt ordning och skickar dig min checklista mot avslag från Apple.

Vanliga frågor

Är ITMS-90034 ett avslag från App Review?

Nej. Det är en automatisk validering som görs när buildet laddas upp, före TestFlight och före all granskning. Ingen har öppnat din app: Apple har bara konstaterat att signaturen inte kommer från ett giltigt distributionscertifikat.

Måste jag återkalla mitt distributionscertifikat för att åtgärda ITMS-90034?

Bara om det är komprometterat eller redan ogiltigt. Att återkalla ett certifikat som fungerar gör dina profiler ogiltiga utan att åtgärda orsaken. Börja med att läsa signaturen i din IPA med codesign och åtgärda sedan det som beslutsträdet pekar ut.

Kan man åtgärda ITMS-90034 med en fjärruppdatering?

Nej. Signaturen är en del av binären, och det avvisade buildet går aldrig att använda. Du måste ta fram en ny, korrekt signerad binär och skicka den igen.

Varför nämner felet min widget och inte min app?

För att widgeten är ett eget bundle, signerat med sin egen profil. Om den inte är deklarerad för EAS eller har signerats på annat sätt får den hela uppladdningen att misslyckas. Deklarera extensionen i din konfiguration och bygg om.

Vad gör jag om codesign säger att allt är giltigt?

Kontrollera även den inbäddade profilen och varje extension. Om allt ser rent ut, skicka igen en gång med ett nytt buildnummer. Om felet kvarstår, skicka en rapport till Apple med IPA-filen, utdata från codesign och uppladdningsloggarna.