# ITMS-90034: åtgärda “Missing or invalid signature” > ITMS-90034: ditt build är inte signerat med ett giltigt distributionscertifikat. Läs signaturen med codesign och gör ett nytt store-build med EAS. Originalsida: [ITMS-90034: åtgärda “Missing or invalid signature”](https://devoria.fr/sv/blog/itms-90034-missing-or-invalid-signature) Författare: [Mehdi Azizi](https://devoria.fr/sv/mehdi-azizi) Publicerad: 2026-11-04 Innehållet senast granskat: 2026-11-04 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](https://devoria.fr/sv/blog/ios-utvecklarcertifikat-provisioning-profile-expo). 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](https://developer.apple.com/help/account/certificates/certificates-overview) 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?** ```bash 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](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) ä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?** ```bash 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?** ```bash 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](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). 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?** ```bash 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_.p8` ska ligga i `~/.appstoreconnect/private_keys`: ```bash xcrun altool --validate-app -f MyApp.ipa -t ios --api-key --api-issuer ``` ## Åtgärda med EAS, orsak för orsak ### Ett internt build eller utvecklingsbuild skickat till Apple Enligt [Expos dokumentation om eas.json](https://docs.expo.dev/build/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**: ```bash 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](https://docs.expo.dev/build-reference/app-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](https://developer.apple.com/support/certificates/) ä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](https://devoria.fr/sv/blog/ios-utvecklarcertifikat-provisioning-profile-expo). ### En binär som ändrats efter signeringen Signaturen förseglar kod, resurser och metadata med hashvärden, som [Apples not TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes) 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](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-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](https://devoria.fr/sv/blog/hemlig-api-nyckel-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](https://devoria.fr/sv/blog/itms-90725-sdk-version-issue-expo) för Xcode-versionen eller [ITMS-90683](https://devoria.fr/sv/blog/itms-90683-missing-purpose-string-expo) för behörighetstexterna. Hela vägen från build till uppladdning, utan Mac, finns i [publicera en iOS-app utan Mac](https://devoria.fr/sv/blog/publicera-ios-app-utan-mac-expo-eas). Avslag från en granskare kräver mer eftertanke: arbetsgången finns på sidan [app avvisad av Apple](https://devoria.fr/sv/expertise/app-nekad-av-apple), och de vanligaste skälen finns i [varför Apple avvisar en app](https://devoria.fr/sv/blog/apple-avvisade-appen-orsaker). För att kontrollera ditt underlag före inskickningen samlar [Review Kit](https://devoria.fr/sv/kits/app-review) 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](https://devoria.fr/sv/coaching): 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](https://devoria.fr/sv/diagnostic): 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. ## Ditt projekt [Review Kit](https://devoria.fr/sv/kits/app-review): Min checklista för App Store-granskningen, mina avslag från Apple och hur jag fixade dem, en för Google Play och tre Claude Code-skills. 549 kr. [iOS & Android Kit](https://devoria.fr/sv/kits/ios): Bygg din app för iPhone och Android med Claude Code: startkoden från mina appar, hela vägen till butikerna och alla kit. 1 099 kr. [Diagnos: det som skiljer dig från din iPhone-app](https://devoria.fr/sv/diagnostic): 7 frågor, 60 sekunder: du får veta vad som egentligen hindrar dig från att publicera din iPhone-app, din väg i 4 steg och kitet som passar dig.