Appleのプライバシーマニフェスト対応の適用日である5/1までもうすぐと迫りました。この記事では、プライバシーマニフェストの説明は省き、具体的に困りどころになるであろう細かいポイントをまとめます。追加情報が出てきたら順次加筆・修正します。
4/26のAppleアナウンス
Appleからプライバシーマニフェストに関して追加の情報が発表されました。
まず、以下の対応が必要であることが書かれています。
そして、以下の場合にはアプリを提出しても却下されます。
- 記載が必要なAPIを載せていない
- 埋め込まれた動的フレームワークの一部であること
- 一般的なサードパーティSDKリストに記載のあるサードパーティSDK
事前にやるべきだと思われていた内容からかなり譲歩されて、リストに記載されたサードパーティSDKのみに限定されたようです。さらに、動的フレームワークのみ対象となり、アプリ本体のバイナリに組み込まれる静的フレームワークは対象外になったようです。
実際にこの制限に緩和されたのかはアプリをアップロードして試してみないとわかりませんが、公式からの情報なので参考になりそうですね。おせーよ。
将来的にはアプリ全体への適用が示唆されていますが、5/1に向けてはかなり安心できる内容になったかと思います。
注意点まとめ
flutterfire ライブラリは最新まで上げる
Firebase Apple SDKの最新版である10.24.0のリリースが4/9に行われています。
このリリース内で、Crashlyticsのプライバシーマニフェスト記載必須のmach_absolute_time
が削除されています。
Flutterでは、このSDKに対応したflutterfireのfirebase_core
は4/16にリリースされています。ギリギリの対応になっていますが、アップデート未対応の方は急ぎましょう。
https://github.com/firebase/flutterfire/blob/master/CHANGELOG.md#firebase_core---v2300
iOSのコードを含むライブラリのバージョンアップ
注意が必要な点として、iOSのコードを含むライブラリのバージョンを上げる必要があります。
例えば、flutter.devが公開しているshared_preference
は子ライブラリであるshared_preferences_foundation
が実際のiOSの処理を担当していますが、shared_preference
側からの最小バージョンの依存関係は更新されていませんでした。そのため、pubspec.yaml上で更新しても、pubspec.lockのshared_preferences_foundation
が古いままというケースがありえます。
この依存関係の解決のPRが4/11に行われていますので、flutter.devのライブラリ群も最新にしておくと良いでしょう。
空のプライバシーマニフェストを追加する必要はない
iOSのコードを含むライブラリで、特に記載が必要なAPIを使っておらず、何もデータ収集をしていない場合、空のプライバシーマニフェストを追加する必要があるのではないか?と思うかもしれません。こちらはAppleのフォーラム上でDTSエンジニアから回答がありました。
IS PrivacyManifest.xcprivacy still… | Apple Developer Forums
If your framework doesn't require a privacy manifest, do nothing. Avoid adding an empty privacy manifest to your framework.
つまり、空のプライバシーマニフェストを入れる必要はないということです。もしまだプライバシーマニフェストに対応していないライブラリがあった場合、追加するべきだと早合点でず、落ち着いて製作者に問い合わせたり自身でAPIを調べるなりしましょう。
プライバシーマニフェストに空のDictionaryを入れない
プライバシーマニフェストにTracking Domeinなどを追加する項目がありますが、ここに空の<dict/>
が入っていると、無効なプライバシーマニフェストと言われるみたいです。無駄に厳しくない?
Flutterとして各パッケージのマニフェストを調査・処理する方法は検討中
プライバシーマニフェストに未対応のライブラリがある場合、どのライブラリがプライバシーマニフェスト要件に合致していないのかを通知してくれます。しかし、Flutterで静的フレームワークなどが「Runner」として丸め込まれてしまい、調査が困難になるケースが発生しています。
Flutter側としては現在解決策を持っておらず、下記のコメントの通り自力でどうにかするしかないというのが現状です。
Determine how to handle privacy manifests in packages · Issue #131940 · flutter/flutter · GitHub
静的フレームワークへの対応について
上記に関連します。躓きやすいポイントです。
ライブラリを静的フレームワーク(Static linking)として読み込むと、アプリのバイナリに直接コードが組み込まれます。ですが、Apple側のプライバシーマニフェスト判定ではアプリ内のコードとして判定されてしまいます。 静的フレームワークを使用する場合、静的フレームワークのプライバシーマニフェストをアプリに記載する必要がありそうです。
但し、4/26のAppleからのアナウンスを見ると、こちらの対応は必須ではなくなったようです。