ITMS-90034 hiba: Missing or invalid signature javítása

ITMS-90034 akkor jön, amikor elküldöd a buildedet az App Store Connectbe. Azt jelenti, hogy az appod vagy valamelyik összetevője nincs Apple beküldési tanúsítvánnyal aláírva, vagyis nincs érvényes terjesztési (distribution) tanúsítványa. A javítás: megtalálni, melyik bundle van rosszul aláírva és miért, aztán újra buildelni App Store-ra aláírva.

Ez az útmutató a hibánál marad. Ha a tanúsítvány és a profil fogalma nem teljesen tiszta, előbb olvasd el ezt: iOS fejlesztői tanúsítvány és provisioning profile. Itt megtalálod, hogyan olvasd az üzenetet, egy döntési fát, az IPA-dat vizsgáló parancsokat és a javítást az EAS által kezelt hitelesítő adatokkal. Az EAS-es részhez elolvastam az EAS CLI 24.10.0 kódját, ami a tanúsítványt kiválasztja.

Mit jelent az ITMS-90034 hiba?

Ez a klasszikus formája, példanevekkel:

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.

2026-ban az Apple fórumán így is felbukkan: „Validation failed (409) Missing or invalid signature”, utána ugyanaz a szöveg és „(ID: 90034)”.

A „beküldési tanúsítvány” a terjesztési tanúsítványt jelenti. Az Apple tanúsítványokról szóló súgója le is írja: a fejlesztői tanúsítványokkal a saját eszközeiden futtatod az appot, a terjesztésiekkel terjeszted, vagy elküldöd az App Store Connectbe.

Olvasd el az idézett útvonalat: ez mutatja a hibás bundle-t. A Payload/MyApp.app magát az appot jelöli. A .appex végű útvonal egy bővítményt, például widgetet. A .framework végű egy beágyazott könyvtárat.

Ez nem egy reviewer elutasítása. Az ellenőrzés a feltöltéskor vagy a build feldolgozása közben fut, még TestFlight előtt: ez a build soha nem jut el a tesztelőidhez.

A döntési fa: az üzenettől a javításig

Minden sor egy jelnek felel meg, amit az üzenetben, a következő rész parancsaiban vagy az EAS naplóiban látsz. Sorban haladj: az első egyező sor adja az irányt.

Amit látsz	Valószínű ok	Javítás
.appex végű útvonal	Rosszul aláírt bővítmény	Bővítmény deklarálása
Signature=adhoc	Aláíratlan build	Build store profillal
Apple Development	Fejlesztői build	Build store profillal
ProvisionedDevices van	Belső (ad hoc) build	Build store profillal
sealed resource	Utólag módosított IPA	Új build
EAS: „no longer valid”	Visszavont tanúsítvány	Új tanúsítvány
Minden érvényes	Apple oldali hiba	Újraküldés, aztán bejelentés

Az IPA vizsgálata négy paranccsal

Töltsd le az IPA-t a build oldaláról az expo.dev-en, aztán nyiss egy terminált a Maceden.

1. Ki írta alá az appot?

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

A codesign a hibakimenetre ír, ezért kell a 2>&1. Az Apple TN3161-es technikai jegyzete szerint minden Authority sor a bizalmi lánc egy eleme. Az elsőnek Apple Distribution: vagy iPhone Distribution: kezdetűnek kell lennie, utána a csapatod neve. A második a régi iOS Distribution típus felirata: a kódja alapján az EAS CLI 24.10.0 még ilyen típusú tanúsítványokat hoz létre. Ha Apple Development: szerepel, az fejlesztői build. Ha Signature=adhoc szerepel, Authority sor nélkül, akkor a binárist semmilyen tanúsítvány nem írta alá.

2. Módosult az app az aláírás után?

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

Azt szeretnéd látni, hogy valid on disk, utána satisfies its Designated Requirement. A TN3161 pontosítja, mit garantál ez az ellenőrzés: minden várt fájl megvan, semmi nem került hozzá, semmi nem módosult. Egy általam aláírt, majd utólag megpiszkált teszt bundle-nél a parancs ezt válaszolja: a sealed resource is missing or invalid, aztán file modified: és a módosított fájl. A --deep kapcsoló itt ellenőrzésre való, aláírásra soha: az Apple fórumán a támogatási csapat egyik mérnöke ellenzi az aláíráshoz.

3. Melyik profil van beágyazva?

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

Ezek a profilokról szóló TN3125-ös jegyzet parancsai. Egy App Store profil nem tartalmaz eszközlistát: a második sornak Could not extract value választ kell adnia. Ha eszközazonosítókat mutat, az ad hoc profil, egy belső buildé. A harmadik a profil lejárati dátumát adja meg.

4. A bővítmények és frameworkök ugyanúgy vannak aláírva?

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

Minden összetevőnek ugyanazt az Authority sort kell mutatnia, mint az appnak. Ha valamelyik eltér, azt nevezi meg az üzenet.

Ha feltöltés előtt akarsz ellenőrizni, a TN3161 az altool-t ajánlja, ugyanazt az ellenőrzést, mint az Xcode Validate App gombja. Ehhez App Store Connect API-kulcs kell, aminek az AuthKey_<KEY_ID>.p8 fájlja a ~/.appstoreconnect/private_keys mappába kerül:

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

Javítás EAS-sel, okonként

Belső vagy fejlesztői build ment az Apple-nek

Az Expo eas.json dokumentációja szerint a "distribution": "internal" buildek nincsenek store-okra aláírva: ad hoc profilt használnak. Csak a store terjesztésű profil (ez az alapértelmezés) ad feltölthető buildet. A legbiztosabb, ha azt a buildet küldöd el, amit épp most készítettél, kézi választás nélkül:

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

Ha eas submit --path-szal küldesz, ellenőrizd, hogy a fájl tényleg a legutóbbi store buildod. Az Apple fórumán egy csapat rájött, hogy a feltöltőeszközük minden alkalommal egy régi, gitben tárolt IPA-t küldött el.

Elfelejtett bővítmény

Minden bővítmény külön bundle, saját azonosítóval és saját profillal. Natív generálású Expo projektben az Expo iOS bővítményekről szóló oldala azt kéri, hogy deklaráld őket az extra.eas.build.experimental.ios.appExtensions alatt. Így az EAS CLI már a build előtt ismeri őket, és létrehozza vagy ellenőrzi az azonosítóikat. A legtöbb könyvtár, ami bővítményt ad hozzá, a pluginjával ezt a deklarációt megírja helyetted.

A Solys, a minijátékos ébresztőm, négy bővítményt tartalmaz: egy widgetet és három Képernyőidő-bővítményt. Mind a négy deklarálva van a konfigurációjában, és az EAS-nek mindegyikhez van profilja. Egy kézzel, Xcode-ban hozzáadott bővítmény ilyen deklaráció nélkül a tökéletes gyanúsított, ha az üzenetben .appex útvonal szerepel.

Visszavont vagy lejárt tanúsítvány

Az Apple tanúsítványokról szóló oldala egyértelmű: lejárt vagy visszavont tanúsítvánnyal aláírt buildet már nem küldhetsz be. Egy már feltöltött, de még be nem küldött build akár Invalid Binary állapotba is kerülhet, ha a tanúsítványát visszavonták.

Az EAS CLI 24.10.0 kódjából kiderül, mikor marad ez észrevétlen:

• Interaktív build, Apple-be bejelentkezve: az EAS összeveti a tanúsítványát az Apple-nél még érvényesekkel. Ha már nincs ott, kiírja: „Current distribution certificate is no longer valid in Apple Dev Portal”, és felajánlja, hogy válassz vagy hozz létre egyet.
• Interaktív build, bejelentkezés nélkül: az EAS csak a dátumokat nézi, és figyelmeztet, hogy kihagyja az Apple-nél való ellenőrzést.
• Nem interaktív build, CI-ban: az EAS kiírja: „Distribution Certificate is not validated for non-interactive builds”, és ettől még aláír.

CI-ban az EAS nem ellenőrzi újra magát a tanúsítványt: a visszavonás lehet, hogy csak feltöltéskor derül ki. A javítás: indíts egy interaktív buildet az Apple-fiókodba bejelentkezve, vagy használd az eas credentials --platform ios parancsot, Build Credentials menü, aztán „Distribution Certificate: Add a new one to your account”. A régi tanúsítványt tartalmazó profilok érvénytelenné válnak: az EAS a következő buildnél ellenőrzi és újragenerálja őket. Az Apple tanúsítványszám-korlátairól az iOS fejlesztői tanúsítványról szóló útmutatóban olvashatsz.

Az aláírás után módosított bináris

Az aláírás hashekkel pecsételi le a kódot, az erőforrásokat és a metaadatokat, ahogy az Apple TN3126-os jegyzete elmagyarázza. Ha kicsomagolod az IPA-t, módosítasz egy fájlt, majd újra becsomagolod, eltöröd ezt a pecsétet. A módosítást a konfigurációdban végezd el, aztán buildelj újra. Az EAS által készített IPA-hoz soha ne nyúlj.

Ugyanez a logika, ha kód rossz helyre került, például egy .zip archívumba: az App Store nem tudja újra aláírni. Az engedélyezett helyeket az Apple a bundle tartalmáról szóló oldalán írja le.

Helyi hitelesítő adatok

Ha az EAS profilod "credentialsSource": "local" beállítást használ, a credentials.json fájlod egy .p12 tanúsítványra és egy .mobileprovision profilra mutat. Ellenőrizd a profilt a 3. lépés parancsaival: App Store típusúnak kell lennie, és a jelenlegi terjesztési tanúsítványodat kell tartalmaznia. Ezeket a fájlokat pedig tartsd a repón kívül, ahogy egy Expo app API-kulcsait is.

Ha minden érvényes

Marad egy bosszantó eset. Az Apple fórumán vannak fejlesztők, akiknél a hiba eltűnik, ha ugyanazt a buildet változtatás nélkül újraküldik. 2026 augusztusában és szeptemberében két szál az ellenkezőjét írja le: új tanúsítvány és profil, ellenőrzött aláírás, mégis tartós hiba. Az egyikben egy Apple-mérnök hibajelentést javasol az IPA-val, az aláírás-elemzéssel és a Transporter naplóival, majd kapcsolatfelvételt az App Store Connecttel.

Küldd el tehát még egyszer, új buildszámmal. Ha a hiba visszatér, pedig a négy parancsod tiszta eredményt ad, jelentsd az Apple-nek ezekkel az anyagokkal. Ne vond vissza reflexből a tanúsítványodat: semmit nem old meg, viszont érvényteleníti a profiljaidat.

Build feltöltése kellemetlen meglepetések nélkül

Egy aláírást két perc alatt ellenőrzöl feltöltés előtt. A többi automatikus ellenőrzés ugyanilyen alaposságot kíván, például az ITMS-90725 az Xcode verzióhoz vagy az ITMS-90683 az engedélykérő szövegekhez. A teljes út a buildtől a feltöltésig, Mac nélkül: iOS app publikálása Mac nélkül.

Egy reviewer elutasítása több rálátást igényel: a teendőket az Apple által elutasított alkalmazás oldalon találod, a leggyakoribb okokat pedig itt: miért utasítja el az Apple az appot.

Hogy feltöltés előtt átnézd az anyagodat, a Review Kit összegyűjti a checklistemet és Claude Code skilleket, amik átnézik a projektedet. Ha elakadt a feltöltés, és emberi szemre van szükséged, foglalj velem egy órát: videóhívásban, a te képernyődön átnézzük a projektedet. Ha pedig az első megjelenésedre készülsz, csináld meg az ingyenes diagnózist: sorba rakja a lépéseket, és elküldi neked az Apple-elutasítás elleni checklistemet.

Gyakori kérdések

Az ITMS-90034 egy App Review elutasítás?

Nem. Ez egy automatikus ellenőrzés a build feltöltésekor, TestFlight és bármilyen review előtt. Senki nem nyitotta meg az appodat: az Apple csak azt állapította meg, hogy az aláírása nem érvényes terjesztési tanúsítványtól származik.

Vissza kell vonnom a terjesztési tanúsítványomat az ITMS-90034 javításához?

Csak akkor, ha kompromittálódott vagy már érvénytelen. Egy működő tanúsítvány visszavonása érvényteleníti a profiljaidat, az okot pedig nem javítja. Kezdd azzal, hogy codesign-nal elolvasod az IPA aláírását, aztán javítsd, amire a döntési fa mutat.

Javítható az ITMS-90034 távoli frissítéssel?

Nem. Az aláírás a bináris része, és az elutasított build soha nem lesz használható. Új, helyesen aláírt binárist kell készítened és újra elküldened.

Miért a widgetemet nevezi meg a hiba, és nem az appot?

Mert a widget külön bundle, saját profillal aláírva. Ha nincs deklarálva az EAS-nek, vagy máshogy írták alá, az egész feltöltést elbuktatja. Deklaráld a bővítményt a konfigurációdban, és buildelj újra.

Mit tegyek, ha a codesign szerint minden érvényes?

Ellenőrizd a beágyazott profilt és minden bővítményt is. Ha minden tiszta, küldd el még egyszer új buildszámmal. Ha a hiba megmarad, küldj jelentést az Apple-nek az IPA-val, a codesign kimenetével és a feltöltési naplókkal.