ITMS-90034: popravak greške „Missing or invalid signature”

ITMS-90034 se pojavi kad šalješ build u App Store Connect. Kaže da tvoja aplikacija, ili neki njezin dio, nije potpisana Appleovim certifikatom za predaju, odnosno valjanim distribucijskim certifikatom. Rješenje: pronađi koji je bundle krivo potpisan i zašto, pa napravi novi build potpisan za App Store.

Ovaj vodič ostaje usredotočen na grešku. Ako su ti pojmovi certifikat i profil nejasni, prvo pročitaj iOS developerski certifikat i provisioning profile. Ovdje ćeš naći poruku koju treba pročitati, stablo odlučivanja, naredbe koje pregledavaju tvoj IPA i popravak s vjerodajnicama kojima upravlja EAS. Za dio o EAS-u pročitao sam kod EAS CLI 24.10.0 koji bira certifikat.

Što znači greška ITMS-90034?

Ovo je njezin klasični oblik, s primjerima imena:

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.

U 2026. se na Appleovom forumu pojavljuje i u obliku „Validation failed (409) Missing or invalid signature”, nakon čega slijedi isti tekst i „(ID: 90034)”.

„Certifikat za predaju” je distribucijski certifikat. Appleova pomoć o certifikatima to jasno piše: razvojni certifikati služe za pokretanje aplikacije na tvojim uređajima, a distribucijski za distribuciju ili slanje u App Store Connect.

Pročitaj navedenu putanju: ona pokazuje na problematični bundle. Payload/MyApp.app znači samu aplikaciju. Putanja koja završava na .appex znači ekstenziju, primjerice widget. Putanja na .framework znači ugrađenu biblioteku.

Ovo nije odbijanje od reviewera. Validacija padne pri slanju ili tijekom obrade builda, prije TestFlighta: taj build nikad neće stići do tvojih testera.

Stablo odlučivanja: od poruke do popravka

Svaki redak odgovara tragu koji čitaš u poruci, u naredbama iz sljedećeg odjeljka ili u EAS logovima. Idi redom: prvi koji odgovara daje ti smjer.

Što vidiš	Vjerojatni uzrok	Popravak
Putanja na .appex	Krivo potpisana ekstenzija	Deklariraj ekstenziju
Signature=adhoc	Nepotpisan build	Build sa store profilom
Apple Development	Razvojni build	Build sa store profilom
Pročitan ProvisionedDevices	Interni build (ad hoc)	Build sa store profilom
sealed resource	IPA naknadno izmijenjen	Ponovi build
EAS: „no longer valid”	Opozvan certifikat	Novi certifikat
Sve je valjano	Problem na Appleovoj strani	Pošalji ponovno, pa prijavi

Pregledaj svoj IPA u četiri naredbe

Preuzmi IPA sa stranice builda na expo.dev, pa otvori terminal na svom Macu.

1. Tko je potpisao aplikaciju?

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

codesign piše na izlaz za greške, zato 2>&1. Prema Appleovoj tehničkoj bilješci TN3161, svaki redak Authority je karika u lancu povjerenja. Prvi mora počinjati s Apple Distribution: ili iPhone Distribution:, nakon čega ide ime tvog tima. Druga oznaka pripada starom tipu iOS Distribution: prema svom kodu, EAS CLI 24.10.0 još uvijek stvara certifikate tog tipa. Ako pročitaš Apple Development:, to je razvojni build. Ako pročitaš Signature=adhoc bez ijednog retka Authority, binarna datoteka nije potpisana nijednim certifikatom.

2. Je li aplikacija izmijenjena nakon potpisivanja?

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

Želiš vidjeti valid on disk, pa satisfies its Designated Requirement. TN3161 precizira što ova provjera jamči: sve očekivane datoteke su tu, nijedna nije dodana, nijedna nije izmijenjena. Na testnom bundleu koji sam potpisao pa naknadno dirao, naredba odgovara a sealed resource is missing or invalid, pa file modified: i promijenjenu datoteku. Opcija --deep ovdje služi za provjeru, nikad za potpisivanje: na Appleovom forumu inženjer iz tima podrške ne preporučuje je za potpisivanje.

3. Koji je profil ugrađen?

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

To su naredbe iz bilješke TN3125 o profilima. App Store profil ne sadrži nikakav popis uređaja: drugi redak mora odgovoriti Could not extract value. Ako ispiše identifikatore uređaja, to je ad hoc profil, profil internog builda. Treći daje datum isteka profila.

4. Jesu li ekstenzije i frameworkovi potpisani jednako?

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

Svaka komponenta mora prikazati isti redak Authority kao aplikacija. Ako neka odstupa, upravo nju navodi poruka.

Ako želiš provjeriti prije slanja, TN3161 preporučuje altool, istu provjeru kao gumb Validate App u Xcodeu. Traži API ključ za App Store Connect, čija se datoteka AuthKey_<KEY_ID>.p8 sprema u ~/.appstoreconnect/private_keys:

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

Popravak s EAS-om, uzrok po uzrok

Interni ili razvojni build poslan Appleu

Prema Expo dokumentaciji o eas.json, buildovi s "distribution": "internal" nisu potpisani za trgovine: koriste ad hoc profil. Samo profil s distribucijom store, što je zadana vrijednost, daje build koji se može poslati. Najsigurnije je poslati build koji si upravo napravio, bez ručnog odabira:

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

Ako koristiš eas submit --path, provjeri je li datoteka stvarno tvoj zadnji store build. Na Appleovom forumu jedan je tim otkrio da njihov alat za slanje svaki put šalje stari IPA, spremljen u git.

Zaboravljena ekstenzija

Svaka ekstenzija je zaseban bundle, s vlastitim identifikatorom i vlastitim profilom. U Expo projektu s generiranjem nativnog koda, Expo stranica o iOS ekstenzijama traži da ih deklariraš u extra.eas.build.experimental.ios.appExtensions. Tada ih EAS CLI zna prije builda te stvara ili provjerava njihove vjerodajnice. Većina biblioteka koje dodaju ekstenziju napiše tu deklaraciju umjesto tebe, kroz svoj plugin.

Solys, moja budilica s mini-igrama, ima četiri ekstenzije: widget i tri Screen Time ekstenzije. Sve četiri su deklarirane u njezinoj konfiguraciji, a EAS ima profil za svaku. Ekstenzija dodana ručno u Xcodeu, bez te deklaracije, idealan je kandidat za putanju na .appex u poruci.

Opozvan ili istekao certifikat

Appleova stranica o certifikatima je jasna: više ne možeš poslati build potpisan isteklim ili opozvanim certifikatom. Build koji je već poslan, ali još nije predan, može čak prijeći u Invalid Binary ako mu je certifikat opozvan.

Kod EAS CLI 24.10.0 pokazuje kada ovaj slučaj prođe nezapaženo:

• Interaktivni build, prijavljen kod Applea: EAS uspoređuje svoj certifikat s onima koji su kod Applea još valjani. Ako ga tamo više nema, ispiše „Current distribution certificate is no longer valid in Apple Dev Portal” i ponudi ti da odabereš ili stvoriš novi.
• Interaktivni build, bez prijave: EAS provjerava samo datume i upozorava da preskače provjeru kod Applea.
• Neinteraktivni build, u kontinuiranoj integraciji: EAS ispiše „Distribution Certificate is not validated for non-interactive builds” i svejedno potpiše.

U kontinuiranoj integraciji EAS ne provjerava ponovno sam certifikat: opoziv se može vidjeti tek pri slanju. Popravak: pokreni interaktivni build prijavljen na svoj Apple račun ili idi kroz eas credentials --platform ios, izbornik Build Credentials, pa „Distribution Certificate: Add a new one to your account”. Profili koji su sadržavali stari certifikat postaju nevaljani: EAS ih provjeri pri sljedećem buildu i napravi ponovno. Appleova ograničenja broja certifikata detaljno su opisana u vodiču o iOS developerskom certifikatu.

Binarna datoteka izmijenjena nakon potpisivanja

Potpis zapečati kod, resurse i metapodatke pomoću hasheva, kako objašnjava Appleova bilješka TN3126. Raspakiravanje IPA-a da promijeniš datoteku i ponovno pakiranje razbija taj pečat. Napravi izmjenu u konfiguraciji, pa ponovi build. Nikad ne diraj IPA koji je napravio EAS.

Ista logika vrijedi za kod spremljen na krivo mjesto, primjerice u .zip arhivu: App Store ga ne može ponovno potpisati. Apple opisuje dopuštena mjesta na svojoj stranici o sadržaju bundlea.

Lokalne vjerodajnice

Ako tvoj EAS profil koristi "credentialsSource": "local", tvoja datoteka credentials.json pokazuje na certifikat .p12 i profil .mobileprovision. Provjeri profil naredbama iz koraka 3: mora biti tipa App Store i sadržavati tvoj trenutni distribucijski certifikat. I drži te datoteke izvan repozitorija, kao i API ključeve Expo aplikacije.

Kad je sve valjano

Ostaje jedan frustrirajući slučaj. Na Appleovom forumu developeri vide da greška nestane kad ponovno pošalju isti build, bez ikakve promjene. U kolovozu i rujnu 2026. dvije teme opisuju suprotno: novi certifikat i profil, provjeren potpis, a neuspjeh ostaje. U jednoj od njih Appleov inženjer savjetuje prijavu buga s IPA-om, analizom potpisa i Transporter logovima, a zatim kontakt s App Store Connectom.

Zato pošalji još jednom s novim brojem builda. Ako se greška vrati iako su tvoje četiri naredbe čiste, prijavi je Appleu s tim podacima. Nemoj refleksno opozvati certifikat: to ništa dodatno ne rješava, a poništi ti profile.

Pošalji build bez neugodnih iznenađenja

Potpis se provjeri za dvije minute prije slanja. Ostale automatske provjere traže istu temeljitost, poput ITMS-90725 za verziju Xcodea ili ITMS-90683 za tekstove dopuštenja. Cijeli put od builda do slanja, bez Maca, nalazi se u objavi iOS aplikacije bez Maca.

Odbijanja od reviewera traže više odmaka: postupak je na stranici aplikacija odbijena od Applea, a najčešći razlozi su u tekstu zašto Apple odbija aplikaciju.

Za provjeru svega prije slanja, Review Kit objedinjuje moju checklistu i Claude Code skillove koji pregledavaju tvoj projekt. Ako ti slanje zapne i želiš ljudski pogled, rezerviraj sat sa mnom: prolazimo tvoj projekt na videopozivu, na tvom ekranu. A ako pripremaš svoje prvo izdanje, napravi besplatnu dijagnozu: posloži korake redom i pošalje ti moju checklistu protiv Appleovih odbijanja.

Česta pitanja

Je li ITMS-90034 odbijanje od App Reviewa?

Ne. To je automatska validacija pri slanju builda, prije TestFlighta i prije bilo kakvog pregleda. Nitko nije otvorio tvoju aplikaciju: Apple je samo utvrdio da njezin potpis ne dolazi od valjanog distribucijskog certifikata.

Trebam li opozvati distribucijski certifikat da popravim ITMS-90034?

Samo ako je kompromitiran ili već nevaljan. Opoziv certifikata koji radi poništava tvoje profile, a ne popravlja uzrok. Počni čitanjem potpisa svog IPA-a pomoću codesign, pa popravi ono na što pokazuje stablo odlučivanja.

Može li se ITMS-90034 popraviti ažuriranjem na daljinu?

Ne. Potpis je dio binarne datoteke, a odbijeni build nikad neće biti upotrebljiv. Moraš napraviti novu, ispravno potpisanu binarnu datoteku i ponovno je poslati.

Zašto greška navodi moj widget, a ne aplikaciju?

Zato što je widget zaseban bundle, potpisan vlastitim profilom. Ako nije deklariran EAS-u ili je potpisan drukčije, ruši cijelo slanje. Deklariraj ekstenziju u konfiguraciji i ponovi build.

Što ako codesign kaže da je sve valjano?

Provjeri i ugrađeni profil i svaku ekstenziju. Ako je sve čisto, pošalji još jednom s novim brojem builda. Ako greška ostane, pošalji Appleu prijavu s IPA-om, izlazom naredbe codesign i logovima slanja.