はじめに
こんにちは、ヤプリでiOSエンジニアをしている菅（@Nao_RandD）です。
前回に続いて、Appleのプライバシー要件アップデートに関する記事第２弾です！
第１弾ではプライバシー要件のアップデートを時系列に沿って整理しながら、プライバシーマニフェスト1のわかりにくさを解消する対応表を紹介させていただきました。
ご興味ある方は以下のリンクから、ご一読いただけると嬉しいです。
プライバシー要件のアップデートがどういったものかと、現状どういったステータスかサクッと確認したい方向けに、折りたたみコンテンツとして記載しておきます💁
プライバシー要件のアップデートとは？
「プライバシーマニフェスト」とか、「SDKの署名」でお馴染みのアレです
それぞれは以下のWWDCのセッションとドキュメントから🙏
WWDC 23のセッション - プライバシーマニフェスト：「Get started with privacy manifests」 - SDKの署名：「Verify app dependencies with digital signatures」
2024年5月1日からApp Storeへの提出にプライバシー要件のアップデートが適用されています
つまり、記事を書いている現時点（2024年6月）で、必要な対応がされていない場合にはストア申請でリジェクトされる可能性があります
第２弾となる今回では実際にヤプリで対応した時の内容を大公開します🎉
以下の方を対象読者として、記事を書いていこうと思います
- 新しいプライバシー要件で具体的に取り組むべき内容を把握したい
- 新しいプライバシー要件には対応したけど、他社でどのように対応したかも知りたい
必要な対応の確認
全体の構成としては、「サードパーティSDKへの対応」「本体（アプリプラットフォーム）への対応」という二つの大枠に分かれ、それぞれで取り組むに当たっての調査と実際のタスクを紹介するというものです。
「サードパーティSDKへの対応」に関しては、ヤプリが導入しているSDKがあるため、外部ベンダーに問い合わせたり、OSSであればIssueなど方針を把握していったという内容です。
「本体（アプリプラットフォーム）への対応」に関しては、本体プロジェクトにプライバシーマニフェストを追加するにあたって調査したことと、Appleが提示するプラクティスに合わせて対応した内容を紹介していきます。
サードパーティSDKへの対応
「近日中に適用されるサードパーティSDKに関する要件」のリストに含まれるサードパーティSDKと、ヤプリが外部ベンダーと連携して機能提供しているその他SDKでそれぞれに対応する必要があります。
リストにあるサードパーティSDK
Appleからのリストは以下のリンクから確認できます。
それぞれ対象のサードパーティSDKのリポジトリにあるIssueやリリースノートから、すでに対応されているかや、今後の方針を把握していく流れになります。
Firebase
FirebaseAuthのユーザー認証や、FirebaseAnalyticsでのデータ収集に利用しています。
FirebaseAnalyticsはリストには含まれていませんでしたが、FirebaseCoreの指定があるのでFirebaseを利用している場合には対応が必要と判断しました。
firebase-ios-sdkのIssuesを毎日チェックしながら、対応バージョンのリリースタイミングを把握していきました。
2024年2月辺りで、日程や対応バージョンがわかってきたため、合わせてバージョンアップができるよう社内各所で調整していきました。
We weren't able to complete the privacy manifests in time for 10.21.0 and are hopeful we can release in 10.22.0, due out the week of February 26th.
Lottie
アニメーションアイコンに利用しています。
Lottieは4.4.0のタイミングでプライバシーマニフェストが追加されています。
その後も、パッチバージョンをあげてプライバシーマニフェストにも更新が入っていたため、5月1日までにヤプリでリリースが行える範囲内で最新だった4.4.2へのバージョンアップで対応しています。
GoogleMLKit/TextRecognition
OCR機能のために利用しています。
「近日中に適用されるサードパーティSDKに関する要件」にはGoogleMLKitがないのですが、内部でGTMSessionFetcher, GoogleUtilities, GoogleToolboxForMac, GoogleDataTransportに依存があったため対応が必要になると判断しました。
(補足) ML Kit を使用して画像内のテキストを認識する（iOS）で紹介されているサンプルコードになりますが、CocoaPodsでインストールするとFramework Search Pathに対象のSDKが追加されていることがわかります。
ただ、GoogleMLKitはメンテナンスがしばらくされておらず、Firebaseをバージョンアップすると依存解決に失敗するという問題もあり、異なるアプローチを検討しました。
結果として、ヤプリではOCR機能をGoogleMLKitからAppleのVision Frameworkに置き換えて提供する方針で対応しました。
これによって、プライバシー要件のアップデートの対応も不要となり、Firebaseのバージョンアップによる影響もなくなりました。
おまけ：副産物として、残すはMLKitのみとなっていたCococaPodsでのライブラリ管理がなくなり、SPMに完全移行することも合わせて進めることができました🎉
その他SDK
ヤプリでは外部ベンダー提供のSDKと連携することで、提供しているオプション機能が存在します。
例えば、インストール数をベースとした広告効果分析が行える、AppsFlyer連携などがあります。
その他にもいくつか存在しますが、基本的には各ベンダーの窓口の方に連絡をとりながら、新しいプライバシー要件に対応したバージョンアップを行うという流れになります。
本体（アプリプラットフォーム）への対応
ここからはヤプリのアプリプラットフォームに対して、新しいプライバシー要件に対応した内容を紹介していきます！
ヤプリでは、プログラミング不要でネイティブアプリを作成・配信できるアプリプラットフォーム「Yappli」を提供しています。
1つのコードベースから800以上のアプリをビルドして、ネイティブアプリとしてストア公開が可能です。 yapp.li
対応としては、プライバシーマニフェストを本体のプロジェクトに追加することが必要になります。
ただ、800アプリ以上を同じコードベースで提供するプラットフォーマーとしては、ビルドフェーズでプライバシーマニフェストを柔軟に切り替えることも必要になります。
アプリプラットフォームのビルド基盤に関しては、iOSDCでヤプリの @k_katsumi が発表しておりますので、ご興味ある方はぜひご覧ください。
それでは、プライバシーマニフェストのそれぞれの項目ごとに対応内容を紹介していきます。
プライバシーマニフェストは以下の4つの項目から構成されています。
- Privacy Accessed API Types
- Privacy Nutrition Label Types
- Privacy Tracking Enabled
- Privacy Tracking Domains
項目に関する詳細は第１弾の記事で関連用語や参考記事も紹介しておりますので、必要に応じてそちらをご覧ください。
ヤプリiOSエンジニアの新プライバシー要件対応 | 時系列で振り返り、関連用語を理解する - Yappli Tech Blog
第１弾で紹介した関連表
| 項目 | キー名 | 関連用語 |
|---|---|---|
| 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フレームワークが共通して関連用語になるかと思います。
Privacy Accessed API Types
Privacy Accessed API TypesはRequired Reason APIを指しています。
ドキュメントが用意されており、対象のAPIをアプリ内で利用している場合には、プライバシーマニフェストに理由とともに定義する必要があります。
| API | 内容 |
|---|---|
| File Timestamp | ファイルのタイムスタンプ。使用例：ファイルが作成・変更・アクセスされた日時を取得して管理する。etc |
| System Boot Time | システムの起動時間。使用例：計測用にデバイスが最後に再起動された時間を取得する。etc |
| Disk Space | 使用可能なディスク容量。使用例：デバイスの空き容量が少なければキャッシュをクリアする。etc |
| Language and Locale | 言語とロケール。使用例：多言語対応。言語設定に応じてアプリの表示言語を変更する。etc |
| Time Zone | タイムゾーン。使用例：ユーザーのタイムゾーンに応じて時間を正しく表示する。etc |
| User Defaults | 言わずもがなUser Defaults。使用例：アプリキルなどアプリのライフサイクル外でも保持したい情報を保存する。etc |
それぞれ使用するAPIに応じて、あらかじめ用意されたいずれかの理由を選択することになります。
ヤプリでは、File Timestamp, User Defaultsを利用していたので、本体のプロジェクトのプライバシーマニフェストに追加しました。
選択した理由は、
- File Timestamp → C617.1
- User Defaults → 1C8F.1
となっています。
ヤプリではUserDefaultsをRich Push, Widgetで本体と共有していたため、CA92.1ではなく1C8F.1としています。
利用しているAPIの確認方法
Privacy Accessed API Types に不足がないかは、ストア審査か外部テスター審査のいずれかに提出して確認することができます。
画像だと対象アプリがSystem Boot Timeが不足している、ということがわかります。
利用しているSDKに対象APIがあり、プライバシーマニフェスト対応してくれなさそうな場合は？
本体のプライバシーマニフェストで項目を網羅しているとメールが届かなくなるため、利用しているSDKでプライバシーマニフェスト対応をしてくれない場合には本体に定義することで回避できます。
（基本的には利用しているSDK側にプライバシーマニフェストが適切に追加されていることが望ましいため、SDK側がどうしても対応してくれない場合の回避策かと思います）
当然かもしれませんが、SDK側の定義が本体や他のSDK側をカバーしてくれないことに注意する必要があり、本体にSDK Bで必要な項目定義がなく、SDK AでSDK Bに必要な項目が定義されていても、SDK Bの定義は別途必要になります。
Privacy Nutrition Label Types
Privacy Nutrition Label Typesは、新しいプライバシー要件以前からあるApp Privacyの内容になります。
アプリ開発者からだと、App Store Connectでどのようなデータを収集しているか、トラッキングするかを入力しているものですね。
入力した情報はApp Storeで対象のアプリページに表示され、ユーザーがアプリ内で収集したデータがどのように扱われるかを把握することができる仕組みです。
収集するデータはアプリによって様々です。
アプリプラットフォームを提供するヤプリでは、ビルドフェーズにアプリ単位で異なる情報に書き換える必要がありました。
ヤプリとしてどのように運用することにしたかは、ビルド基盤でのプライバシー要件の対応として、次の第三弾の記事で紹介しようと思います。
Privacy Tracking Enabled, Privacy Tracking Domains
最後にPrivacy Tracking Enabled, Privacy Tracking Domainsです。
アプリ内でATT(App Tracking Transparency)フレームワークを利用して、IDFAを収集している場合には無視できない項目です。
App Tracking Transparency（ATT）とは？
ATTは、Appleのプライバシーフレームワークです。
iOS14以降では、ユーザーから許可が得られないと、IDFAという広告識別子が取得できなくなりました。
IDFAはiOSデバイスに一意に割り当てられており、 デベロッパーとマーケターはIDFAを通して、アプリ外のWebサイトや他のアプリからやってきたかを把握することができます。
これによって、ユーザー属性を把握して分析し、有効なマーケティング施策を打ち出すことに繋げられます。
ATTフレームワークを利用している場合には、Tracking EnabledをTrueにして、かつ、Tracking DomainsにIDFAを収集するドメインを1つ以上定義する必要があります。
ドキュメントには以下のように記載があり、Tracking Domainsに定義したドメインはATTの許可をユーザーがしていない場合には、ネットワークリクエストがエラーとなると記載されています。
NSPrivacyTrackingDomains An array of strings that lists the internet domains your app or third-party SDK connects to that engage in tracking. If the user has not granted tracking permission through the App Tracking Transparency framework, network requests to these domains fail and your app receives an error.
To provide a list of internet domains in NSPrivacyTrackingDomains, set NSPrivacyTracking to true.
IDFAを収集する役割だけを担うドメインであれば定義に追加するのみで大きな懸念はありませんが、収集以外の役割をもつドメインの場合には問題があります。
収集以外の役割をもつドメインを定義してしまうと、ユーザーがATTを許可しない状態でリクエストがエラーとなるため、それ以外の役割を果たすことができなくなります。
＊ IDFAを収集するドメインがある場合には、それ専用にドメインを分けることが推奨されており詳しくは後述します。
ヤプリでは、二つのドメインでIDFAを扱うリクエストを行っていました。
二つのドメインをそれぞれ下記として進めていきます。
- analytics.yapplil.example.com
- yappli.example.com
＊ ドメイン名は仮置きです。
対象ドメインごとの役割
それぞれのドメインの役割は異なっています。
1. analytics.yapplil.example.com
アプリ内の画面表示やユーザー操作をイベントとして送信している分析用のドメインです。
マーケティングにも用いられる分析基盤にイベントを送信しており、IDFAもインプレッションを計測する目的で多く利用されていました。
2. yappli.example.com
アプリ情報をサーバーから取得するアプリの根幹となるドメインです。
アプリで表示されるコンテンツのほとんどを扱う重要なドメインです。
ATTをユーザーが許可しておりIDFAが取得可能であれば、ヘッダー情報に付与してサーバーに送信していますが、トラッキングの役割としてはほんの一部といえます。
それぞれのドメインのあるべきを考えつつどのように対応したかをここから紹介していきます。
対応①：Appleで推奨される方法でドメインを目的別に分ける
1. analytics.yapplil.example.comは、アプリ内の画面表示やユーザー操作をイベントとして送信している分析用のドメインです。
トラッキングすることも重要な目的ではありつつ、ユーザーにトラッキングを許可しない
どのように対応すべきかのプラクティスは、WWDC 2023の「Get started with privacy manifests」で紹介されています。
Get started with privacy manifests - WWDC23 - Videos - Apple Developer
つまり、トラッキングを行う（= IDFAを収集する）場合には、ATTが許可されている状態でIDFAを送信するドメインと、IDFAを送信しないドメインとして役割を分けようね、ということですね。
ヤプリでは、ATTの許可（トラッキング可能）状態によってリクエストするドメインを以下のようにわけて対応しました。
- トラッキング可：tracking-analytics.yapplil.example.com
- トラッキング不可：analytics.yapplil.example.com
ATTが不許可の状態ではanalytics.yapplil.example.comでリクエストするため、イベントはこれまで通りイベント計測ができます。
プライバシーマニフェストには、tracking-analytics.yapplil.example.comを定義します。
tracking-analytics.yapplil.example.comはトラッキングする役割として分けられているため、ユーザーがATTを許可している状態でIDFAを付与してイベント計測を行います。
これによって、Appleの提示する方法としてドメインを目的別に分けることができました。
対応②：IDFA送信をやめて対応不要にする
2. yappli.example.comは、アプリ情報をサーバーから取得するアプリの根幹となるドメインです。
1. analytics.yapplil.example.comは、分析用のドメインであったため、トラッキングする役割も重要な責務と判断してドメインを分ける対応としました。
しかし、2. yappli.example.comの場合には、以下の理由からIDFAを送信しないようにする対応としました。
- 一部機能のためにIDFAを収集しており、本来のドメインの役割からは外れている
- 仮に対応した場合には、アプリ機能全体が影響範囲となりインパクトが大きい
歴史的経緯で収集していたもので、現在はほとんど使用していないこともわかり、社内で確認を進めながらIDFAを送信しない方針で決定できました。
これによって、トラッキングを行わないドメインとなったため、プライバシーマニフェスト定義も不要となりました。
まとめ
今回はAppleの新しいプライバシー要件に対して、ヤプリで実際に進めた内容を大公開させていただきました！
5月1日に新しいプライバシー要件が導入されて1ヶ月以上経過していますが、ヤプリではそれ起因のリジェクトは発生していません。
これから対応される方、他社の対応内容が気になっている方のお役に立てれば幸いです。
注：可能な限り公式情報を参考に執筆しておりますが、記事内容に起因するトラブルなどの補償はしかねますのでご了承ください。
- Privacy manifestファイル や、Privacy manifest という表現をされる場合もありますが、本記事ではプライバシーマニフェストとして統一しています。同じものを指しておりますので、その認識で読み進めていただければと思います 🤲↩
