# ITMS-90034: як виправити «Missing or invalid signature»

> ITMS-90034 означає, що твій build не підписаний чинним сертифікатом дистрибуції. Перевір підпис через codesign і зроби новий store build в EAS.

Оригінальна сторінка: [ITMS-90034: як виправити «Missing or invalid signature»](https://devoria.fr/uk/blog/itms-90034-missing-invalid-signature-fix)
Автор: [Mehdi Azizi](https://devoria.fr/uk/mehdi-azizi)
Опубліковано: 2026-11-04
Останнє оновлення змісту: 2026-11-04


ITMS-90034 з'являється, коли ти надсилаєш build в App Store Connect. Вона означає, що твій застосунок або один із його компонентів не підписаний сертифікатом Apple для надсилання (submission certificate), тобто чинним сертифікатом дистрибуції. **Як виправити: знайди, який bundle підписаний неправильно і чому, а потім зроби новий build, підписаний для App Store.**

Цей гайд присвячений лише цій помилці. Якщо слова «сертифікат» і «профіль» тобі поки незрозумілі, спершу прочитай про [сертифікат розробника iOS і provisioning profile](https://devoria.fr/uk/blog/ios-developer-certificate-provisioning-profile-expo). Тут ти знайдеш, як читати повідомлення, дерево рішень, команди для перевірки IPA і виправлення з обліковими даними, якими керує EAS. Для частини про EAS я прочитав код EAS CLI 24.10.0, який обирає сертифікат.

## Що означає помилка ITMS-90034?

Ось її типовий вигляд, з умовними назвами:

> 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 році на форумі Apple вона трапляється ще й у вигляді «Validation failed (409) Missing or invalid signature», після чого йде той самий текст і «(ID: 90034)».

«Сертифікат для надсилання» означає сертифікат дистрибуції. [Довідка Apple про сертифікати](https://developer.apple.com/help/account/certificates/certificates-overview) пише прямо: сертифікати розробки потрібні, щоб запускати застосунок на твоїх пристроях, а сертифікати дистрибуції потрібні, щоб його поширювати або надсилати в App Store Connect.

**Читай шлях у повідомленні: він вказує на проблемний bundle.** `Payload/MyApp.app` вказує на сам застосунок. Шлях, що закінчується на `.appex`, вказує на розширення, наприклад віджет. Шлях на `.framework` вказує на вбудовану бібліотеку.

Це не відмова рев'юера. Перевірка падає під час надсилання або обробки build, ще до TestFlight: цей build ніколи не дійде до твоїх тестувальників.

## Дерево рішень: від повідомлення до виправлення

Кожен рядок відповідає підказці, яку ти бачиш у повідомленні, у командах з наступного розділу або в журналах EAS. Іди по порядку: перший рядок, що збігається, і є твоїм напрямком.

| Що ти бачиш            | Імовірна причина           | Виправлення                  |
| ---------------------- | -------------------------- | ---------------------------- |
| Шлях на `.appex`       | Розширення підписане хибно | Оголосити розширення         |
| `Signature=adhoc`      | Build не підписаний        | Build із профілем store      |
| `Apple Development`    | Build для розробки         | Build із профілем store      |
| Є `ProvisionedDevices` | Внутрішній build (ad hoc)  | Build із профілем store      |
| `sealed resource`      | IPA змінили після збирання | Зібрати build заново         |
| EAS: «no longer valid» | Сертифікат відкликано      | Новий сертифікат             |
| Усе чинне              | Збій на боці Apple         | Надіслати ще раз, повідомити |

## Перевір свою IPA чотирма командами

Завантаж IPA зі сторінки build на expo.dev і відкрий термінал на своєму Mac.

**1. Хто підписав застосунок?**

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

`codesign` пише у вивід помилок, тому й потрібен `2>&1`. Згідно з [технічною нотаткою Apple TN3161](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates), кожен рядок `Authority` це ланка ланцюжка довіри. Перший має починатися з `Apple Distribution:` або `iPhone Distribution:`, а далі йде назва твоєї команди. Другий варіант належить старому типу iOS Distribution: судячи з коду, EAS CLI 24.10.0 досі створює сертифікати цього типу. Якщо бачиш `Apple Development:`, це build для розробки. Якщо бачиш `Signature=adhoc` без жодного рядка `Authority`, бінарник не підписаний жодним сертифікатом.

**2. Чи змінювали застосунок після підпису?**

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

Ти хочеш побачити `valid on disk`, а потім `satisfies its Designated Requirement`. TN3161 уточнює, що гарантує ця перевірка: усі очікувані файли на місці, жодного не додано і жодного не змінено. На тестовому bundle, який я підписав і потім підправив, команда відповідає `a sealed resource is missing or invalid`, а далі `file modified:` і змінений файл. Опція `--deep` тут лише для перевірки, ніколи не для підпису: на форумі Apple інженер команди підтримки не радить використовувати її для підпису.

**3. Який профіль вбудовано?**

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

Це команди з [нотатки TN3125 про профілі](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). Профіль App Store не містить списку пристроїв: другий рядок має відповісти `Could not extract value`. Якщо він показує ідентифікатори пристроїв, це профіль ad hoc, тобто профіль внутрішнього build. Третій рядок показує дату закінчення дії профілю.

**4. Чи розширення і фреймворки підписані так само?**

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

Кожен компонент має показувати той самий рядок `Authority`, що й застосунок. Якщо якийсь відрізняється, саме його і згадує повідомлення.

Якщо хочеш перевірити до надсилання, TN3161 радить `altool`, це та сама перевірка, що й кнопка Validate App в Xcode. Їй потрібен ключ API App Store Connect, файл `AuthKey_<KEY_ID>.p8` якого кладеш у `~/.appstoreconnect/private_keys`:

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

## Виправлення з EAS, причина за причиною

### В Apple надіслали внутрішній build або build для розробки

Згідно з [документацією Expo про eas.json](https://docs.expo.dev/build/eas-json/), build з `"distribution": "internal"` не підписані для магазинів: вони використовують профіль ad hoc. Лише профіль із дистрибуцією `store`, значенням за замовчуванням, дає build, який можна надіслати. **Найнадійніше: надсилати build, який ти щойно зібрав, не вибираючи його вручну**:

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

Якщо користуєшся `eas submit --path`, перевір, що файл справді твій останній store build. На форумі Apple одна команда виявила, що її інструмент щоразу надсилав старий IPA, який лежав у git.

### Забуте розширення

Кожне розширення це окремий bundle зі своїм ідентифікатором і власним профілем. У проєкті Expo з генерацією нативного коду [сторінка Expo про розширення iOS](https://docs.expo.dev/build-reference/app-extensions/) вимагає оголошувати їх у `extra.eas.build.experimental.ios.appExtensions`. Тоді EAS CLI знає про них ще до build і створює або перевіряє їхні облікові дані. Більшість бібліотек, які додають розширення, пишуть це оголошення за тебе через свій плагін.

Solys, мій будильник із міні-іграми, містить чотири розширення: віджет і три розширення Screen Time. Усі чотири оголошені в його конфігурації, і для кожного в EAS є профіль. **Розширення, додане вручну в Xcode без такого оголошення, це ідеальний кандидат**, якщо в повідомленні шлях на `.appex`.

### Сертифікат відкликано або він прострочений

[Сторінка Apple про сертифікати](https://developer.apple.com/support/certificates/) каже чітко: ти більше не можеш надсилати build, підписаний простроченим або відкликаним сертифікатом. Build, який уже надіслано, але ще не подано на перевірку, може навіть перейти в статус Invalid Binary, якщо його сертифікат відкликали.

Код EAS CLI 24.10.0 показує, коли цей випадок лишається непоміченим:

- **Інтерактивний build з підключенням до Apple**: EAS порівнює свій сертифікат з тими, що досі чинні в Apple. Якщо його там уже немає, він показує «Current distribution certificate is no longer valid in Apple Dev Portal» і пропонує вибрати або створити інший.
- **Інтерактивний build без підключення**: EAS перевіряє лише дати і попереджає, що пропускає перевірку в Apple.
- **Неінтерактивний build у CI**: EAS показує «Distribution Certificate is not validated for non-interactive builds» і все одно підписує.

**У CI EAS не перевіряє сам сертифікат повторно: відкликання може виявитися лише під час надсилання.** Виправлення: запусти інтерактивний build з підключенням до свого акаунта Apple або скористайся `eas credentials --platform ios`, меню Build Credentials, далі «Distribution Certificate: Add a new one to your account». Профілі, що містили старий сертифікат, стають недійсними: EAS перевіряє їх під час наступного build і створює заново. Обмеження Apple на кількість сертифікатів описані в [гайді про сертифікат розробника iOS](https://devoria.fr/uk/blog/ios-developer-certificate-provisioning-profile-expo).

### Бінарник змінили після підпису

Підпис запечатує код, ресурси й метадані хешами, як пояснює [нотатка Apple TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes). Якщо розпакувати IPA, змінити файл і запакувати знову, ця печатка ламається. **Вноси зміни в конфігурацію, а потім збирай build заново.** Ніколи не правити IPA, яку створив EAS.

Та сама логіка для коду, покладеного не туди, наприклад в архів `.zip`: App Store не може його перепідписати. Дозволені місця Apple описує на сторінці про [вміст bundle](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle).

### Локальні облікові дані

Якщо твій профіль EAS використовує `"credentialsSource": "local"`, файл `credentials.json` вказує на сертифікат `.p12` і профіль `.mobileprovision`. Перевір профіль командами з кроку 3: він має бути типу App Store і містити твій поточний сертифікат дистрибуції. І тримай ці файли поза репозиторієм, як і [ключі API застосунку Expo](https://devoria.fr/uk/blog/secret-api-key-expo-app-what-to-protect).

### Коли все чинне

Лишається один неприємний випадок. На форумі Apple розробники бачать, що помилка зникає, коли вони надсилають той самий build ще раз, нічого не змінюючи. У серпні та вересні 2026 року дві гілки описують протилежне: новий сертифікат і профіль, підпис перевірено, а збій не зникає. В одній із них інженер Apple радить звіт про баг з IPA, аналізом підпису і журналами Transporter, а потім звернутися в App Store Connect.

Тож надішли ще раз із новим номером build. Якщо помилка повертається, хоча всі чотири команди чисті, повідом про неї Apple з цими матеріалами. **Не відкликай сертифікат за звичкою**: це нічого не вирішує, а профілі стануть недійсними.

## Надсилай build без неприємних сюрпризів

Підпис перевіряється за дві хвилини до надсилання. Інші автоматичні перевірки вимагають тієї ж уважності, як-от [ITMS-90725](https://devoria.fr/uk/blog/itms-90725-sdk-version-issue-expo) щодо версії Xcode або [ITMS-90683](https://devoria.fr/uk/blog/itms-90683-missing-purpose-string-expo) щодо текстів запитів дозволів. Повний шлях від build до надсилання без Mac описано в статті [як опублікувати iOS-застосунок без Mac](https://devoria.fr/uk/blog/publish-ios-app-without-mac-expo-eas).

Відмови рев'юера потребують спокійнішого підходу: порядок дій описано на сторінці [застосунок відхилила Apple](https://devoria.fr/uk/expertise/app-rejected-by-apple), а найчастіші причини зібрано в статті [чому Apple відхиляє застосунок](https://devoria.fr/uk/blog/vidmova-apple-app-store-prychyny).

Щоб перевірити все перед надсиланням, [Review Kit](https://devoria.fr/uk/kits/app-review) містить мій чеклист і skills для Claude Code, які переглядають твій проєкт. Якщо надсилання застрягло і тобі потрібен живий погляд, [забронюй годину зі мною](https://devoria.fr/uk/coaching): розберемо твій проєкт на відеодзвінку, на твоєму екрані. А якщо готуєш свій перший реліз, [пройди безкоштовну діагностику](https://devoria.fr/uk/diagnostic): вона розставить етапи по порядку і надішле тобі мій чеклист проти відмов Apple.

## Поширені запитання

### ITMS-90034 це відмова App Review?

Ні. Це автоматична перевірка під час надсилання build, до TestFlight і до будь-якої перевірки. Ніхто не відкривав твій застосунок: Apple лише виявила, що його підпис зроблено не чинним сертифікатом дистрибуції.

### Чи треба відкликати сертифікат дистрибуції, щоб виправити ITMS-90034?

Лише якщо він скомпрометований або вже недійсний. Відкликання робочого сертифіката робить твої профілі недійсними, а причину не усуває. Почни з того, що прочитай підпис своєї IPA через `codesign`, а потім виправ те, на що вказує дерево рішень.

### Чи можна виправити ITMS-90034 віддаленим оновленням?

Ні. Підпис є частиною бінарника, а відхилений build ніколи не стане придатним. Потрібно зібрати новий, правильно підписаний бінарник і надіслати його знову.

### Чому помилка згадує мій віджет, а не застосунок?

Бо віджет це окремий bundle, підписаний власним профілем. Якщо він не оголошений в EAS або підписаний інакше, через нього падає все надсилання. Оголоси розширення в конфігурації і збери build заново.

### Що робити, якщо codesign каже, що все чинне?

Перевір також вбудований профіль і кожне розширення. Якщо все чисто, надішли ще раз із новим номером build. Якщо помилка не зникає, надішли Apple звіт з IPA, виводом `codesign` і журналами надсилання.


## Твій проєкт

[Review Kit](https://devoria.fr/uk/kits/app-review): Мій чекліст для перевірки в App Store, виправлені відмови Apple, чекліст для Google Play і три скіли для Claude Code. 2 499 ₴.

[iOS & Android Kit](https://devoria.fr/uk/kits/ios): Створи свій застосунок для iPhone і Android з Claude Code: стартовий код моїх застосунків, шлях до публікації в сторах і всі кіти. 4 999 ₴.

[Діагностика: що відділяє тебе від твого застосунку для iPhone](https://devoria.fr/uk/diagnostic): 7 запитань, 60 секунд: ти дізнаєшся, що насправді заважає тобі опублікувати застосунок для iPhone, отримаєш свій шлях у 4 кроки і кіт, який тобі підходить.