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

> ITMS-90034: tvoj build nie je podpísaný platným distribučným certifikátom. Skontroluj podpis cez codesign a sprav nový store build cez EAS.

Pôvodná stránka: [ITMS-90034: oprava chyby „Missing or invalid signature“](https://devoria.fr/sk/blog/itms-90034-missing-or-invalid-signature-oprava)
Autor: [Mehdi Azizi](https://devoria.fr/sk/mehdi-azizi)
Zverejnenie: 2026-11-04
Posledná revízia obsahu: 2026-11-04


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

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

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

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

Sú to príkazy z [poznámky TN3125 o profiloch](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). 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?**

```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á č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`:

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

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

### Binárka upravená po podpise

Podpis zapečatí kód, zdroje a metadáta pomocou hashov, ako vysvetľuje [poznámka Apple TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes). 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](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle).

### 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](https://devoria.fr/sk/blog/tajny-api-kluc-expo-aplikacia).

### 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](https://devoria.fr/sk/blog/itms-90725-sdk-version-issue-expo) pre verziu Xcode alebo [ITMS-90683](https://devoria.fr/sk/blog/itms-90683-missing-purpose-string-expo) pre texty povolení. Celý postup od buildu po odoslanie, bez Macu, nájdeš v článku [publikovanie iOS appky bez Macu](https://devoria.fr/sk/blog/publikovanie-ios-aplikacie-bez-macu-expo-eas).

Zamietnutia od reviewera si žiadajú viac nadhľadu: postup je na stránke [appka zamietnutá od Apple](https://devoria.fr/sk/expertise/aplikacia-zamietnuta-apple) a najčastejšie dôvody v článku [prečo Apple zamieta appky](https://devoria.fr/sk/blog/zamietnutie-aplikacie-apple-pricina).

Na kontrolu podkladov pred odoslaním ti [Review Kit](https://devoria.fr/sk/kits/app-review) 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](https://devoria.fr/sk/coaching): prejdeme tvoj projekt cez video, na tvojej obrazovke. A ak chystáš svoje prvé vydanie, [sprav si bezplatnú diagnostiku](https://devoria.fr/sk/diagnostic): 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.


## Tvoj projekt

[Review Kit](https://devoria.fr/sk/kits/app-review): Môj checklist na App Store review, moje opravené zamietnutia od Apple, checklist pre Google Play a tri skilly pre Claude Code. 49 €.

[iOS & Android Kit](https://devoria.fr/sk/kits/ios): Vytvor si appku pre iPhone a Android s Claude Code: štartovací kód mojich appiek, cesta až do obchodov a všetky kity. 99 €.

[Diagnostika: čo ťa delí od tvojej iPhone appky](https://devoria.fr/sk/diagnostic): 7 otázok, 60 sekúnd: zistíš, čo ti naozaj bráni zverejniť tvoju iPhone appku, dostaneš cestu v 4 krokoch a kit, ktorý ti sedí.