ITMS-90034: oprava chyby „Missing or invalid signature“

ITMS-90034 sa objaví, keď posielaš build do App Store Connect. Hovorí, že tvoja app alebo niektorá jej časť nie je podpísaná certifikátom Apple na odosielanie, teda platným distribučným certifikátom. Oprava: zisti, ktorý bundle je zle podpísaný a prečo, a potom sprav nový build podpísaný pre App Store.

Tento návod sa drží len tejto chyby. Ak ti pojmy certifikát a profil nie sú úplne jasné, prečítaj si najprv vývojársky certifikát iOS a provisioning profile. Tu nájdeš, ako čítať správu, rozhodovací strom, príkazy na kontrolu IPA a opravu s prihlasovacími údajmi, ktoré spravuje EAS. Pri časti o EAS som prešiel kód EAS CLI 24.10.0, ktorý vyberá certifikát.

Čo znamená chyba ITMS-90034?

Takto vyzerá jej klasická podoba, s ukážkovými názvami:

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.

V roku 2026 sa na fóre Apple objavuje aj ako „Validation failed (409) Missing or invalid signature“, za ktorou nasleduje ten istý text a „(ID: 90034)“.

„Submission certificate“ je distribučný certifikát. Pomocník Apple k certifikátom to píše jasne: vývojárske certifikáty slúžia na spúšťanie appky na tvojich zariadeniach, distribučné na jej distribúciu alebo odoslanie do App Store Connect.

Prečítaj si uvedenú cestu: ukazuje na chybný bundle. Payload/MyApp.app znamená samotnú appku. Cesta končiaca na .appex znamená rozšírenie, napríklad widget. Cesta na .framework znamená vloženú knižnicu.

Nie je to zamietnutie od reviewera. Validácia zlyhá pri odosielaní alebo počas spracovania buildu, ešte pred TestFlightom: tento build sa k tvojim testerom nikdy nedostane.

Rozhodovací strom: od správy k oprave

Každý riadok zodpovedá stope, ktorú vidíš v správe, vo výstupe príkazov z ďalšej sekcie alebo v logoch EAS. Choď po nich v poradí: prvý, ktorý sedí, ti ukáže smer.

Čo vidíš	Pravdepodobná príčina	Oprava
Cesta na .appex	Zle podpísané rozšírenie	Deklarovať rozšírenie
Signature=adhoc	Nepodpísaný build	Build so store profilom
Apple Development	Vývojársky build	Build so store profilom
Načítané ProvisionedDevices	Interný build (ad hoc)	Build so store profilom
sealed resource	IPA upravená dodatočne	Spraviť nový build
EAS: „no longer valid“	Zrušený certifikát	Nový certifikát
Všetko je platné	Problém na strane Apple	Poslať znova, potom nahlásiť

Kontrola IPA štyrmi príkazmi

Stiahni si IPA zo stránky buildu na expo.dev a otvor terminál na Macu.

1. Kto appku podpísal?

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

codesign píše na chybový výstup, preto 2>&1. Podľa technickej poznámky Apple TN3161 je každý riadok Authority článkom reťazca dôvery. Prvý musí začínať na Apple Distribution: alebo iPhone Distribution: a za ním názov tvojho tímu. Druhé označenie patrí starému typu iOS Distribution: podľa svojho kódu EAS CLI 24.10.0 stále vytvára certifikáty tohto typu. Ak vidíš Apple Development:, ide o vývojársky build. Ak vidíš Signature=adhoc bez akéhokoľvek riadku Authority, binárka nie je podpísaná žiadnym certifikátom.

2. Bola appka po podpise upravená?

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

Chceš vidieť valid on disk a potom satisfies its Designated Requirement. TN3161 presne hovorí, čo táto kontrola zaručuje: všetky očakávané súbory sú na mieste, žiadny nepribudol a žiadny nebol zmenený. Na testovacom bundli, ktorý som podpísal a potom upravil, príkaz odpovedá a sealed resource is missing or invalid a potom file modified: so zmeneným súborom. Prepínač --deep tu slúži na overenie, nikdy nie na podpisovanie: inžinier z podpory Apple ho na fóre na podpisovanie neodporúča.

3. Aký profil je vlož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

Sú to príkazy z poznámky TN3125 o profiloch. Profil App Store neobsahuje žiadny zoznam zariadení: druhý riadok musí odpovedať Could not extract value. Ak vypíše identifikátory zariadení, je to ad hoc profil, teda profil interného buildu. Tretí riadok ukáže dátum expirácie profilu.

4. Sú rozšírenia a frameworky podpísané rovnako?

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

Každá časť musí ukázať rovnaký riadok Authority ako appka. Ak sa niektorá líši, práve tú uvádza správa.

Ak chceš overiť build ešte pred odoslaním, TN3161 odporúča altool, rovnakú kontrolu ako tlačidlo Validate App v Xcode. Potrebuje API kľúč App Store Connect, ktorého súbor AuthKey_<ID_CLE>.p8 patrí do ~/.appstoreconnect/private_keys:

xcrun altool --validate-app -f MonApp.ipa -t ios --api-key <ID_CLE> --api-issuer <ID_EMETTEUR>

Oprava cez EAS, príčinu po príčine

Interný alebo vývojársky build poslaný do Apple

Podľa dokumentácie Expo k eas.json nie sú buildy s "distribution": "internal" podpísané pre obchody: používajú ad hoc profil. Build, ktorý sa dá odoslať, vytvorí len profil s distribúciou store, čo je predvolená hodnota. Najistejšie je poslať build, ktorý si práve zostavil, bez ručného výberu:

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

Ak používaš eas submit --path, over si, že súbor je naozaj tvoj posledný store build. Na fóre Apple jeden tím zistil, že jeho nástroj na odosielanie zakaždým posielal starú IPA, uloženú v gite.

Zabudnuté rozšírenie

Každé rozšírenie je samostatný bundle s vlastným identifikátorom a vlastným profilom. V Expo projekte s generovaním natívneho kódu ich stránka Expo o iOS rozšíreniach žiada deklarovať v extra.eas.build.experimental.ios.appExtensions. EAS CLI ich potom pozná ešte pred buildom a vytvorí alebo overí ich prihlasovacie údaje. Väčšina knižníc, ktoré pridávajú rozšírenie, túto deklaráciu za teba zapíše cez svoj plugin.

Solys, môj budík s minihrami, obsahuje štyri rozšírenia: widget a tri rozšírenia pre Screen Time. Všetky štyri sú deklarované v jeho konfigurácii a EAS má profil pre každé z nich. Rozšírenie pridané ručne v Xcode bez tejto deklarácie je ideálny kandidát na cestu .appex v správe.

Zrušený alebo expirovaný certifikát

Stránka Apple o certifikátoch je jasná: build podpísaný expirovaným alebo zrušeným certifikátom už nemôžeš odoslať. Build, ktorý je už odoslaný, ale ešte nie je zaslaný na review, môže dokonca prejsť do stavu Invalid Binary, ak bol jeho certifikát zrušený.

Kód EAS CLI 24.10.0 ukazuje, kedy tento prípad prejde bez povšimnutia:

• Interaktívny build, prihlásený do Apple: EAS porovná svoj certifikát s tými, ktoré sú v Apple stále platné. Ak tam už nie je, vypíše „Current distribution certificate is no longer valid in Apple Dev Portal“ a ponúkne ti vybrať alebo vytvoriť iný.
• Interaktívny build bez prihlásenia: EAS skontroluje len dátumy a upozorní, že validáciu v Apple preskakuje.
• Neinteraktívny build v CI: EAS vypíše „Distribution Certificate is not validated for non-interactive builds“ a aj tak podpíše.

V CI EAS samotný certifikát znova neoveruje: zrušenie sa môže ukázať až pri odosielaní. Oprava: spusti interaktívny build prihlásený do svojho Apple účtu, alebo použi eas credentials --platform ios, menu Build Credentials a potom „Distribution Certificate: Add a new one to your account“. Profily, ktoré obsahovali starý certifikát, sa stanú neplatnými: EAS ich pri ďalšom builde skontroluje a vytvorí nanovo. Limity Apple na počet certifikátov nájdeš v návode k vývojárskemu certifikátu iOS.

Binárka upravená po podpise

Podpis zapečatí kód, zdroje a metadáta pomocou hashov, ako vysvetľuje poznámka Apple TN3126. Rozbalenie IPA kvôli zmene súboru a jej opätovné zabalenie túto pečať poruší. Zmenu sprav v konfigurácii a potom spusti nový build. IPA vytvorenú cez EAS nikdy ručne neupravuj.

Rovnaká logika platí pre kód uložený na zlom mieste, napríklad v archíve .zip: App Store ho nevie znova podpísať. Povolené umiestnenia Apple popisuje na stránke o obsahu bundlu.

Lokálne prihlasovacie údaje

Ak tvoj EAS profil používa "credentialsSource": "local", tvoj súbor credentials.json odkazuje na certifikát .p12 a profil .mobileprovision. Over profil príkazmi z kroku 3: musí byť typu App Store a obsahovať tvoj aktuálny distribučný certifikát. A tieto súbory drž mimo repozitára, rovnako ako API kľúče Expo appky.

Keď je všetko platné

Zostáva jeden frustrujúci prípad. Na fóre Apple niektorým vývojárom chyba zmizne, keď pošlú ten istý build znova, bez akejkoľvek zmeny. V auguste a septembri 2026 dve vlákna opisujú opak: nový certifikát aj profil, overený podpis, a chyba pretrváva. V jednom z nich inžinier Apple radí poslať hlásenie o chybe s IPA, analýzou podpisu a logmi z Transporteru a potom kontaktovať App Store Connect.

Pošli teda build ešte raz s novým číslom buildu. Ak sa chyba vráti, hoci tvoje štyri príkazy sú čisté, nahlás ju Apple s týmito podkladmi. Nerob reflexívne revoke certifikátu: nič navyše tým nevyriešiš a zneplatníš si profily.

Odoslanie buildu bez nepríjemných prekvapení

Podpis si overíš za dve minúty pred odoslaním. Ostatné automatické kontroly si žiadajú rovnakú dôslednosť, napríklad ITMS-90725 pre verziu Xcode alebo ITMS-90683 pre texty povolení. Celý postup od buildu po odoslanie, bez Macu, nájdeš v článku publikovanie iOS appky bez Macu.

Zamietnutia od reviewera si žiadajú viac nadhľadu: postup je na stránke appka zamietnutá od Apple a najčastejšie dôvody v článku prečo Apple zamieta appky.

Na kontrolu podkladov pred odoslaním ti Review Kit dá môj checklist a Claude Code skilly, ktoré prejdú tvoj projekt. Ak sa ti odosielanie zasekne a chceš ľudský pohľad, rezervuj si so mnou hodinu: prejdeme tvoj projekt cez video, na tvojej obrazovke. A ak chystáš svoje prvé vydanie, sprav si bezplatnú diagnostiku: zoradí ti kroky v správnom poradí a pošle ti môj checklist proti zamietnutiu od Apple.

Často kladené otázky

Je ITMS-90034 zamietnutie od App Review?

Nie. Je to automatická validácia pri odoslaní buildu, pred TestFlightom a pred akýmkoľvek review. Nikto tvoju appku neotvoril: Apple len zistil, že jej podpis nepochádza z platného distribučného certifikátu.

Musím na opravu ITMS-90034 zrušiť svoj distribučný certifikát?

Len ak je kompromitovaný alebo už neplatný. Zrušenie fungujúceho certifikátu zneplatní tvoje profily bez toho, aby opravilo príčinu. Začni tým, že si prečítaš podpis svojej IPA cez codesign, a potom oprav to, na čo ukáže rozhodovací strom.

Dá sa ITMS-90034 opraviť aktualizáciou na diaľku?

Nie. Podpis je súčasťou binárky a odmietnutý build nebude nikdy použiteľný. Musíš vytvoriť novú, správne podpísanú binárku a poslať ju znova.

Prečo chyba uvádza môj widget a nie appku?

Pretože widget je samostatný bundle podpísaný vlastným profilom. Ak nie je deklarovaný pre EAS alebo bol podpísaný inak, zhodí celé odoslanie. Deklaruj rozšírenie v konfigurácii a sprav nový build.

Čo robiť, ak codesign hovorí, že je všetko platné?

Skontroluj aj vložený profil a každé rozšírenie. Ak je všetko čisté, pošli build ešte raz s novým číslom buildu. Ak chyba pretrváva, pošli Apple hlásenie s IPA, výstupom codesign a logmi z odosielania.