はじめに
こんにちは、ヤプリでiOSエンジニアをしている菅（@Nao_RandD）です。
みなさん、新しいプライバシー要件への対応は順調でしょうか？ 👀
「プライバシーマニフェスト」1とか、「SDKの署名」でお馴染みのアレですね。
2024年5月1日からApp Storeへの提出にプライバシー要件のアップデートが適用されています。
つまり、記事を書いている現時点（2024年6月）で、必要な対応がされていない場合にはストア申請でリジェクトされる可能性があります。
本記事から複数の記事に渡って、ヤプリで新しいプライバシー要件に対応した内容をご紹介させていただこうかと思います。
第１弾の本記事では、時系列順で何があったのかと、対応時のわかりにくさを攻略する自分なりの整理をご紹介します。
次に実際に対応するに当たって、全体像把握と必要な対応を整理していきます。
そして、最後の記事でノーコードアプリプラットフォームとして、基盤に適用した内容と実際の運用を紹介していきます。
以下の方を対象読者として、記事を書いていこうと思います。
- 新しいプライバシー要件はどんな時系列のものだったか把握したい
- 新しいプライバシー要件には対応したけど用語の整理がついていない
何が発表されたのか？時系列で把握しよう！💪
まずは、時系列にそって整理していきましょう。
2023年6月：「プライバシー要件のアップデート」発表
WWDC 23で以下の二つが発表され、Appleから新しくユーザーのプライバシーや開発者の信頼性を担保する仕組みとして、「プライバシーマニフェスト」と「SDKの署名」に関するセッションがありました。
- プライバシーマニフェスト：「Get started with privacy manifests」
- SDKの署名：「Verify app dependencies with digital signatures」
Apple公式のニュースでも発表され、近日に追加情報が公開されることも明らかになりました。
（以下原文）
年内には、次のような追加情報を公開する予定です。
・プライバシーに影響を及ぼすSDK（ユーザーのプライバシーに特に大きな影響を与えるサードパーティ製SDK）のリスト
・認められる理由を宣言する必要がある「理由が求められる」APIのリスト
・対象のAPIを呼び出す新しい理由を提案するための、デベロッパ向けフィードバックフォーム
・署名とプライバシーマニフェストのメリットや詳細、およびこれらが必須となる時期に関する追加文書
💭 当時の感想：
サードパーティSDKはそれぞれの開発者で対応してもらう必要があることと、アプリで対象のAPI（UserDefaults, FileStamp, etc)を利用する場合にはプライバシーマニフェストをプロジェクトに追加する必要があるとありました。
そのため、ほとんどのiOSアプリ開発者にとって影響のある内容であるとして関心が高まっていました。
（+α）2023年9月：iOSDC Japan 2023
同じくヤプリでiOSエンジニアのkamimi（kamimi_01）がiOSDC Japan 2023で、「基礎から理解する！来年春までに対応すべきプライバシーの変更点」というセッションで発表しています。
合わせて投稿されている記事では、新しいプライバシー要件についてしっかり整理されており、自身も対応へのアサインが決まってからキャッチアップに重宝していました✨
【WWDC23】2024年春以降に Apple 審査を通過するために対応すべきプライバシーの変更点
その年のiOSDCはオフラインで参加していましたが、セッション会場も賑わっており当時にそれだけ多くの開発者が関心を向けていたことがわかります。
2023年12月：「適用されるサードパーティSDKに関する要件」の発表
少し空いた12月に、対象のサードパーティSDKが公開され、メジャーなSDKのほとんどが対象であると発表されました。
FirebaseやRxSwift, Alamofireなど有名どころのiOSライブラリのほとんどがリストに記載されており、各SDKでの対応がどのように進められるかが注目されました。
💭 当時の感想：
近日中とはいつなのか。。。という気持ちは晴れず、2024年春頃という情報を元に4月までにある程度の方針を決める必要があるな、と思っていました😨
2024年2月：「プライバシー要件のアップデートが適用される時期」の発表
2024年5月1日以降、AppleはApp Storeへの提出におけるプライバシー要件をアップデートすると、2024年2月にAppleから公式のニュースとして発表がありました。
3月13日以降：承認される理由が必要なAPIを使用している新規アプリまたは既存アプリのアップデートをApp Store Connectにアップロードする際に、アプリのプライバシーマニフェストに理由が含まれていない場合は、その旨をEメールでお知らせします。これは、App Store Connectの既存の通知に追加されます。
5月1日以降：App Store Connectに新規アプリまたはアップデートされたアプリをアップロードする際に、アプリのコードが使用されるリストされたAPIの場合、承認された理由を含めることが義務付けられます。APIの使用が認められる理由によるものでない場合は、（該当APIを使用する以外の）代替方法を見つけてください。また、一般的に使用されているサードパーティSDKのリストに含まれている新しいサードパーティSDKを追加した場合は、これらのAPI、プライバシーマニフェスト、署名の要件がそのSDKに適用されます。必ず、プライバシーマニフェストが含まれているバージョンのSDKを使用してください。SDKがバイナリ依存として追加される場合は、署名も必須になるため注意してください。
この発表によって、4月内には必要な対応をリリース状態として5月1日に備える方針で、具体的なスケジュールの社内合意を得ることができました。
3月1日以降ではApp Store ConnectにIPAをアップロードした後に、ストア審査提出 or テスト審査提出（主にこちらを活用した）することで、Required Reason APIで不足している情報があれば警告メールが届くようになりました。
💭 当時の感想：
警告メールが届く対象がRequired Reason APIのみで、Privacy Nutrition LabelsやTracking Domainは警告対象でなかったことから、5月1日以降に適用される項目がプライバシーマニフェストの項目全てではないのかな、と一つの判断軸もできました。
ただ最悪のパターンを想定すると5月1日から多くのアプリがリジェクトになるリスクがあるため、ヤプリではプライバシーマニフェストで他の項目も含めて4月中に対応完了できるようなスケジュールで進めていました。
新しいプライバシー要件の整理
新しいプライバシー要件の内容を整理していきましょう！
要件の大枠から「プライバシーマニフェスト」と「コード署名」が、それぞれアプリ本体とサードパーティSDKで対応が必要かに分けられます。
アプリ開発者を対象という記事の前提もありますので、アプリ開発目線でアプリ本体とサードパーティSDKにそれぞれ必要な対応を整理します。
| 対象 | プライバシーマニフェスト | コード署名 |
|---|---|---|
| アプリ本体 | ⭕️ | 🔺 |
| サードパーティSDK | ⭕️ | ⭕️ |
アプリ本体でコード署名が🔺になっているのは？
アプリ本体でコード署名🔺としているのは、XCFrameworkとして自前のライブラリや実装が切り分けられている場合には、コード署名の対応があることが望ましいと考えたためです。
プロジェクトに追加したXCFrameworkが署名がされたものかどうかは、Xcode 15以降で対象のフレームワークを選択すると確認することができます。
異なる署名や署名がない状態で変更された場合にはビルドエラーになり、一度プロジェクトから削除して再度取り込む必要があります。
Verifying the origin of your XCFrameworks | Apple Developer Documentation
アプリ本体に対してはプライバシーマニフェストが必要2で、導入しているサードパーティSDKに対してはそれに加えてコード署名が必要になります。
次に、プライバシーマニフェストの中身の要素に関してです。
プライバシーマニフェストのわかりづらさを攻略する
時系列からどういった動きがあったのか把握したので、ここからはプライバシーマニフェストに対応する際にわかりづらさを生む要因を整理していきます。
なぜわかりづらいのか？
アプリ本体での対応としてはメインと言えるプライバシーマニフェストですが、よし取り掛かろうと思って情報収集するときに、出てくる名称を関連づけるのに苦戦します。
現状、プライバシーマニフェストはたった4つの項目だけを理解していれば、どの部分が対応として必要なのかを把握することができます。
ただ、情報を調べる切り口によって名称の違いがあり、名称の関連付けに時間がかかることが、理解を難しくする要因かと思っています。
プライバシーマニフェストを理解するには、以下の4つの項目をしっかり把握する必要があります。
（ここでの項目名はXcodeでプライバシーマニフェストをProperty List表示した時の名称として提示します）
- Privacy Tracking Enabled
- Privacy Tracking Domains
- Privacy Accessed API Types
- Privacy Nutrition Label Types
Appleの公式ドキュメントがあり、詳細は以下のリンクからも確認することができます。
Privacy manifest files | Apple Developer Documentation
名称の違いが生まれるパターンは以下です。
- 以前からあるものとプライバシーマニフェストの名称の違い
- ドキュメントとプライバシーマニフェストの名称の違い
- プライバシーマニフェストのキー名で表現した時の名称の違い
それぞれ具体的に説明していきます。
以前からあるものとプライバシーマニフェストの名称の違い
プライバシーマニフェストの項目になっている中で、以前から馴染みあるもので中身がほぼ同じでありながら、名称が異なるものがあります。
それは、「Privacy Nutrition Label Types」で、これはApp Privacyとして記載する情報と同じです。
App PrivacyはApp Storeでアプリ詳細を見たときに記載されている情報で、アプリがどういったデータをどのような用途で利用するかをユーザーに提示する仕組みです。
App Privacy Details - App Store - Apple Developer
アプリ開発者であれば、位置情報や連絡先などApp Store Connectでポチポチ入れているやつですね。
Privacy Nutrition Label Typesにある内容はApp Privacyに記載してある情報とイコールである必要3があります。
そのため、項目もApp PrivacyとプライバシーマニフェストのPrivacy Nutrition Label Typesは1対1で対応しています。
ドキュメントとプライバシーマニフェストの名称の違い
パッとRequired Reason APIと聞いてPrivacy Accessed API Typesのことだな、とピンときづらいですよね 🧐（少なくとも僕はそうでした）
Apple公式ニュースなどではRequired Reason APIと表現されますし、後述するプライバシーマニフェストのドキュメントで読む際には、キー名であるNSPrivacyAccessedAPITypesとして、それぞれ対応している内容だと認識しないとどの話のことか途端に掴みづらくなります。
先ほどあった「Privacy Nutrition Label Types」もプライバシーマニフェストのドキュメントのタイトルでは、「Describing data use in privacy manifests」と表現されていたり対応をしっかり把握していないと、何を指した情報なのかの理解が困難です。
Describing data use in privacy manifests | Apple Developer Documentation
プライバシーマニフェストをキー値で表現した時の名称の違い
プライバシーマニフェストのドキュメントを見るとわかりますが、それぞれの要素にキー値が割り当てられており、こちらもそれぞれと対応するものがパッとわかりづらかったりします。
Privacy manifest files | Apple Developer Documentation
対応は以下の通りです。
| 項目 | キー名 |
|---|---|
| Privacy Tracking Enabled | NSPrivacyTracking |
| Privacy Tracking Domains | NSPrivacyTrackingDomains |
| Privacy Accessed API Types | NSPrivacyAccessedAPITypes |
| Privacy Nutrition Label Types | NSPrivacyCollectedDataTypes |
Privacy Tracking Enabled・Domains, Privacy Accessed API Typesはそのままで特に覚える必要はないのですが、 Privacy Nutrition Label Types ⇒ NSPrivacyCollectedDataTypes はピンときづらく個人的に感じました。
そこで、対応表を作ってチートシートとして確認しやすくしていました。
表にして攻略する
つらつらと、関連付けの難しさをお伝えしたところで、自身がチートシートとして利用していたものを紹介します。
項目に対するキー名はもちろん、ドキュメントなどで関連するフレーズが整理しやすいように作成したものです。
| 項目 | キー名 | 関連用語 |
|---|---|---|
| Privacy Tracking Enabled | NSPrivacyTracking | *特になし |
| Privacy Tracking Domains | NSPrivacyTrackingDomains | *特になし |
| Privacy Accessed API Types | NSPrivacyAccessedAPITypes | ・Required Reason API ・UserDefaults ・該当するAPIを使用する場合に承認される理由（公式ニュースでの和訳） |
| Privacy Nutrition Label Types | NSPrivacyCollectedDataTypes | ・Collected Data Type ・App Privacy ・Describing data use |
＊特に混乱するという前提はなく、強いて言えばATTフレームワークが共通して関連用語になるかと思います。
まとめ
今回はAppleの新しいプライバシー要件に関して、時系列に沿った動きと対応時に自身がわかりづらいと感じた要因を整理しました。
対応された方は改めて整理することに、これから対応する可能性がある方には用語の整理にお役立て頂ければと思います。
次回には具体的に必要な対応を整理してタスクを洗い出していきます。
注：この記事は個人の解釈も含まれております。可能な限り公式情報を参考に執筆しておりますが、記事内容に起因するトラブルなどの補償はしかねますのでご了承ください。
- Privacy manifestファイル や、Privacy manifest という表現をされる場合もありますが、本記事ではプライバシーマニフェストとして統一しています。同じものを指しておりますので、その認識で読み進めていただければと思います 🤲↩
- 2024年5月時点では、Required Reason APIに該当するAPIの利用がなければ、ストア審査でリジェクトされる可能性は低いです。ただ、UserDefaultsやFirestampなど大抵のアプリで利用されると考えられるAPIが対象のため、⭕️としています。また、利用している外部SDKでプライバシーマニフェストの対応がされていない場合には、本体のプロジェクトで代わりにRequired Reason APIを定義する必要があるため、ほとんどのケースで対応が必要になるかと思います。↩
- 2024年5月時点ではApp Store Connectに入力する情報と、プライバシーマニフェストにあるPrivacy Nutrition Label Typesの情報が、厳密に同じでないとリジェクトになるという事象はヤプリでは確認されていません。また、プライバシーマニフェストに定義したからといって、App Store ConnectにApp Privacyが自動で反映されるということもありません。↩
