XcodeのInfo.plist完全ガイド｜必須キー・権限・ATS・URLスキーム設定

Info.plistは、iOSアプリの識別子・バージョン・権限・通信ポリシーなど、アプリの「振る舞い」をiOSに宣言する設定ファイルです。XcodeのInfoタブやXML編集、xcconfigなど複数の方法で管理でき、審査エラーや実機クラッシュの主要因にもなります。本稿では必須キーからATS、URLスキーム、プライバシー文言、マルチターゲット対応まで、現場で“実際に使う”観点で徹底解説します。

Info.plistとは――役割・場所・基本構造

Info.plistの役割（アプリのメタ情報・動作ポリシーを宣言）

Info.plistは、アプリの正体と許容される動作をOSに伝える宣言書です。バンドルIDや表示名、バージョンのほか、カメラ等のプライバシー権限、起動シーン、URLスキーム、通信方針などをキーと値で定義します。コードで分岐できない“前提条件”を静的に宣言するため、ビルドや審査、実行時の挙動に直結します。チーム開発では、仕様書としても機能するため、レビュー可能な形で管理することが重要です。

配置場所とターゲットごとの扱い（App/Extension/Framework）

通常は各ターゲットの「Supporting Files」配下に配置され、ターゲットごとに独立したInfo.plistを持ちます。アプリ本体、Share Extension、Widget、Frameworkなどは必要なキーが異なるため、共通化しすぎると不要な権限や設定が混入します。逆に共通化したい値はBuild Settingsの置換やxcconfigで注入し、ターゲット固有のキーは各plistで完結させると保守しやすくなります。

XML/バイナリ形式とProperty Listの基本

Property Listはキーと値の辞書で、XMLとバイナリの2形式が存在します。Git管理やレビュー性を考えるとXMLが無難ですが、サイズ効率ではバイナリに利があります。XcodeはGUI編集でもXMLにシリアライズ可能で、plutilで相互変換ができます。値型はString、Number、Boolean、Array、Dictionaryなど。型が違うとシステムが期待通りに解釈できず、クラッシュや意図しない挙動の原因になります。

Xcodeでの編集方法（4通り）

“Info”タブ（GUI）で編集する

もっとも手軽なのがターゲット設定の「Info」タブです。人間に読みやすいラベルと補完が効くため、初学者でも迷いにくいのが利点。一方で差分が見えにくく、プロジェクト設定とplistの関係が不透明になることがあります。最初はGUIで理解し、最終的にはXMLと差分を確認する運用にすると、レビューと再現性のバランスが取れます。

ソース（XML）を直接編集する

XMLを直接編集すると、レビューでの差分確認やコードレビュー文化に合致します。不要なキーの削除や並び順の統一、コメント挿入など、チームルールを適用しやすいのも利点です。ミスを防ぐため、必ずスキーマやサンプルを参照し、型を厳密に守りましょう。編集後はplutil -lintで検証するとCIでも検出できます。

Build Settingsの値展開（$(PRODUCT_*) 置換）を使う

Info.plist内の値に$(PRODUCT_BUNDLE_IDENTIFIER)等のビルド設定を展開できます。環境やターゲットで異なる値をソースに直書きせず、設定から注入することで共通化が進みます。Bundle name、バージョン文字列、APIエンドポイントの一部などに応用可能。過度な動的化は可読性を落とすため、ルールを決めて限定的に使うと効果的です。

xcconfigで環境別（Debug/Release）に分ける

xcconfigはビルド設定の宣言ファイルで、Debug/Releaseや社内/本番などの差分管理に最適です。Info.plistは変えず、MARKETING_VERSIONやPRODUCT_BUNDLE_IDENTIFIER等をxcconfigで切り替えると、衝突が減りレビューもしやすくなります。値の命名規約とファイル分割方針（Base/Envごと）を決め、ドキュメント化すると運用が安定します。

まず理解すべき必須・頻出キー

CFBundleIdentifier / DisplayName（表示名と識別子）

CFBundleIdentifierはアプリの一意な識別子で、逆ドメイン形式を推奨します。重複や変更はプロビジョニングやPush通知に影響します。表示名（Bundle name/CFBundleDisplayName）はホーム画面の表記で、ローカライズや短縮に配慮しましょう。記号や長さ制限で省略される場合があるため、実機での確認が不可欠です。

CFBundleShortVersionString / CFBundleVersion（バージョン/ビルド）

前者はユーザー向けのマーケティングバージョン、後者は内部ビルド番号です。App Store提出では単調増加が必須で、逆戻りは却下の原因になります。CIで自動採番し、人手ミスを防ぐ運用が定番です。Semantic Versioningを参考にしつつ、チームで上げ方のルールを定義しましょう。

UIApplicationSceneManifest（UIWindowScene/SwiftUIのシーン設定）

iOS 13以降はシーンベースが標準で、マルチウインドウやライフサイクル管理を司ります。SwiftUI/Appライフサイクルを使う場合も、Info.plistの定義有無が挙動に影響することがあります。最小設定で問題がなければ触らず、複数ウインドウや特定ロールが必要なときに拡張するのが安全です。

UISupportedInterfaceOrientations（回転/向き）

対応する画面向きを列挙します。iPhoneとiPadで要件が異なる場合、~ipadキーを分けて定義しましょう。ゲームや動画アプリで誤回転がUXを損なうため、要件を明確化し実機で検証します。強制縦向きでも例外画面があるなら、コード側と整合を取る必要があります。

UIRequiredDeviceCapabilities（必要デバイス機能）

カメラ、GPS、ARKitなど必須ハード・機能を宣言し、非対応端末をストア表示から除外します。宣言しないと動作不能端末に配信され、低評価の温床になります。逆に要件が緩い場合はOptional指定で裾野を広げる選択もあります。マーケと技術で配信戦略を合わせましょう。

CFBundleURLTypes（URLスキーム登録）

他アプリやWebからの起動フックに使います。スキームの衝突を避けるため、識別子にドメインを含める命名が無難です。ロールやアイコンなどの付随設定も正しく定義し、テストではUIApplication.open(_:)で往復動作を確認します。Universal Linksを併用する場合は、重複や優先順位に注意してください。

LSApplicationQueriesSchemes（canOpenURL許可）

iOSはcanOpenURLで問い合わせ可能なスキームを制限しており、事前宣言が必要です。過剰な列挙は審査で指摘されるため、実際に利用する最小集合に絞り込みます。テスト環境だけで必要なものは条件付きビルドやxcconfigで切り替えると安全です。

権限（Privacy）関連キーの書き方と落とし穴

NSCameraUsageDescription / NSPhotoLibraryUsageDescription などの共通パターン

プライバシー関連キーは用途を具体的・ユーザ利益中心で記述します。「サービス向上のため」など抽象的な表現は避け、撮影・アップロード・本人確認など目的を明示。内部名の混在や誤字はローカライズ崩れの原因です。必須キーの漏れは即クラッシュに直結するため、初回アクセス前に必ず確認しましょう。

文言のベストプラクティス（審査で通る説明文の書き方）

Appleはデータ利用の透明性を重視します。取得タイミング、用途、保存期間、第三者共有の有無を短い文で端的に伝えると通過率が上がります。アプリ内の機能名と一致する語彙を用い、サポートURLやヘルプから詳細に誘導する設計も有効です。不要時は権限を求めないUIにするのが最良です。

「This app has crashed because it attempted to access privacy-sensitive data…」の原因と対処

代表的な原因は、該当APIを呼ぶ前にUsageDescriptionが未定義なケースです。サードパーティSDKの内部アクセスでも同様に発生し得ます。該当キーを特定し、説明文を追加して再ビルドするだけで解消されます。テストでは機能単位で権限リセットし、実機で初回ダイアログの表示を確認しましょう。

App Transport Security（ATS）の正しい設定

NSAppTransportSecurityとNSAllowsArbitraryLoadsの是非

ATSは安全な通信（原則HTTPS/TLS1.2+）を強制します。NSAllowsArbitraryLoadsで一括無効化は簡便ですが、審査・セキュリティ両面で非推奨です。やむを得ない場合は開発時限定とし、配信前にドメイン例外へ段階的に移行する計画を立てましょう。

ドメイン単位の例外設定（NSExceptionDomains）の具体例

一部の外部APIや社内検証用でHTTPや古いTLSを許可する場合、対象ドメインを限定し、最小権限で例外を与えます。HSTSや証明書の状態を定期確認し、恒久化しない方針を明文化しましょう。例外は運用負債になりやすく、定例で棚卸しする仕組みが有効です。

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>api.example.com</key>
    <dict>
      <key>NSIncludesSubdomains</key><true/>
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key><true/>
    </dict>
  </dict>
</dict>

HTTPS移行時のチェックリスト

証明書の失効・中間証明書の配置・TLSバージョン・SNI対応を確認。リダイレクトやHSTS設定も重要です。アプリ側ではピニングやリトライ戦略、タイムアウトの見直しを行い、古い端末での互換性をテストします。例外を段階的に削減し、ゼロATS例外を目標にします。

URLスキーム／外部連携の実装ポイント

CFBundleURLTypesの具体例（スキーム名・ロール）

URL TypesではCFBundleURLNameやCFBundleURLSchemesを定義します。衝突を避けるため、組織名やドメインを含めた命名にします。受け取り側ではシーン/アプリデリゲートのハンドラにて解釈し、エラー時のフォールバックを設計すると堅牢です。

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLName</key><string>com.example.app</string>
    <key>CFBundleURLSchemes</key>
    <array><string>exampleapp</string></array>
  </dict>
</array>

canOpenURL制限とLSApplicationQueriesSchemesの最小化

外部アプリ起動前の存在確認はcanOpenURLで行いますが、未宣言スキームは常にfalseになります。テストで必要なスキームの洗い出しと、本番での最小化を分けて管理しましょう。過剰な列挙は審査指摘や将来の保守負担につながります。

Universal LinksとInfo.plistの関係（ざっくり比較）

Universal LinksはHTTPSのみで発火し、Webとアプリのディープリンクを統合します。Info.plist側は照合対象のドメインやハンドリングの宣言が中心で、実体はapple-app-site-associationファイルにあります。URLスキームと併用し、到達率・UX・保守性のバランスで選択しましょう。

マルチターゲット／エクステンションでの設計

ターゲット別に分離するキー／共通化するキー

Extensionは利用できるAPIや権限が限定され、不要なキーは持ち込み厳禁です。共通化したいのはバージョンやBundle関連などで、権限やATS例外は分離が原則。設計段階で「共有」「固有」をラベル付けし、レビューで崩れない仕組みを作ると実装が安定します。

Build Settingsの置換でターゲット差分を吸収する

Bundle IDや表示名、URLスキームのプレフィックスなどは置換で吸収すると、plistの分岐が減ります。逆にDictionary/Array構造を丸ごと変えたい場合は個別plistを採用。目的に応じて“値注入”と“ファイル分割”を使い分けるのがコツです。

共有xcconfigの活用と命名規約

Base.xcconfigで共通値、Env.xcconfigで環境差分、Target.xcconfigで固有差分を定義する三層構成が分かりやすい運用です。キー名やバージョンの扱い方をREADMEに明文化し、CIでlintをかけて逸脱を検出します。新人オンボーディングの教材にもなります。

具体例で学ぶInfo.plistテンプレート

最小構成のテンプレート（App）

最小限ではバンドルID、表示名、バージョン、サポート向きの定義だけでも動作します。初期段階は極力シンプルに保ち、必要に応じて権限やURL、ATSを増やすとトラブルを局所化できます。以下は学習・検証に適した最小例です。

<dict>
  <key>CFBundleIdentifier</key><string>com.example.app</string>
  <key>CFBundleDisplayName</key><string>Example</string>
  <key>CFBundleShortVersionString</key><string>1.0.0</string>
  <key>CFBundleVersion</key><string>1</string>
  <key>UISupportedInterfaceOrientations</key>
  <array><string>UIInterfaceOrientationPortrait</string></array>
</dict>

写真・カメラ・位置情報を使うアプリのテンプレート

メディア取得や位置連動機能ではUsageDescriptionの抜け漏れが最頻クラッシュ要因です。ユーザーに価値が伝わる説明文を短く具体的に書き、不要な権限は求めない方針で設計しましょう。ATSやバックグラウンド更新などの追加要件があれば合わせて定義します。

<key>NSCameraUsageDescription</key><string>プロフィール撮影のためカメラを使用します。</string>
<key>NSPhotoLibraryUsageDescription</key><string>投稿に写真を選ぶためフォトライブラリにアクセスします。</string>
<key>NSLocationWhenInUseUsageDescription</key><string>近くのスポットを表示するため位置情報を利用します。</string>

外部API連携（ATS例外/URLスキームあり）のテンプレート

レガシーAPIや認証アプリ連携がある場合、ATS例外とURL Typesを最小限で組み合わせます。例外はドメイン限定・一時的を原則とし、将来的なHTTPS移行をロードマップに入れておきましょう。スキームは衝突回避の命名と、フォールバック導線の設計が鍵です。

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>legacy.example.com</key>
    <dict>
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key><true/>
    </dict>
  </dict>
</dict>
<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLName</key><string>com.example.app</string>
    <key>CFBundleURLSchemes</key><array><string>exampleapp</string></array>
  </dict>
</array>

よくあるビルド/審査エラーとデバッグ手順

Missing Info.plist value / Invalid Bundle Identifier

値の未設定や型不一致、Bundle IDの重複は即ビルド/提出エラーになります。まずXcodeのレポートとplutil -lintで構文検証し、CIで自動チェックを導入しましょう。Bundle IDはプロビジョニングと一致させ、ターゲットやスキームの取り違えを防ぐ命名にします。

プライバシー文言不足によるクラッシュ/却下

権限アクセス前に説明文が無いとクラッシュし、審査でも高確率で却下されます。SDK経由のアクセスにも注意が必要です。テストでは権限をリセットして初回ダイアログを毎回確認し、不要なキーは削除します。文言はユーザー利益が伝わる具体表現に統一しましょう。

canOpenURL失敗・ATSブロックの切り分け

外部連携が失敗する場合、まずはLSApplicationQueriesSchemes宣言漏れとATSブロックを疑います。URLスキームのスペル、Universal LinksのAASA配信、ドメイン例外の有無を段階的に確認。ネットワークモニタとコンソールログ、実機テストの組み合わせで原因を特定します。

Info.plistと周辺ファイルの関係を整理

entitlements（権限付与）との違い

entitlementsはiCloudやPushなどOS機能の“付与”を署名レベルで宣言するもの、Info.plistはアプリの“性質や前提”をシステムに知らせるものです。両者は相補的で、片方だけでは機能しないケースもあります。設計時に役割を分離して管理しましょう。

Privacy Manifest（PrivacyInfo.xcprivacy）との役割分担

Privacy ManifestはSDKやアプリが収集するデータ種別・用途を宣言する新しい仕組みです。Info.plistのUsageDescriptionはユーザーへの対話、Manifestは開発者間と審査向けの透明性確保と捉えると整理しやすいです。両者の記載が矛盾しないよう、更新時はセットで見直します。

LaunchScreen / Assets / Capabilitiesとの境界

起動画面（LaunchScreen）やアイコンはAssetsで管理し、Info.plistは参照やメタ情報の宣言が中心です。Capabilitiesはサンドボックス権限を付与し、必要に応じて関連キーがplistに追加されます。配置場所と責務を分けることで設定の衝突を防げます。

変更管理・レビューしやすい運用術

キー命名・並び順・コメントのルール

キーの並び順を「識別子→バージョン→UI→通信→権限→外部連携」のように固定し、辞書や配列も一貫した順序で記述するとレビュー効率が上がります。変更理由はコメントで残し、PRテンプレートに“plist変更欄”を設けて経緯を可視化しましょう。

環境差分の見える化（xcconfig + スクリプト）

環境ごとに異なる値はxcconfigに集約し、agvtoolやスクリプトでマーケ版・ビルド番号を自動更新します。plistbuddyで差分抽出、plutilでフォーマット統一を行うと、差分レビューが安定します。リリース手順書にも組み込みましょう。

CIでのLint/検証（plistbuddy/plutilの活用）

CIで構文チェック、必須キー有無、値の妥当性を自動検証するとヒューマンエラーを早期に潰せます。テンプレートからの逸脱やATS例外の増加を検知してアラートする仕組みも効果的です。成果物のIPAから展開したplistを最終検証するのも有用です。

まとめ（チェックリスト付き）

リリース前の最終チェック項目

Bundle ID/表示名/バージョンの整合、プライバシー文言の漏れ、ATS例外の最小化、URLスキームとUniversal Linksの到達性、対応向きの実機確認、entitlementsとの矛盾、環境差分の意図通りの注入、CIでのlint通過をチェックしましょう。最後に実機で初回起動体験を確認します。

参考リンクと社内テンプレートへの落とし込み

Apple公式ドキュメントと社内ベストプラクティスを突き合わせ、用途別テンプレートを整備しましょう。新規プロジェクトはテンプレから開始し、変更点だけPRで議論できる体制を作ると学習コストを抑えられます。定期的な棚卸しで負債化を防ぐのが長期的な成功の鍵です。