Xcode 27 PrivacyInfo.xcprivacy が Archive に入らない？2026年の切り分け

Xcode 27 PrivacyInfo.xcprivacy が Archive に入らない？2026年の切り分け

📋 目次

ArchiveにPrivacyInfo.xcprivacyが見当たらず、提出前の検証で止まる。 最終の.xcarchiveを先に調べ、アプリ本体と依存パッケージを確認してから、target設定、Swift Packageのリソース宣言、SDKの同梱状況へ戻ってください。ファイルがあっても内容の有効性は別途確認が必要です。

対象読者：ローカルでは通るのにArchiveで自分のプライバシーマニフェストが見つからないiOS開発者。 対象読者：Swift PackageやバイナリSDKの同梱状況を確かめたいモバイルCI担当者。 対象読者：リモートMac CIの差分を再現し、記録に残せる検証手順を整えたいDevOps担当者。

最終更新：2026年10月5日。Xcodeの現行情報と、Appleのプライバシーマニフェスト、無効なマニフェストの調査手順、第三者SDK要件を照合しています（プライバシーマニフェストの追加手順、TN3181、第三者SDKの要件）。

ソースにある状態とArchiveに入った状態は別です

2026年10月5日時点のAppleの説明では、プライバシーマニフェストはアプリや第三者SDKのプライバシー関連の扱いを記述するファイルです。すべてのアプリに同じ内容を一律で記載すればよい、というものではありません。まずはAppleの追加手順と、該当するSDKがある場合は現在の第三者SDK要件を基準にします。

Xcodeのナビゲーターに見えているのに、Archiveでは見つからないのはなぜですか？

プロジェクト内にファイルが存在することと、Archive対象のアプリへリソースとしてコピーされることは別です。targetへの所属、ビルド設定、成果物に含まれるbundleの構成のどこで途切れたかを、完成したアーカイブから逆に確認します。

まず、問題が起きたビルドと同じScheme、構成、依存解決結果で作られた.xcarchiveを指定します。以下はパスを環境変数に設定して、成果物内のファイルを探す例です。

ARCHIVE="/path/to/<App>.xcarchive"

find "$ARCHIVE/Products/Applications" \
  -name "PrivacyInfo.xcprivacy" -print

見つからない場合は、次の比較で調査対象を絞ります。

  • アプリ自身の清単がない：アプリtargetにファイルが所属しているか、Archiveで使う構成のリソース設定に含まれるかを確認します。
  • Swift Packageのリソースbundleにもない：Package.swiftのリソース宣言と、依存パッケージのビルド成果物を調べます。
  • SDKのframeworkやbundleにない：SDKの配布物にマニフェストが含まれるか、アプリへの組み込み時にbundle構造が保たれているかを確認します。
  • ファイルはあるが検証で拒否される：配置ではなく、plist形式や宣言内容の妥当性を確認します。

パスはアプリ、frameworkなどのbundle種別によって異なります。Appleのbundleへのコンテンツ配置の説明を参照し、ひとつの製品種別のパスを他の成果物に当てはめないでください。

Archive内で見つけたファイルを直接書き換えて解決しようとしないでください。署名済み成果物を変更すると署名との整合性に影響します。修正はプロジェクト、パッケージ、またはSDKの構成元に戻してから再アーカイブします。

アプリ、Swift Package、SDKで確認場所を分けます

アプリtargetでは「所属」と「コピー」を確認します

アプリ用マニフェストがソースツリーにあっても、Archiveを作るtargetに所属していなければ、最終アプリのbundleには入りません。Xcodeのファイル参照だけでなく、対象targetとビルド構成を開き、Archiveに使ったSchemeでそのリソースが処理されるか確認してください。

同じファイルがDebugでは見えても、Archiveに使う構成では別targetや別設定が選ばれている場合があります。問題の再現ではSchemeを固定し、ローカルとCIの双方で同じコミットと構成を使います。これにより、プロジェクト設定の差か、実行環境の差かを分けやすくなります。

Swift PackageではSources内の配置だけで判断しません

Swift Packageの清単を最終アプリに含めるには、何を確認しますか？

パッケージのディレクトリにPrivacyInfo.xcprivacyがあるだけでは、リソースとしてビルドされる証拠になりません。Package.swiftで対象targetのresourcesに宣言されているかを確認し、パッケージ側の生成物とArchive内のリソースbundleを順に調べます。宣言方法やリソース処理の詳細は、AppleのSwift Packageリソースガイドに沿って確認してください。

ここでは、欠落箇所を次のように判別します。

  • パッケージの成果物にファイルがない場合は、パッケージ側の配置やresources宣言を見直します。
  • パッケージの生成物にはあるが、最終アプリの構成で見つからない場合は、依存関係の解決結果とアプリへの組み込みを追います。
  • アプリ本体のマニフェストだけが見つからない場合は、パッケージではなくアプリtargetの設定を優先して確認します。

この切り分けなら、「Swift Packageのリソースが入らない」問題と、アプリ自身のtarget設定の問題を混同しません。

第三者SDKではSDK側と統合側を分けます

SDKについては、まず提供元の配布物にプライバシーマニフェストが含まれているかを確認します。次に、バイナリframeworkなどSDKのbundle内にファイルがあるか、Archive後にもその構造が保たれているかを確認してください。必要なSDKや要件は変わり得るため、Appleの第三者SDK要件の案内を基準に照合します。

SDK由来のコードの扱いを、アプリ本体のマニフェストで代用して申告しないでください。SDKの実装とマニフェストは提供元に確認し、アプリ側では正しい版を依存に含めたか、Archive時に成果物から欠落していないかを確認します。

リモートMac CIで作ったArchiveにSDKのマニフェストがあるか、どう確認しますか？

CIログに依存解決の結果とArchiveの出力先を残し、成果物を取得して同じfindコマンドを実行します。ローカルとCIでファイルの有無が異なる場合は、コミット、Xcodeの選択状況、ビルド構成、依存パッケージの解決結果、SDKの配布物を順に比較します。単にXcodeのプロジェクト画面にファイルが表示されるかどうかでは判定できません。

形式エラーと宣言内容の不一致は別に直します

ファイルの存在を確認した後に検証します

ファイルが入っているのに提出時の検証エラーが残る場合、次に何を見ますか？

まず、エラーが「ファイルがない」「plistを読み取れない」「宣言の値が無効」「必須理由APIの説明が合わない」のどれに当たるかを分けます。Archiveから対象ファイルを取り出して、plistとして読み取れるかを確認するには、次のように実行できます。

plutil -lint "/path/to/PrivacyInfo.xcprivacy"

これは形式の確認であり、宣言内容が実際のアプリやSDKの動作と一致することまでは証明しません。データの利用や必須理由APIに関する記述は、データ利用の説明、必須理由APIの記載方法、無効なマニフェストの調査手順と、実際の実装を突き合わせます。

清単にNSPrivacyAccessedAPITypesなどのキーが記載されていても、それだけで申告が適切とは限りません。ファイルの構文、認められるキーと値、利用するAPIに対応した理由の整合性をそれぞれ確認してください。修正後はソースから再ビルドし、Archiveの再検査と提出前の検証結果まで記録します。

再現時は環境差を証跡に残します

次の手順で、ローカルとリモートMac CIを同じ条件にそろえます。

  1. 調査対象のコミットとArchiveに使うSchemeを固定します。
  2. CIとローカルで選択中のXcode、ビルド構成、依存解決結果を記録します。Xcode 27の背景情報は公式ページで確認し、ツールチェーンの表示だけからプライバシー要件の変更を推測しないでください。
  3. 同じ条件でArchiveを作成し、出力した.xcarchiveの場所を記録します。
  4. アプリと依存SDKのbundleを検索し、ファイルがあるパスと見つからなかった対象を記録します。
  5. 見つかったマニフェストを検査し、提出時のエラーがあれば文面と該当SDK・targetを関連づけます。
  6. 修正後に同じ条件で再Archiveし、変更前後のログと確認結果を保存します。

この手順で、作業環境の違いとtarget・リソース設定の問題を分離できます。遠隔Mac CIの構成そのものを見直す場合は、物理Macと仮想macOS環境の違いも判断材料になります。

条件別に次の調査先を選びます

  • Archive内にアプリ本体のマニフェストがないなら、アプリtargetの所属とArchive構成のリソース設定を確認します。
  • Package内の生成物にもマニフェストがないなら、Swift Packageのresources宣言とパッケージの成果物へ戻ります。
  • SDKのbundleだけにないなら、SDKの配布物と提供元の要件情報を確認します。
  • Archive内にファイルがあり、検証だけ失敗するなら、配置調査を止め、plist形式・キーと値・API理由の整合性を調べます。
  • ローカルとCIで結果が違うなら、同じコミット、Scheme、Xcode、依存解決結果で再Archiveします。条件が一致しない状態で設定変更を重ねると、原因を特定しにくくなります。

確認の評価は、Archive内の該当bundleを特定できたら「配置確認済み」、形式と宣言内容を公式資料および実装に照らして確認できたら「内容確認済み」と分けて記録してください。ファイルが見つかったことだけで検証全体を完了扱いにしないのがポイントです。

CIノードの再現性とマニフェスト検証を分けます

手元のMacだけでArchiveを作る運用では、使用中のXcodeや依存関係の状態がCIと揃わず、差分の再現に手間がかかることがあります。一方、リモートMac CIに切り替えても、清単の記述が正しいか、SDKが適切に申告しているかまでは自動的に保証されません。ノードの再現性を確保する作業と、Archive内のマニフェストを検証する作業は別々に維持してください。

一時的な検証環境や、ローカルとCIのArchive差分を調べるためのmacOSノードが必要なら、MacDateのMacレンタル料金案内を確認し、期間や運用条件を比較できます。常時稼働の負荷が安定していて物理環境を長期占有したい場合は自前のMacが合うこともありますが、短期の再現検証では購入コスト、保守、利用後の遊休が課題になります。ローカル実機だけで続ける場合も、CIとの差分を再現しづらいことや、ビルド中に開発用マシンを占有する点を考慮してください。MacDateのリモートMacを使う場合も、最終判断はArchiveの実物と検証結果で行います。