Apple HIG 【Accessing private data編】
Appleが提唱しているHuman Interface Guidelines（HIG）についてちゃんと読んでいなかったので、掻い摘んでまとめてみます。
今回は、年々厳重になってきている（気がする）プライバシー周りに関する部分を読んでみました。
以下、翻訳したまとめです。
違う解釈をしている可能性もあるのでご了承いただければと思います。
※プラットフォームはiOSのみに絞ってひとまずまとめます。
ユーザは自分のデバイスに対して個人的な意図で利用し、アプリがプライバシーを保護してくれることを期待しています。
ユーザをトラッキングしたり、データやデバイスリソースへのアクセス許可を要求することに加えて、アクセス許可したデータに対して保護していることは必須です。
開発者はアプリを公開するときに、アプリ内での利用が想定されるプライバシーデータに関して説明をしなければいけません。（データの収集や利用等の目的を知らせるために）
設定した内容がApple Storeでのアプリページに表示されるので（下記画像参照）、それをもとにユーザはアプリをDLすることを決めます。
※公式より抜粋
Requesting permission
アクセス許可をしないといけないものは下記のようなものがあります。
位置情報、健康状態、金銭面、連絡先などを含む個人に関するデータ
メール、メッセージ、ゲームプレイ情報、オーディオ、写真、ビデオ等のユーザが生成したデータ
Bluetooth周辺機器、Wi-Fiネットワーク、ローカルネットワークなどの保護されたリソース
カメラ・マイクなどのデバイス機能
アプリトラッキングを可能にするためのデバイスの広告識別子
それぞれのリクエストに関しては標準アラートでユーザに表示され、アラート内ではなぜアクセス許可をしているのかをアラート内で説明しないといけません。
アクセス許可の更新や確認は設定アプリの「プライバシー」から確認できます。
アプリが明らかにあるデータ・リソースへのアクセスを必要としている時のみアクセス許可のリクエストをすること
意味のわからないタイミングでリクエストをされてもユーザは困惑するから当たり前だよねぇって感じ。
理想的なのはユーザがアクセスが必要な機能を使い始めたタイミングでアクセス許可のリクエストを送ることです。
ex. はじめて位置情報ボタンを押したタイミングで、位置情報のアクセスをリクエストする。
アプリを起動するためにデータ・リソースが必要ではない限り、アプリ起動時にアクセス許可をすることは避けること
リクエストする理由が明らかであれば、ユーザはアプリ起動時にリクエストに困惑する可能性は下がります。
ex. 地図系のアプリを起動する際に位置情報のリクエストをすることは、ユーザが想定できる
結構通知系のリクエストを初回起動時に行うアプリが多いので、これは割とこの原則に反しているのではないかと個人的に思ったりした🤔
リクエストした機能・データ・リソースがアプリ内でどのように使われるのかを具体的に説明すること
説明文はアラートのタイトル（アプリ名が入っている）と選択肢のボタンに表示されます。
受動態を避けた文章で、ピリオドをつけてください。
※公式より抜粋
Location Button
iOS15からCore Locationが位置情報ボタンが提供され、ボタンを押した時に位置情報のアクセスを一時的に承認できるようになりました。
ボタンのUIはアプリに合わせて調整ができ、認識しやすい形で表示できます。
ユーザがはじめて位置情報ボタンを押した時に位置情報の許可アラートが表示され、そこで承認するか否かを決めます。
アプリの機能で、位置情報の共有を簡単に実施できるように位置情報ボタンを利用することを検討すること
ユーザがよく位置情報を「一度だけ許可」することが想定できるのであれば、位置情報ボタンを使用して繰り返しリクエストをしなくても位置情報を共有できるように考慮してください。
何回もリクエストされたらクドイもんねぇ🤔
アプリのUIに調和するような位置情報ボタンのカスタマイズを検討すること
例えば、
「現在地」、「現在地を共有」といった機能に即したボタン文言にする
塗りつぶされた or アウトライン化された位置情報とわかるアイコンを使用する
背景色・タイトル色・アイコン色を選択する
ボタンの角を調整する
ボタンのテキストはボタン内に収まるようにする必要があります。
言語が変わっても文字が切り捨てられずに収まるようにしないといけません。
外国語対応しているアプリであればテスト項目増えそうだな…😇
と思ったやまたくであった
Pre-alert screens
理想的なのは、標準アラートの文言でユーザがアクセス許可の理由を理解できることです。
しかしこれは難しいので、リクエスト許可をする前にリクエストの理由をより明確に説明したカスタム画面を表示させることもできます。
ボタンを一つだけ含めて標準アラートを表示させるようにすること
カスタム画面にアラートを表示しない選択肢もあると、ユーザは操作されていると感じる可能性があります。
また、カスタム画面内のボタン文言を「許可」や「承認」とすると、ユーザが意図せずにアクセスを許可してしまう可能性もあるので、「次へ」や「進む」といった文言にして、ボタンを押した後に標準アラートが表示されることを想定できるようにしてあげることが良いです。
※公式より抜粋
カスタム画面に追加のアクションを含めないこと
閉じるボタンのように、標準アラートを表示させなくても画面を閉じれるような選択肢をユーザに持たせないでください。
Tracking requests
アプリトラッキングはセンシティブな問題で、トラッキングすることのメリットを説明するにはカスタム画面を表示させてあげるのが有効な場合もあります。
アプリ起動直後にトラッキングを実行する場合は、トラッキングデータ収集前に標準アラートを表示する必要があります。
標準アラート表示前に、ユーザが混乱するようなカスタム画面を表示させないこと
アラートをよく読まずに閉じるユーザもいるので、そのようなケースで選択に影響を与えるような画面構成にしているとストア申請の時点でNGが出る可能性があります。
NGとなるようなカスタムデザインとしては、インセンティブの提供・リクエスト画面のような見た目、アラート画像の表示等があるので、そのようなデザインにしないようにしましょう。
※公式より抜粋
Protecting data
個人情報の保護は最重要事項です。
認証はパスワード方式のみを採用しないこと
指紋認証を可能にするTouch ID等の他の方法も活用してください。
機密情報はキーチェーンに保存すること
キーチェーンは個人情報を処理する際に安全で予測可能なUXを提供します。
パスワードやその他センシティブな情報を単なるテキストファイルに保存しないこと
ファイルのアクセス許可をしてアクセス制限したとしても、機密情報はキーチェーンの方が安全なのでそちらで管理するようにしましょう。
カスタム認証スキームを作成しないこと
アプリ内で認証が必要な場合は、Sign in with Appleやパスワードの自動入力等の、システムで提供された機能を採用するようにして下さい。
*
*
*
普段何気なく開発しているプライバシー情報に関する機能ですが、意外と読んでみないと知らないこともありましたね。
リクエスト前のカスタム画面に関しては、場合によってはストア申請で弾かれる場合もあるんだなぁとか、意外と知らないとやってしまいがちなものもあるようなケースもあったので自分が関わるサービスでは今回のインプットがタメになると良いなと思いました。
通知許諾のタイミングとかめっちゃ考えたい（ひとりごと）