KDE BLOG

バイブス

【Human Interface Guidelines 翻訳 vol.9】iOS - App Architecture - Requesting Permission

元ページ
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/requesting-permission/

Requesting Permission(許可の要求)

Users must grant permission for an app to access personal information, including the current location, calendar, contact information, reminders, and photos. Although people appreciate the convenience of using an app that has access to this information, they also expect to have control over their private data. For example, people like being able to automatically tag photos with their physical location or find nearby friends, but they also want the option to disable such features.

ユーザーは、アプリが現在の場所、カレンダー、連絡先情報、リマインダー、写真などの個人情報にアクセスすることを許可する必要があります。
この情報にアクセスできるアプリを使用することの利便性は高く評価されますが、個人データを管理することも期待されています。
たとえば、写真に実際の場所のタグを自動的に付けたり、近くの友達を見つけたりすることを好みますが、そのような機能を無効にするオプションも求めています。

f:id:jinseirestart:20200628034655p:plain

Request personal data only when your app clearly needs it.> It’s natural to be suspicious of a request for personal information, especially if there’s no obvious need for it. Make sure permission requests occur only when people are using features that clearly need personal data. For example, an app might only request access to the current location when activating a location tracking feature.

アプリで明らかに必要な場合にのみ、個人データを要求します。
特に明白な必要がない場合は特に、個人情報の要求を疑うのは当然です。
個人データが明らかに必要な機能を人々が使用している場合にのみ、許可リクエストが発生するようにしてください。
たとえば、位置追跡機能をアクティブにすると、アプリは現在地へのアクセスのみを要求する場合があります。

f:id:jinseirestart:20200628035115p:plain

Explain why your app needs the information. Provide custom text (known as a purpose string or usage description string) for display in the system's permission request alert, and include an example. Keep the text short and specific, use sentence case, and be polite so people don't feel pressured. There’s no need to include your app name—the system already identifies your app. For developer guidance, see Protecting the User's Privacy.

アプリに情報が必要な理由を説明してください。
システムの権限要求アラートに表示するためのカスタムテキスト(目的文字列または使用法説明文字列と呼ばれます)を提供し、例を含めます。
テキストは短く具体的なものにし、文の大文字小文字を使用し、礼儀正しくして、人々がプレッシャーを感じないようにします。
アプリ名を含める必要はありません。システムはすでにアプリを識別しています。
開発者向けガイダンスについては、ユーザーのプライバシーの保護をご覧ください。

Example purpose strings(目的文字列の例)
OK The app records you during the night to detect snoring sounds.
(アプリは、いびき音を検出するために夜間にあなたを記録します)
NG Microphone access needed for a better experience.
(より良い体験のためにマイクへのアクセスが必要です)
NG Turn on microphone access.
(マイクへのアクセスをオンにします)

Request permission at launch only when necessary for your app to function. Users won’t be bothered by this request if it’s obvious that your app depends on their personal information to operate.

アプリが機能するために必要な場合にのみ、起動時に権限をリクエストします。
アプリの操作が個人情報に依存していることが明らかな場合、ユーザーはこのリクエストに悩まされることはありません。

Don’t request location information unnecessarily. Before accessing location information, check the system to see whether Location Services is enabled. With this knowledge, you can delay the alert until a feature truly requires it, or perhaps avoid the alert altogether. To learn how to implement location features, see MapKit and Location and Maps Programming Guide.

位置情報を不必要に要求しないでください。
位置情報にアクセスする前に、システムをチェックして、位置情報サービスが有効になっているかどうかを確認してください。
この知識があれば、機能で本当に必要になるまでアラートを遅らせたり、アラートを完全に回避したりできます。
位置情報機能の実装方法については、MapKit および 位置情報と地図のプログラミングガイドをご覧ください。

Use the system-provided alert. You can customize text in the standard permission alert, but avoid adding custom prompts that replicate the standard alert’s behavior or appearance.

システム提供のアラートを使用します。
標準の許可アラートのテキストをカスタマイズできますが、標準のアラートの動作や外観を複製するカスタムプロンプトを追加しないでください。