ITMS-90034「Missing or invalid signature」の直し方

ITMS-90034は、ビルドをApp Store Connectに送信したときに出るエラーです。アプリ本体、またはその構成要素のどれかが、Appleの提出用証明書（つまり有効な配布証明書）で署名されていない、という意味です。直し方は、どのバンドルの署名がおかしいのか、なぜなのかを突き止めて、App Store用に署名したビルドを作り直すことです。

このガイドはエラーそのものに絞っています。証明書やプロファイルという言葉があいまいなら、先にiOS開発者証明書とプロビジョニングプロファイルを読んでください。ここでは、読むべきメッセージ、判断フロー、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に送信したりするためのものです。

メッセージに書かれたパスを読んでください。それが問題のバンドルです。 Payload/MyApp.app ならアプリ本体です。.appexで終わるパスは、ウィジェットなどの拡張機能を指します。.frameworkで終わるパスは、埋め込まれたライブラリを指します。

これはレビュアーによるリジェクトではありません。検証は送信時、またはビルドの処理中、TestFlightより前に行われます。このビルドがテスターに届くことはありません。

判断フロー：メッセージから修正まで

各行は、メッセージ、次のセクションのコマンド、またはEASのログから読み取れる手がかりに対応しています。上から順に確認し、最初に当てはまった行があなたの手がかりです。

観察されること	考えられる原因	修正
.appexで終わるパス	拡張機能の署名ミス	拡張機能を宣言する
Signature=adhoc	未署名のビルド	storeプロファイルでビルド
Apple Development	開発用ビルド	storeプロファイルでビルド
ProvisionedDevicesがある	内部ビルド（ad hoc）	storeプロファイルでビルド
sealed resource	後からIPAを変更した	ビルドし直す
EAS：「no longer valid」	証明書が失効している	新しい証明書
すべて有効	Apple側の障害	再送信し、その後報告する

4つのコマンドでIPAを調べる

expo.devのビルドページからIPAをダウンロードし、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の各行は信頼チェーンの1つの環です。最初の行はApple Distribution:かiPhone Distribution:で始まり、その後にチーム名が続くはずです。後者は旧来のiOS Distributionタイプの表記で、コードを見る限り、EAS CLI 24.10.0は今もこのタイプの証明書を作成します。Apple Development:と出たら開発用ビルドです。Authority行が1つもなくSignature=adhocと出たら、そのバイナリはどの証明書でも署名されていません。

2. 署名後にアプリが変更されていないか？

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

valid on disk、続いてsatisfies its Designated Requirementと出れば正常です。TN3161には、このチェックで何が保証されるかが書かれています。期待されるファイルがすべて揃っていること、追加されたファイルがないこと、変更されたファイルがないことです。私が署名してから手を加えたテスト用バンドルでは、コマンドはa sealed resource is missing or invalidと返し、続いてfile modified:のあとに変更したファイルを表示しました。ここでの--deepオプションは検証のためだけに使います。署名には絶対に使わないでください。Appleフォーラムでも、サポートチームのエンジニアが署名での使用を勧めていません。

3. どのプロファイルが埋め込まれているか？

security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profile.plist
plutil -extract ProvisionedDevices xml1 -o - profile.plist
plutil -extract ExpirationDate raw profile.plist

これはプロファイルに関するテクニカルノートTN3125のコマンドです。App Storeプロファイルにはデバイスのリストが含まれないので、2行目はCould not extract valueと返るはずです。デバイスの識別子が表示されたら、それは内部ビルド用のad hocプロファイルです。3行目はプロファイルの有効期限を表示します。

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を勧めています。XcodeのValidate Appボタンと同じチェックです。App Store Connect APIキーが必要で、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に送った

eas.jsonに関するExpoのドキュメントによると、"distribution": "internal"のビルドはストア用に署名されず、ad hocプロファイルを使います。送信できるビルドを作るのは、配布方法がstore（デフォルト値）のプロファイルだけです。いちばん確実なのは、手で選ばずに、今ビルドしたものをそのまま送信することです。

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

eas submit --pathを使う場合は、そのファイルが本当に最新のストア用ビルドか確認してください。Appleフォーラムでは、送信ツールがgitで管理されていた古いIPAを毎回送っていたことに気づいたチームがいました。

拡張機能の宣言漏れ

拡張機能はそれぞれ独立したバンドルで、固有の識別子と専用のプロファイルを持ちます。ネイティブコードを生成するExpoプロジェクトでは、iOS拡張機能に関するExpoのページのとおり、extra.eas.build.experimental.ios.appExtensionsに宣言する必要があります。そうすればEAS CLIがビルド前に拡張機能を把握し、その認証情報を作成または検証します。拡張機能を追加するライブラリの多くは、プラグイン経由でこの宣言を自動で書いてくれます。

ミニゲーム付き目覚ましアプリのSolysには、4つの拡張機能が入っています。ウィジェットが1つと、スクリーンタイムの拡張機能が3つです。4つともすべて設定に宣言してあり、EASはそれぞれにプロファイルを持っています。この宣言なしでXcodeから手動で追加した拡張機能は、メッセージに.appexのパスが出たときの最有力候補です。

証明書の失効・期限切れ

証明書に関するAppleのページにはっきり書かれています。期限切れまたは失効した証明書で署名したビルドは送信できません。すでに送信済みでまだ審査に出していないビルドでも、証明書が失効するとInvalid Binaryになることがあります。

EAS CLI 24.10.0のコードを見ると、このケースが見落とされる状況がわかります。

• 対話型ビルド、Appleにログイン済み：EASは自分の証明書を、Apple側でまだ有効な証明書と照合します。見つからなければ「Current distribution certificate is no longer valid in Apple Dev Portal」と表示し、別の証明書を選ぶか作るよう提案します。
• 対話型ビルド、ログインなし：EASは日付だけを確認し、Apple側での検証をスキップすると警告します。
• 非対話型ビルド（CI）：EASは「Distribution Certificate is not validated for non-interactive builds」と表示し、そのまま署名します。

CIでは、EASは証明書自体を再検証しません。失効していても、送信時まで気づかないことがあります。 直し方は、Appleアカウントにログインした状態で対話型ビルドを実行するか、eas credentials --platform iosでBuild Credentialsメニューを開き、「Distribution Certificate: Add a new one to your account」を選ぶことです。古い証明書を含んでいたプロファイルは無効になりますが、EASが次回のビルドでチェックして作り直します。証明書の数に関するAppleの上限は、iOS開発者証明書のガイドで詳しく説明しています。

署名後にバイナリを変更した

AppleのテクニカルノートTN3126が説明しているとおり、署名はコード、リソース、メタデータをハッシュで封印します。IPAを解凍してファイルを変更し、再圧縮すると、この封印が壊れます。変更は設定側で行い、ビルドし直してください。 EASが作ったIPAには絶対に手を加えないでください。

.zipアーカイブの中など、間違った場所に置かれたコードも同じ理屈です。App Storeはそれを再署名できません。許可されている配置場所は、Appleのバンドルの中身に関するページに書かれています。

ローカルの認証情報

EASプロファイルで"credentialsSource": "local"を使っている場合、credentials.jsonファイルが.p12証明書と.mobileprovisionプロファイルを指しています。手順3のコマンドでプロファイルを確認してください。App Storeタイプで、現在の配布証明書を含んでいる必要があります。また、Expoアプリの APIキーと同じように、これらのファイルはリポジトリに入れないでください。

すべて有効なのに失敗する

厄介なケースがもう1つあります。Appleフォーラムでは、何も変えずに同じビルドを再送信したらエラーが消えた、という開発者がいます。一方、2026年8月と9月には、逆の状況を書いたスレッドが2つありました。証明書もプロファイルも新しく、署名も確認済みなのに、失敗が続くというものです。そのうち1つでは、Appleのエンジニアが、IPA、署名の解析結果、Transporterのログを添えてバグ報告し、そのうえでApp Store Connectに問い合わせるよう勧めています。

なので、ビルド番号を新しくして一度だけ再送信してください。4つのコマンドの結果が問題ないのにエラーが再発したら、これらの資料を添えてAppleに報告します。反射的に証明書を失効させないでください。 それで解決することはなく、プロファイルが無効になるだけです。

トラブルなくビルドを送信するために

署名は送信前に2分で確認できます。ほかの自動チェックにも同じ丁寧さが必要です。たとえばXcodeのバージョンに関するITMS-90725や、権限の説明文に関するITMS-90683です。Macなしでビルドから送信までを行う全手順は、MacなしでiOSアプリを公開するにまとめています。

レビュアーによるリジェクトには、もう少し引いた視点が必要です。対処の進め方はAppleにリジェクトされたアプリのページに、よくある理由はAppleがアプリをリジェクトする理由にあります。

送信前に申請内容を確認するなら、Review Kitに私のチェックリストと、プロジェクトを見直すClaude Codeのスキルをまとめています。送信で行き詰まって人の目で見てほしいなら、私と1時間のセッションを予約してください。ビデオ通話で、あなたの画面を見ながら一緒にプロジェクトを確認します。初めてのリリースを準備中なら、無料診断を受けてください。やるべきステップを順番に整理し、私のApple リジェクト対策チェックリストをお送りします。

よくある質問

ITMS-90034はApp Reviewのリジェクトですか？

いいえ。ビルドの送信時、TestFlightやあらゆる審査より前に行われる自動検証です。誰もあなたのアプリを開いていません。Appleは、署名が有効な配布証明書によるものではないと確認しただけです。

ITMS-90034を直すには配布証明書を失効させる必要がありますか？

漏えいした場合や、すでに無効な場合だけです。正常に動いている証明書を失効させても、原因は直らずにプロファイルが無効になるだけです。まずcodesignでIPAの署名を読み、判断フローが示す点を直してください。

ITMS-90034はリモートアップデートで直せますか？

いいえ。署名はバイナリの一部で、拒否されたビルドが使えるようになることはありません。正しく署名した新しいバイナリを作り、送信し直す必要があります。

なぜエラーにアプリではなくウィジェットが出るのですか？

ウィジェットは独立したバンドルで、専用のプロファイルで署名されるからです。EASに宣言されていなかったり、別の方法で署名されていたりすると、送信全体が失敗します。設定で拡張機能を宣言し、ビルドし直してください。

codesignがすべて有効と言う場合はどうすればいいですか？

埋め込まれたプロファイルと各拡張機能も確認してください。すべて問題なければ、ビルド番号を新しくして一度だけ再送信します。それでもエラーが続くなら、IPA、codesignの出力、送信ログを添えてAppleに報告してください。