ITMS-90034: oprava chyby Missing or invalid signature

ITMS-90034 přijde ve chvíli, kdy posíláš build do App Store Connect. Říká, že tvoje appka nebo některá její součást není podepsaná certifikátem Apple pro odesílání, tedy platným distribučním certifikátem. Oprava: zjistit, který bundle je špatně podepsaný a proč, a pak udělat nový build podepsaný pro App Store.

Tenhle návod se drží jen té chyby. Pokud ti slova certifikát a profil nic moc neříkají, přečti si nejdřív vývojářský certifikát iOS a provisioning profile. Tady najdeš, jak číst zprávu, rozhodovací strom, příkazy, které prozkoumají tvoje IPA, a opravu s přihlašovacími údaji spravovanými přes EAS. Kvůli části o EAS jsem prošel kód EAS CLI 24.10.0, který vybírá certifikát.

Co znamená chyba ITMS-90034?

Tady je její klasická podoba, s ukázkovými názvy:

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 roce 2026 se na fóru Apple objevuje i ve tvaru „Validation failed (409) Missing or invalid signature“, za kterým následuje stejný text a „(ID: 90034)“.

„Certifikát pro odesílání“ je distribuční certifikát. Nápověda Apple k certifikátům to píše jasně: vývojové certifikáty slouží ke spouštění appky na tvých zařízeních, distribuční k její distribuci nebo k odeslání do App Store Connect.

Přečti si uvedenou cestu: ukazuje na vadný bundle. Payload/MyApp.app míří na samotnou appku. Cesta končící na .appex míří na rozšíření, třeba widget. Cesta s .framework míří na vloženou knihovnu.

Nejde o zamítnutí od revieweru. Validace selže při odeslání nebo během zpracování buildu, ještě před TestFlightem: tenhle build se k tvým testerům nikdy nedostane.

Rozhodovací strom: od zprávy k opravě

Každý řádek odpovídá vodítku, které vyčteš ze zprávy, z příkazů v další sekci nebo z logů EAS. Projdi je popořadě: první, který sedí, ti ukáže směr.

Co vidíš	Pravděpodobná příčina	Oprava
Cesta s .appex	Špatně podepsané rozšíření	Deklarovat rozšíření
Signature=adhoc	Nepodepsaný build	Build se store profilem
Apple Development	Vývojový build	Build se store profilem
Přečteno ProvisionedDevices	Interní build (ad hoc)	Build se store profilem
sealed resource	IPA upravená dodatečně	Udělat nový build
EAS: „no longer valid“	Zneplatněný certifikát	Nový certifikát
Vše je platné	Problém na straně Apple	Poslat znovu, pak nahlásit

Prozkoumej své IPA čtyřmi příkazy

Stáhni si IPA ze stránky buildu na expo.dev a pak otevři terminál na svém Macu.

1. Kdo appku podepsal?

unzip -q MyApp.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, proto to 2>&1. Podle technické poznámky TN3161 od Apple je každý řádek Authority článkem řetězce důvěry. První musí začínat Apple Distribution: nebo iPhone Distribution: a za ním název tvého týmu. Druhé označení patří starému typu iOS Distribution: podle svého kódu EAS CLI 24.10.0 certifikáty tohoto typu pořád vytváří. Když uvidíš Apple Development:, jde o vývojový build. Když uvidíš Signature=adhoc bez jediného řádku Authority, binárka není podepsaná žádným certifikátem.

2. Byla appka po podpisu změněná?

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

Chceš vidět valid on disk a pak satisfies its Designated Requirement. TN3161 upřesňuje, co tahle kontrola zaručuje: všechny očekávané soubory jsou na místě, žádný nebyl přidán a žádný nebyl změněn. Na testovacím bundlu, který jsem podepsal a pak upravil, příkaz odpoví a sealed resource is missing or invalid a pak file modified: se změněným souborem. Volba --deep tu slouží k ověření, nikdy k podepisování: na fóru Apple ji inženýr z týmu podpory k podepisování nedoporučuje.

3. Jaký 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

To jsou příkazy z poznámky TN3125 o profilech. Profil pro App Store neobsahuje žádný seznam zařízení: druhý řádek musí odpovědět Could not extract value. Pokud vypíše identifikátory zařízení, jde o ad hoc profil, tedy profil interního buildu. Třetí řádek ukáže datum vypršení profilu.

4. Jsou rozšíření a frameworky podepsané stejně?

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

Každá součást musí ukázat stejný řádek Authority jako appka. Pokud se nějaká liší, právě ji zpráva uvádí.

Jestli to chceš ověřit před odesláním, TN3161 doporučuje altool, stejnou kontrolu jako tlačítko Validate App v Xcode. Potřebuje API klíč App Store Connect, jehož soubor AuthKey_<KEY_ID>.p8 patří do ~/.appstoreconnect/private_keys:

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

Oprava v EAS, příčinu po příčině

Interní nebo vývojový build odeslaný do Apple

Podle dokumentace Expo k eas.json nejsou buildy s "distribution": "internal" podepsané pro obchody: používají ad hoc profil. Odeslatelný build vytvoří jen profil s distribucí store, což je výchozí hodnota. Nejbezpečnější je poslat build, který jsi právě sestavil, aniž bys ho vybíral ručně:

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

Pokud používáš eas submit --path, ověř, že ten soubor je opravdu tvůj poslední store build. Na fóru Apple jeden tým zjistil, že jeho nástroj na odesílání pokaždé posílal staré IPA verzované v gitu.

Zapomenuté rozšíření

Každé rozšíření je samostatný bundle s vlastním identifikátorem a vlastním profilem. V projektu Expo s generováním nativního kódu chce stránka Expo o rozšířeních iOS, abys je deklaroval v extra.eas.build.experimental.ios.appExtensions. EAS CLI je pak zná ještě před buildem a vytvoří nebo ověří jejich přihlašovací údaje. Většina knihoven, které přidávají rozšíření, tuhle deklaraci zapíše za tebe přes svůj plugin.

Solys, můj budík s minihrami, obsahuje čtyři rozšíření: widget a tři rozšíření pro Čas u obrazovky. Všechna čtyři jsou deklarovaná v jeho konfiguraci a EAS má profil pro každé z nich. Rozšíření přidané ručně v Xcode bez této deklarace je ideální kandidát na cestu s .appex ve zprávě.

Zneplatněný nebo prošlý certifikát

Stránka Apple o certifikátech mluví jasně: build podepsaný prošlým nebo zneplatněným certifikátem už odeslat nemůžeš. Build, který už je odeslaný, ale ještě ne podaný k review, může dokonce přejít do stavu Invalid Binary, pokud byl jeho certifikát zneplatněn.

Kód EAS CLI 24.10.0 ukazuje, kdy tahle situace projde bez povšimnutí:

• Interaktivní build, přihlášený k Apple: EAS porovná svůj certifikát s těmi, které jsou u Apple pořád platné. Pokud tam už není, vypíše „Current distribution certificate is no longer valid in Apple Dev Portal“ a nabídne ti vybrat nebo vytvořit jiný.
• Interaktivní build bez přihlášení: EAS kontroluje jen data a upozorní, že ověření u Apple přeskakuje.
• Neinteraktivní build v průběžné integraci: EAS vypíše „Distribution Certificate is not validated for non-interactive builds“ a podepíše i tak.

V průběžné integraci EAS samotný certifikát znovu neověřuje: zneplatnění se může projevit až při odeslání. Oprava: spusť interaktivní build přihlášený k tvému účtu Apple, nebo použij eas credentials --platform ios, menu Build Credentials a pak „Distribution Certificate: Add a new one to your account“. Profily, které obsahovaly starý certifikát, se stanou neplatnými: EAS je při dalším buildu zkontroluje a vytvoří znovu. Limity Apple na počet certifikátů najdeš v návodu k vývojářskému certifikátu iOS.

Binárka upravená po podpisu

Podpis zapečetí kód, zdroje i metadata pomocí otisků (hashů), jak vysvětluje poznámka TN3126 od Apple. Rozbalit IPA, změnit soubor a znovu ji zabalit tuhle pečeť rozbije. Změnu udělej v konfiguraci a pak udělej nový build. IPA vytvořenou v EAS nikdy neupravuj.

Stejná logika platí pro kód uložený na špatném místě, třeba v archivu .zip: App Store ho nedokáže znovu podepsat. Povolená umístění Apple popisuje na stránce o obsahu bundlu.

Lokální přihlašovací údaje

Pokud tvůj profil v EAS používá "credentialsSource": "local", tvůj soubor credentials.json odkazuje na certifikát .p12 a profil .mobileprovision. Zkontroluj profil příkazy z kroku 3: musí být typu App Store a obsahovat tvůj aktuální distribuční certifikát. A drž tyhle soubory mimo repozitář, stejně jako API klíče Expo appky.

Když je všechno platné

Zbývá jeden frustrující případ. Na fóru Apple vývojářům chyba zmizí, když pošlou stejný build znovu, aniž by cokoli změnili. V srpnu a září 2026 popisují dvě vlákna opak: nový certifikát i profil, ověřený podpis, a selhání trvá. V jednom z nich inženýr Apple radí poslat hlášení chyby s IPA, analýzou podpisu a logy z Transporteru a pak kontaktovat App Store Connect.

Pošli tedy build jednou znovu s novým číslem buildu. Pokud se chyba vrátí, i když jsou tvé čtyři příkazy čisté, nahlas ji Apple s těmito podklady. Necháš-li se zlákat, nezneplatňuj certifikát reflexivně: nic dalšího tím nevyřešíš a zneplatníš si profily.

Odešli build bez nepříjemných překvapení

Podpis ověříš před odesláním za dvě minuty. Ostatní automatické kontroly chtějí stejnou pečlivost, třeba ITMS-90725 kvůli verzi Xcode nebo ITMS-90683 kvůli textům k oprávněním. Celou cestu od buildu po odeslání, bez Macu, najdeš v publikaci iOS appky bez Macu.

Zamítnutí od revieweru chtějí víc nadhledu: postup je na stránce appka zamítnutá Applem a nejčastější důvody v článku proč Apple zamítá appky.

Na kontrolu podkladů před odesláním je tu Review Kit, který obsahuje můj checklist a skills pro Claude Code, které ti projdou projekt. Pokud se ti odeslání zaseklo a chceš lidský pohled, zarezervuj si se mnou hodinu: projdeme tvůj projekt přes videohovor, přímo na tvé obrazovce. A pokud chystáš své první vydání, udělej si bezplatnou diagnostiku: seřadí ti kroky a pošle ti můj checklist proti zamítnutí od Apple.

Časté dotazy

Je ITMS-90034 zamítnutí od App Review?

Ne. Je to automatická validace při odeslání buildu, před TestFlightem a před jakýmkoli review. Nikdo tvou appku neotevřel: Apple jen zjistil, že její podpis nepochází z platného distribučního certifikátu.

Musím kvůli opravě ITMS-90034 zneplatnit svůj distribuční certifikát?

Jen pokud je kompromitovaný nebo už neplatný. Zneplatněním funkčního certifikátu zneplatníš své profily, aniž bys opravil příčinu. Začni tím, že si přečteš podpis svého IPA přes codesign, a pak oprav to, na co ukáže rozhodovací strom.

Dá se ITMS-90034 opravit aktualizací na dálku?

Ne. Podpis je součástí binárky a odmítnutý build už nikdy nepůjde použít. Musíš vytvořit novou, správně podepsanou binárku a poslat ji znovu.

Proč chyba uvádí můj widget, a ne appku?

Protože widget je samostatný bundle podepsaný vlastním profilem. Pokud není deklarovaný v EAS nebo byl podepsaný jinak, shodí celé odeslání. Deklaruj rozšíření v konfiguraci a udělej nový build.

Co dělat, když codesign tvrdí, že je všechno platné?

Zkontroluj i vložený profil a každé rozšíření. Pokud je všechno čisté, pošli build jednou znovu s novým číslem buildu. Pokud chyba trvá, pošli Apple hlášení s IPA, výstupem codesign a logy z odesílání.