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

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

Цей гайд присвячений лише цій помилці. Якщо слова «сертифікат» і «профіль» тобі поки незрозумілі, спершу прочитай про сертифікат розробника iOS і provisioning profile. Тут ти знайдеш, як читати повідомлення, дерево рішень, команди для перевірки 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 про сертифікати пише прямо: сертифікати розробки потрібні, щоб запускати застосунок на твоїх пристроях, а сертифікати дистрибуції потрібні, щоб його поширювати або надсилати в 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. Хто підписав застосунок?

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, кожен рядок Authority це ланка ланцюжка довіри. Перший має починатися з Apple Distribution: або iPhone Distribution:, а далі йде назва твоєї команди. Другий варіант належить старому типу iOS Distribution: судячи з коду, EAS CLI 24.10.0 досі створює сертифікати цього типу. Якщо бачиш Apple Development:, це build для розробки. Якщо бачиш Signature=adhoc без жодного рядка Authority, бінарник не підписаний жодним сертифікатом.

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

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. Який профіль вбудовано?

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 про профілі. Профіль App Store не містить списку пристроїв: другий рядок має відповісти Could not extract value. Якщо він показує ідентифікатори пристроїв, це профіль ad hoc, тобто профіль внутрішнього build. Третій рядок показує дату закінчення дії профілю.

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

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:

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

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

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

Згідно з документацією Expo про eas.json, build з "distribution": "internal" не підписані для магазинів: вони використовують профіль ad hoc. Лише профіль із дистрибуцією store, значенням за замовчуванням, дає build, який можна надіслати. Найнадійніше: надсилати build, який ти щойно зібрав, не вибираючи його вручну:

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

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

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

Кожне розширення це окремий bundle зі своїм ідентифікатором і власним профілем. У проєкті Expo з генерацією нативного коду сторінка Expo про розширення iOS вимагає оголошувати їх у extra.eas.build.experimental.ios.appExtensions. Тоді EAS CLI знає про них ще до build і створює або перевіряє їхні облікові дані. Більшість бібліотек, які додають розширення, пишуть це оголошення за тебе через свій плагін.

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

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

Сторінка Apple про сертифікати каже чітко: ти більше не можеш надсилати 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.

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

Підпис запечатує код, ресурси й метадані хешами, як пояснює нотатка Apple TN3126. Якщо розпакувати IPA, змінити файл і запакувати знову, ця печатка ламається. Вноси зміни в конфігурацію, а потім збирай build заново. Ніколи не правити IPA, яку створив EAS.

Та сама логіка для коду, покладеного не туди, наприклад в архів .zip: App Store не може його перепідписати. Дозволені місця Apple описує на сторінці про вміст bundle.

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

Якщо твій профіль EAS використовує "credentialsSource": "local", файл credentials.json вказує на сертифікат .p12 і профіль .mobileprovision. Перевір профіль командами з кроку 3: він має бути типу App Store і містити твій поточний сертифікат дистрибуції. І тримай ці файли поза репозиторієм, як і ключі API застосунку Expo.

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

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

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

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

Підпис перевіряється за дві хвилини до надсилання. Інші автоматичні перевірки вимагають тієї ж уважності, як-от ITMS-90725 щодо версії Xcode або ITMS-90683 щодо текстів запитів дозволів. Повний шлях від build до надсилання без Mac описано в статті як опублікувати iOS-застосунок без Mac.

Відмови рев'юера потребують спокійнішого підходу: порядок дій описано на сторінці застосунок відхилила Apple, а найчастіші причини зібрано в статті чому Apple відхиляє застосунок.

Щоб перевірити все перед надсиланням, Review Kit містить мій чеклист і skills для Claude Code, які переглядають твій проєкт. Якщо надсилання застрягло і тобі потрібен живий погляд, забронюй годину зі мною: розберемо твій проєкт на відеодзвінку, на твоєму екрані. А якщо готуєш свій перший реліз, пройди безкоштовну діагностику: вона розставить етапи по порядку і надішле тобі мій чеклист проти відмов Apple.

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

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

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

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

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

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

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

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

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

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

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