# ITMS-90034: oprava chyby Missing or invalid signature

> ITMS-90034: tvůj build není podepsaný platným distribučním certifikátem. Přečti si podpis přes codesign a udělej nový store build v EAS.

Původní stránka: [ITMS-90034: oprava chyby Missing or invalid signature](https://devoria.fr/cs/blog/itms-90034-missing-or-invalid-signature-oprava)
Autor: [Mehdi Azizi](https://devoria.fr/cs/mehdi-azizi)
Publikováno: 2026-11-04
Poslední revize obsahu: 2026-11-04


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](https://devoria.fr/cs/blog/ios-certifikat-vyvojare-provisioning-profile-expo). 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](https://developer.apple.com/help/account/certificates/certificates-overview) 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?**

```bash
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](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) 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á?**

```bash
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ý?**

```bash
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](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). 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ě?**

```bash
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`:

```bash
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](https://docs.expo.dev/build/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ě**:

```bash
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](https://docs.expo.dev/build-reference/app-extensions/), 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](https://developer.apple.com/support/certificates/) 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](https://devoria.fr/cs/blog/ios-certifikat-vyvojare-provisioning-profile-expo).

### Binárka upravená po podpisu

Podpis zapečetí kód, zdroje i metadata pomocí otisků (hashů), jak vysvětluje [poznámka TN3126 od Apple](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes). 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](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle).

### 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](https://devoria.fr/cs/blog/tajny-api-klic-aplikace-expo).

### 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](https://devoria.fr/cs/blog/itms-90725-sdk-version-issue-expo) kvůli verzi Xcode nebo [ITMS-90683](https://devoria.fr/cs/blog/itms-90683-missing-purpose-string-expo) 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](https://devoria.fr/cs/blog/publikace-ios-aplikace-bez-macu-expo-eas).

Zamítnutí od revieweru chtějí víc nadhledu: postup je na stránce [appka zamítnutá Applem](https://devoria.fr/cs/expertise/aplikace-zamitnuta-applem) a nejčastější důvody v článku [proč Apple zamítá appky](https://devoria.fr/cs/blog/apple-zamitl-aplikaci-duvody).

Na kontrolu podkladů před odesláním je tu [Review Kit](https://devoria.fr/cs/kits/app-review), 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](https://devoria.fr/cs/coaching): projdeme tvůj projekt přes videohovor, přímo na tvé obrazovce. A pokud chystáš své první vydání, [udělej si bezplatnou diagnostiku](https://devoria.fr/cs/diagnostic): 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í.


## Tvůj projekt

[Review Kit](https://devoria.fr/cs/kits/app-review): Můj checklist pro review v App Store, moje opravená zamítnutí od Applu, checklist pro Google Play a tři skilly pro Claude Code. 1 199 Kč.

[iOS & Android Kit](https://devoria.fr/cs/kits/ios): Vytvoř si aplikaci pro iPhone a Android s Claude Code: startovní kód mých aplikací, cesta až do obchodů a všechny kity. 2 399 Kč.

[Diagnostika: co tě dělí od tvé iPhone aplikace](https://devoria.fr/cs/diagnostic): 7 otázek, 60 sekund: zjistíš, co ti doopravdy brání vydat iPhone aplikaci, dostaneš cestu ve 4 krocích a kit přesně pro tebe.