ITMS-90034: fiks «Missing or invalid signature»

ITMS-90034 dukker opp når du sender builden din til App Store Connect. Den sier at appen din, eller en av delene i den, ikke er signert med et Apple submission certificate, altså et gyldig distribusjonssertifikat. Løsningen: finn ut hvilken bundle som er feil signert og hvorfor, og lag deretter en ny build signert for App Store.

Denne guiden holder seg til selve feilen. Hvis ordene sertifikat og profil er litt uklare for deg, les først iOS-utviklersertifikat og provisioning profile. Her finner du meldingen du skal lese, et beslutningstre, kommandoene som inspiserer IPA-en din og løsningen med legitimasjon som EAS håndterer. For EAS-delen har jeg lest koden i EAS CLI 24.10.0 som velger sertifikatet.

Hva betyr feilen ITMS-90034?

Her er den vanlige formen, med eksempelnavn:

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 dukker den også opp på Apples forum som «Validation failed (409) Missing or invalid signature», etterfulgt av den samme teksten og «(ID: 90034)».

«Submission certificate» er distribusjonssertifikatet. Apples hjelpesider om sertifikater sier det rett ut: utviklingssertifikater brukes til å kjøre appen på dine egne enheter, distribusjonssertifikater til å distribuere den eller sende den til App Store Connect.

Les stien som nevnes: den peker på bundelen som er feil. Payload/MyApp.app gjelder selve appen. En sti som slutter på .appex gjelder en utvidelse, for eksempel en widget. En sti på .framework gjelder et innebygd bibliotek.

Dette er ikke en avvisning fra en reviewer. Valideringen slår til ved opplasting eller mens builden behandles, før TestFlight: denne builden kommer aldri frem til testerne dine.

Beslutningstreet: fra melding til løsning

Hver rad tilsvarer et tegn du ser i meldingen, i kommandoene i neste seksjon eller i EAS-loggene. Gå gjennom dem i rekkefølge: den første som passer, viser deg veien.

Det du ser	Sannsynlig årsak	Løsning
Sti på .appex	Feil signert utvidelse	Deklarer utvidelsen
Signature=adhoc	Usignert build	Build med store-profil
Apple Development	Utviklingsbuild	Build med store-profil
ProvisionedDevices funnet	Intern build (ad hoc)	Build med store-profil
sealed resource	IPA endret i etterkant	Lag builden på nytt
EAS: «no longer valid»	Tilbakekalt sertifikat	Nytt sertifikat
Alt er gyldig	Feil hos Apple	Send på nytt, så rapporter

Inspiser IPA-en din med fire kommandoer

Last ned IPA-en fra build-siden på expo.dev, og åpne en terminal på Mac-en din.

1. Hvem signerte 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 standard error, derav 2>&1. Ifølge Apples tekniske notat TN3161 er hver Authority-linje et ledd i tillitskjeden. Den første må begynne med Apple Distribution: eller iPhone Distribution:, etterfulgt av navnet på teamet ditt. Den andre betegnelsen hører til den gamle typen iOS Distribution: ifølge koden lager EAS CLI 24.10.0 fortsatt sertifikater av denne typen. Ser du Apple Development:, er det en utviklingsbuild. Ser du Signature=adhoc uten noen Authority-linje, er binærfilen ikke signert med noe sertifikat.

2. Er appen endret etter signeringen?

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

Du vil se valid on disk, og deretter satisfies its Designated Requirement. TN3161 forklarer hva denne sjekken garanterer: alle forventede filer er der, ingen er lagt til, ingen er endret. På en testbundle jeg signerte og så endret, svarer kommandoen a sealed resource is missing or invalid, og deretter file modified: etterfulgt av den endrede filen. Flagget --deep er her bare for å verifisere, aldri for å signere: på Apples forum fraråder en ingeniør fra supportteamet å bruke det til signering.

3. Hvilken profil er bygd inn?

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

Dette er kommandoene fra notatet TN3125 om profiler. En App Store-profil inneholder ingen enhetsliste: den andre linjen skal svare Could not extract value. Viser den enhets-ID-er, er det en ad hoc-profil, altså en intern build. Den tredje gir utløpsdatoen til profilen.

4. Er utvidelsene og rammeverkene signert likt?

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. Hvis én av dem avviker, er det den meldingen nevner.

Vil du sjekke før opplasting, anbefaler TN3161 altool, den samme kontrollen som Validate App-knappen i Xcode. Den krever en App Store Connect API-nøkkel, der filen AuthKey_<KEY_ID>.p8 legges i ~/.appstoreconnect/private_keys:

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

Fiks det med EAS, årsak for årsak

En intern build eller utviklingsbuild sendt til Apple

Ifølge Expos dokumentasjon om eas.json er builds med "distribution": "internal" ikke signert for butikkene: de bruker en ad hoc-profil. Bare en profil med distribusjon store, som er standardverdien, gir en build du kan sende inn. Det sikreste er å sende builden du nettopp har laget, uten å velge den manuelt:

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

Bruker du eas submit --path, sjekk at filen faktisk er din siste store-build. På Apples forum oppdaget et team at opplastingsverktøyet deres sendte en gammel IPA hver gang, en som lå versjonert i git.

En glemt utvidelse

Hver utvidelse er en egen bundle, med egen identifikator og egen profil. I et Expo-prosjekt med native generering ber Expos side om iOS-utvidelser deg deklarere dem i extra.eas.build.experimental.ios.appExtensions. Da kjenner EAS CLI dem før builden, og oppretter eller validerer legitimasjonen deres. De fleste biblioteker som legger til en utvidelse, skriver denne deklarasjonen for deg via sin plugin.

Solys, vekkerklokka mi med minispill, har fire utvidelser: en widget og tre Skjermtid-utvidelser. Alle fire er deklarert i konfigurasjonen, og EAS har en profil for hver av dem. En utvidelse lagt til manuelt i Xcode, uten denne deklarasjonen, er den perfekte kandidaten når meldingen viser en sti på .appex.

Et tilbakekalt eller utløpt sertifikat

Apples side om sertifikater er tydelig: du kan ikke lenger laste opp en build signert med et utløpt eller tilbakekalt sertifikat. En build som allerede er lastet opp, men ikke sendt til gjennomgang, kan til og med gå over til Invalid Binary hvis sertifikatet er tilbakekalt.

Koden i EAS CLI 24.10.0 viser når dette går ubemerket hen:

• Interaktiv build, logget inn hos Apple: EAS sammenligner sertifikatet med dem som fortsatt er gyldige hos Apple. Er det ikke der lenger, viser den «Current distribution certificate is no longer valid in Apple Dev Portal» og lar deg velge eller lage et nytt.
• Interaktiv build, uten innlogging: EAS sjekker bare datoene og advarer om at den hopper over valideringen hos Apple.
• Ikke-interaktiv build, i CI: EAS viser «Distribution Certificate is not validated for non-interactive builds» og signerer likevel.

I CI sjekker ikke EAS selve sertifikatet på nytt: en tilbakekalling kan først vise seg ved opplasting. Løsningen: kjør en interaktiv build logget inn med Apple-kontoen din, eller bruk eas credentials --platform ios, menyen Build Credentials, og deretter «Distribution Certificate: Add a new one to your account». Profilene som inneholdt det gamle sertifikatet, blir ugyldige: EAS sjekker dem ved neste build og lager dem på nytt. Apples grenser for antall sertifikater er forklart i guiden om iOS-utviklersertifikatet.

En binærfil endret etter signering

Signaturen forsegler koden, ressursene og metadataene med hasher, som Apples notat TN3126 forklarer. Å pakke ut IPA-en for å endre en fil og så pakke den sammen igjen bryter forseglingen. Gjør endringen i konfigurasjonen din, og lag builden på nytt. Rør aldri IPA-en som EAS har laget.

Samme logikk gjelder for kode som ligger på feil sted, for eksempel i et .zip-arkiv: App Store kan ikke signere den på nytt. Apple beskriver de tillatte plasseringene på siden om innholdet i en bundle.

Lokal legitimasjon

Hvis EAS-profilen din bruker "credentialsSource": "local", peker credentials.json-filen din til et .p12-sertifikat og en .mobileprovision-profil. Sjekk profilen med kommandoene fra steg 3: den må være av typen App Store og inneholde det nåværende distribusjonssertifikatet ditt. Og hold disse filene utenfor repoet, akkurat som API-nøklene i en Expo-app.

Når alt er gyldig

Det gjenstår ett frustrerende tilfelle. På Apples forum ser utviklere at feilen forsvinner når de sender den samme builden på nytt, uten å endre noe. I august og september 2026 beskriver to tråder det motsatte: nytt sertifikat og ny profil, verifisert signatur, feilen står fast. I én av dem anbefaler en Apple-ingeniør en feilrapport med IPA-en, signaturanalysen og Transporter-loggene, og deretter å kontakte App Store Connect.

Send derfor på nytt én gang med et nytt build-nummer. Kommer feilen tilbake selv om de fire kommandoene dine er rene, rapporter den til Apple med disse vedleggene. Ikke tilbakekall sertifikatet ditt på refleks: det løser ingenting mer, og det gjør profilene dine ugyldige.

Send builden din uten ubehagelige overraskelser

En signatur sjekkes på to minutter før opplasting. De andre automatiske kontrollene krever samme grundighet, som ITMS-90725 for Xcode-versjonen eller ITMS-90683 for tillatelsestekstene. Hele veien fra build til opplasting, uten Mac, finner du i publiser en iOS-app uten Mac.

Avvisninger fra en reviewer krever mer ettertanke: fremgangsmåten står på siden app avvist av Apple, og de vanligste årsakene finner du i hvorfor Apple avviser en app.

For å sjekke prosjektet ditt før opplasting samler Review Kit sjekklisten min og Claude Code-skills som går gjennom prosjektet ditt. Står opplastingen fast og du vil ha et menneskelig blikk, book en time med meg: vi går gjennom prosjektet ditt på video, på din skjerm. Og forbereder du din første lansering, ta den gratis diagnosen: den setter stegene i riktig rekkefølge og sender deg sjekklisten min mot avvisning fra Apple.

Ofte stilte spørsmål

Er ITMS-90034 en avvisning fra App Review?

Nei. Det er en automatisk validering som skjer når builden lastes opp, før TestFlight og før noen gjennomgang. Ingen har åpnet appen din: Apple har bare sett at signaturen ikke kommer fra et gyldig distribusjonssertifikat.

Må jeg tilbakekalle distribusjonssertifikatet mitt for å fikse ITMS-90034?

Bare hvis det er kompromittert eller allerede ugyldig. Å tilbakekalle et sertifikat som fungerer, gjør profilene dine ugyldige uten å fikse årsaken. Start med å lese signaturen til IPA-en din med codesign, og fiks så det beslutningstreet peker på.

Kan man fikse ITMS-90034 med en oppdatering over nett?

Nei. Signaturen er en del av binærfilen, og den avviste builden blir aldri brukbar. Du må lage en ny, riktig signert binærfil og sende den på nytt.

Hvorfor nevner feilen widgeten min og ikke appen?

Fordi widgeten er en egen bundle, signert med sin egen profil. Hvis den ikke er deklarert for EAS eller er signert på en annen måte, får den hele opplastingen til å feile. Deklarer utvidelsen i konfigurasjonen din og lag builden på nytt.

Hva gjør jeg hvis codesign sier at alt er gyldig?

Sjekk også den innebygde profilen og hver utvidelse. Er alt rent, send på nytt én gang med et nytt build-nummer. Står feilen fast, send en rapport til Apple med IPA-en, utdataene fra codesign og opplastingsloggene.