Apple ヒューマンインターフェースガイドライン日本語訳 - iOS App Architecture編

Apple ヒューマンインターフェースガイドライン日本語訳 - iOS App Architecture編

August 2, 2021

本記事は、本記事投稿時点の Human Interface Guidelines - iOS を日本語訳したものです。DeepL で機械翻訳を行った後、誤訳が見受けられた際には修正を加えています。

Human Interface Guidelines - iOS #

https://developer.apple.com/design/human-interface-guidelines/

App architecture - Launching #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/launching/

ローンチ #

起動時のエクスペリエンスは、ユーザーがアプリに対して抱く印象を大きく左右します。使用しているデバイスや、最後にアプリを開いてからの経過時間にかかわらず、起動時のエクスペリエンスは迅速かつシームレスでなければなりません。

以下のガイドラインを参考にして、快適なローンチエクスペリエンスを設計してください。開発者向けのガイダンスについては、「アプリの起動に対応する」を参照してください。

起動画面を提供する システムは、アプリが起動した瞬間に起動画面を表示し、すぐにアプリの最初の画面に切り替えます。起動画面の役割は、アプリが高速で応答性が高いという印象を人々に与えつつ、初期コンテンツのロードを可能にすることです。起動画面からシームレスに移行するためには、最初のアプリ画面に似たプレーンな画面をデザインし、それ自体が注目されないようにします。詳しくは、「起動画面」を参照してください。

適切な方向で起動する アプリが縦向きと横向きの両方をサポートしている場合は、デバイスの現在の向きを使って起動する必要があります。アプリが 1 つの方向でしか動作しない場合は、常にその方向で起動し、必要に応じてデバイスを回転させるようにします。そうしないといけない理由がない限り、ランドスケープモードのアプリは、デバイスが左右どちらに回転したかに関わらず、正しい向きで起動しなければなりません。詳しくは、「適応性とレイアウト」を参照してください。

前もって設定情報を求めない 人々はアプリがただ動くことを期待しています。大多数のユーザーのためにアプリを設計し、異なる設定を必要とする少数のユーザーには、ニーズに合わせて設定を調整してもらいます。可能な限り、デバイスの設定やデフォルト、または iCloud などの同期サービスから設定情報を得るようにしましょう。設定情報の提供を求めなければならない場合は、アプリを最初に開いたときに情報の提供を促し、後からアプリの設定で情報を変更できるようにします。

アプリ内ライセンス契約と免責事項の表示を避ける アプリをダウンロードする前に契約書と免責事項を読むことができるように、App Store に契約書と免責事項を表示させます。アプリ内にこれらの項目を含める必要がある場合は、ユーザーエクスペリエンスを妨げないようにバランスよく統合してください。

アプリの再起動時に以前の状態に戻す アプリの中で、以前の場所にたどり着くために手順を辿らせないようにしましょう。アプリの状態を保存・復元して、中断した場所から続けられるようにしましょう。

再起動を推奨してはいけません 再起動には時間がかかり、アプリの信頼性が低く、使いにくいと思われてしまいます。アプリにメモリやその他の問題があり、システムが起動していないと実行できない場合は、その問題に対処する必要があります。

アプリの評価を急に求めたり、頻繁に求めたりしないようにしましょう 発売後すぐに評価を求めたり、ユーザーがアプリを使用している間に頻繁に評価を求めたりすることは、迷惑であり、有益なフィードバックの数が減る可能性があります。熟慮されたフィードバックを促すために、評価を求める前に、アプリについて意見を形成する時間を与えましょう。評価を求めるプロンプトを拒否する方法を常に提供し、アプリの評価を強制することはありません。

App architecture - Onboarding #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/onboarding/

オンボーディング #

オンボーディングでは、新しいユーザーを迎え入れたり、戻ってきたユーザーと再会したりすることができます。素早く、楽しく、教育的なオプションのオンボーディング体験は、ユーザーの邪魔になることなく、アプリを最大限に活用するのに役立ちます。

新機能や重要な機能が説明され、「次へ」ボタンが表示されている ただ設定するだけではなく、アプリを楽しんでもらうためのオンボーディングを提供します。人々は、アプリについて詳しく知る機会を与えられたことに感謝しますが、同時にアプリが動作することも期待しています。オンボーディングエクスペリエンスに、セットアップやライセンスの詳細を含めないようにしましょう。詳細は、「起動」を参照してください。

すぐに行動に移す システムが起動画面をアプリの初期画面に置き換えたら、すぐにアプリを楽しんでもらいます。チュートリアルやイントロを提供する必要がある場合は、それらをスキップする方法を提供し、再訪ユーザーには自動的に表示しないようにします。

ヘルプの必要性を予測する ユーザーが困ったときには、積極的に助けを求めましょう。例えば、ゲームでは、一時停止したときやキャラクターが進んでいないときに、役立つヒントをさりげなく表示することができます。また、最初のチュートリアルで何かを見逃してしまった場合に備えて、チュートリアルを何度も再生できるようにしておきましょう。

チュートリアルでは、必要なことだけを説明しましょう 初心者のためにガイダンスを提供するのは良いことですが、教育は優れたアプリデザインの代わりにはなりません。何よりもまず、アプリを直感的に操作できるようにしましょう。あまりにも多くのガイダンスが必要な場合は、アプリのデザインを見直してください。

楽しく学べて、発見がある 説明書を読むよりも、実際にやってみて学ぶ方がずっと楽しく、効果的です。アニメーションやインタラクティブ機能を使って、徐々に、そして文脈に沿って教えていきましょう。インタラクティブに見える静的なスクリーンショットの表示は避けましょう。

App architecture - Loading #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/loading/

読み込み中 #

コンテンツの読み込み中に、空白や静止した画面が表示されると、アプリがフリーズしているように見え、混乱や不満を招き、ユーザーがアプリから離れてしまう可能性があります。

ローディングが発生しているときには、それを明確にしてください 最低限、アクティビティスピナーを表示して、何かが起こっていることを伝えます。さらに、どのくらい待たされるかがわかるように、進行状況を明示するとよいでしょう。

なるべく早くコンテンツを表示する 期待していた画面が表示される前に、コンテンツの読み込みを待たせるのはやめましょう。すぐに画面を表示し、コンテンツがまだ提供されていないことを示すために、プレースホルダーのテキスト、グラフィック、またはアニメーションを使用します。コンテンツが読み込まれたら、これらのプレースホルダー要素を交換します。可能な限り、アニメーションの再生中や、ユーザーがレベルやメニューをナビゲートしている間などに、今後のコンテンツをバックグラウンドでプリロードします。

読み込み時間を短縮するために、ユーザーを教育したり、楽しませたりします ゲームプレイのヒントを表示したり、楽しいビデオシーケンスや面白いプレースホルダグラフィックスを表示したりすることを検討してください。

ローディングスクリーンのカスタマイズ 標準的な進行状況の表示は、通常は問題ありませんが、時に文脈に合わないと感じることがあります。アプリやゲームのスタイルに合わせてアニメーションやエレメントをカスタマイズすることで、より没入感のある体験をデザインすることができます。

その他のガイダンスについては、「進行状況インジケータ」を参照してください。

App architecture - Modality #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/modality/

モダリティ #

モダリティとは、ユーザーの現在のコンテキストとは別の一時的なモードでコンテンツを表示し、終了するためには明示的なアクションを必要とするデザイン手法です。コンテンツをモーダルに提示することで、以下のことが可能になります。

自己完結的なタスクや密接に関連した選択肢に集中できるようにする
重要な情報を確実に受け取り、必要に応じて行動することができる。

iOS には、アプリの特定の状況で使用するアラート、アクティビティビュー（またはシェアシート）、アクションシートが用意されています。アプリでカスタムモーダルコンテンツを表示するために、iOS 13 以降では以下の表示スタイルがサポートされています。

シート #

シートのプレゼンテーションスタイルは、コンテンツを部分的に覆うカードとして表示され、覆われていない部分はすべて暗くなり、コンテンツとのインタラクションができなくなります。親ビューまたは前のカードの上端が現在のカードの背後に表示され、カードを開いたときに中断したタスクを思い出しやすくなります。カードを閉じるには、以下の方法があります。

画面上部から下に向かってスワイプする
カードの内容が一番上までスクロールしているときに、画面上の任意の場所から下にスワイプする
ボタンをタップする

シートは、複雑なタスクを実現しない非没入型のモーダルコンテンツに使用します。

フルスクリーン #

フルスクリーンの表示スタイルは、画面全体を覆います。前のビューが完全に覆われるので、視覚的な混乱を最小限に抑えることができます。人はボタンをタップしてフルスクリーンモーダルビューを解除します。

フルスクリーンモーダルビューを使用するのは、ビデオ、写真、カメラビューなどの没入型コンテンツや、ドキュメントのマークアップや写真の編集など、フルスクリーン表示が有効な複雑なタスクの場合です。

注意

現在のコンテキストモーダルビュースタイルを使用して、モーダルコンテンツを分割ビューペインやポップオーバーなどのフルスクリーンではないビューに表示している場合は、コンパクトな環境でモーダルコンテンツを表示するときは、シートを使用するように変更する必要があります。

モダリティは意味のあるときに使う モーダルな体験は、人々の注意を現在のタスクとは異なる選択やタスクの実行に向けさせることが重要な場合にのみ作成します。モーダルな体験は、人々を現在の状況から離脱させ、解除するためのアクションを必要とするため、明確なメリットがある場合にのみ使用することが重要です。

アラートは、必要な情報、そして理想的には実行可能な情報を提供するためのものです 通常、アラートが表示されるのは、何か問題が発生したときです。アラートはエクスペリエンスを中断し、解除するためにはタップが必要なので、人々がその中断が正当なものであると感じることが重要です。詳しくは、「アラート」をご覧ください。

モーダルタスクは、シンプルで短く、焦点を絞ってください アプリの中にアプリを作らないようにしましょう。モーダルタスクが複雑すぎると、モーダルコンテキストに入ったときに中断したタスクを見失う可能性があります。特に、ビューの階層を含むモーダルタスクの作成には注意が必要です。なぜなら、人々は道に迷い、自分の手順を辿る方法を忘れてしまうからです。モーダルタスクがサブビューを含む必要がある場合は、階層を通る単一のパスと、完了までの明確なパスを提供します。タスクを完了する以外の目的で Done ボタンを使用することは避けてください。

モーダルビューを解除するボタンを必ず用意してください 例えば、Done や Cancel を使用するとよいでしょう。ボタンを含めることで、モーダルビューが支援技術でアクセスできるようになり、解除のジェスチャーの代わりになります。

必要に応じて、モーダルビューを閉じる前に確認を取ることで、データの損失を防ぐことができます 解除ジェスチャーやボタンを使ってビューを閉じるかどうかにかかわらず、その操作によってユーザーが作成したコンテンツが失われる可能性がある場合は、状況を説明し、解決する方法を示すアクションシートを提示してください。

ポップオーバーの上に表示されるカードを表示しないでください ポップオーバーの中にカードを表示することはできますが、ポップオーバーの上には何も表示してはいけません（場合によっては警告を除く）。まれに、ポップオーバーの中で人々がアクションを起こした後にカードを表示する必要がある場合がありますが、カードを表示する前にポップオーバーを閉じてください。

一般的には、モーダルタスクを特定するタイトルを表示します モーダルタスクに入ると、それまでのコンテクストから切り替わるので、新しいコンテクストを明確にするのがよいでしょう。また、ビューの他の部分に、タスクをより詳しく説明したり、ガイダンスとなるテキストを表示することもできます。

モーダルビューの外観をアプリと連携させる たとえば、モーダルビューにナビゲーションバーが含まれている場合、アプリのナビゲーションバーと同じ外観を使用する必要があります。

アプリで意味のあるモーダル遷移スタイルを選択します アプリと調和し、一時的なコンテキストシフトの認識を高める遷移スタイルを使用してください。デフォルトのトランジションは、モーダルビューを画面の下部から垂直にスライドさせ、解除されると元に戻します。アプリ全体で一貫したモーダル遷移スタイルを使用してください。

開発者向けのガイダンスとして、UIViewController と UIPresentationController を参照してください。

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/navigation/

ナビゲーション #

アプリのナビゲーションは、期待を裏切るまで気づかれない傾向にあります。あなたの仕事は、アプリケーションの構造と目的をサポートし、注目を集めることなく、ナビゲーションを実装することです。ナビゲーションは、自然で親しみやすいものでなければなりません。また、インターフェースを支配したり、コンテンツからフォーカスを外したりしてはいけません。iOS では、ナビゲーションには 3 つの主なスタイルがあります。

階層型ナビゲーション #

目的地に到達するまで、1 つの画面で 1 つの選択を行います。別の目的地に行くには、元の場所に戻るか、最初から別の選択肢を選ぶ必要があります。設定」や「メール」などはこのナビゲーションスタイルを採用しています。

フラットナビゲーション #

複数のコンテンツカテゴリーを切り替えて表示します。Music と App Store がこのナビゲーションを採用しています。

コンテンツ重視のナビゲーションと体験重視のナビゲーション #

コンテンツの中を自由に移動したり、コンテンツ自体がナビゲーションを決定する。ゲーム、書籍、その他の没入型アプリケーションは、一般的にこのナビゲーションスタイルを採用しています。

アプリの中には、複数のナビゲーションスタイルを組み合わせているものがあります。例えば、フラットなナビゲーションを採用しているアプリでは、各カテゴリー内に階層的なナビゲーションを実装している場合があります。

常に明確な経路を提供する アプリの中で自分がどこにいるのか、次の目的地に行くにはどうすればいいのかを常に把握しておく必要があります。ナビゲーションのスタイルにかかわらず、コンテンツへのパスが論理的で予測可能であり、簡単に辿れることが重要です。一般的に、各画面への経路は 1 つです。1 つの画面を複数の文脈で見る必要がある場合は、アクションシート、アラート、ポップオーバー、モーダルビューなどの使用を検討してください。詳しくは、「アクションシート、アラート、ポップオーバー、モーダル」を参照してください。

コンテンツに素早く簡単にたどり着けるような情報構造を設計する タップ、スワイプ、スクリーンの数が最小限で済むように情報構造を整理します。

タッチジェスチャーを使って流動性を高める 最小限の摩擦で簡単にインターフェースを移動できるようにしましょう。例えば、画面の横からスワイプすると前の画面に戻れるようにするなどです。

標準的なナビゲーションコンポーネントを使用する 可能な限り、ページコントロール、タブバー、セグメントコントロール、テーブルビュー、コレクションビュー、スプリットビューなどの標準的なナビゲーションコントロールを使用してください。ユーザーはこれらのコントロールに慣れ親しんでおり、アプリをどのように操作すればよいか直感的にわかるでしょう。

データの階層をたどるには、ナビゲーションバーを使用します ナビゲーションバーのタイトルは、階層内の現在の位置を示し、戻るボタンで前の位置に簡単に戻ることができます。具体的な方法については、「ナビゲーションバー」を参照してください。

タブバーを使って、コンテンツや機能を分類して表示することができます タブバーを使うと、現在の位置に関係なく、カテゴリー間をすばやく簡単に切り替えることができます。具体的な方法については、「タブバー」を参照してください。

iPad では、タブバーの代わりにスプリットビューを使用できます スプリットビューは、タブバーと同様のクイックナビゲーションを提供するとともに、大きなディスプレイを有効に活用できます。詳しくは、「分割表示」をご覧ください。

同じ種類のコンテンツが複数ページある場合は、ページコントロールを使用します ページコントロールは、利用可能なページの数と現在アクティブなページを明確に伝えます。天気」アプリでは、ページコントロールを使用して、場所ごとの天気ページを表示しています。具体的な方法については、「ページコントロール」を参照してください。

ヒント

セグメント化されたコントロールやツールバーでは、ナビゲーションはできません。セグメント化されたコントロールを使用して、情報をさまざまなカテゴリに整理します。ツールバーは、現在のコンテキストを操作するためのコントロールとして使用します。これらの要素の詳細については、「セグメント化されたコントロールとツールバー」を参照してください。

App architecture - Accessing user data #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/

ユーザーデータおよびリソースへのアクセス #

ユーザーのプライバシーは最も重要です。アプリを信頼してもらうためには、必要とするプライバシー関連のデータやリソース、およびそれらの使用方法について透明性を確保することが重要です。たとえば、次のようなものにアクセスする許可を求めなければなりません。

位置情報、健康情報、財務情報、連絡先情報、その他の個人識別情報を含む個人データ
電子メール、メッセージ、カレンダーデータ、連絡先、ゲームプレイ情報、Apple Music アクティビティ、HomeKit データ、およびオーディオ、ビデオ、写真コンテンツなどのユーザが作成したコンテンツ
Bluetooth 周辺機器、ホームオートメーション機能、Wi-Fi 接続、ローカルネットワークなどの保護されたリソース
カメラやマイクなどのデバイス機能

重要

iOS 14.5 および iPadOS 14.5 以降では、ユーザーを追跡したり、ユーザーのデバイスの広告識別子にアクセスしたりする場合は、AppTrackingTransparency フレームワークを使ってユーザーの許可を求める必要があります。詳しくは、「ユーザーのプライバシーとデータ利用」をご覧ください。

新規または更新されたアプリケーションを提出する際には、App Store がお客様の製品ページに情報を表示できるように、お客様のプライバシー慣行および収集するプライバシー関連データに関する詳細を提供する必要があります。この情報は、App Store Connect でいつでも管理することができます。ユーザーは、アプリをダウンロードする前に十分な情報を得た上で判断するために、商品ページのプライバシーに関する詳細情報を使用します。詳細については、App Store の App privacy details をご覧ください。

アクセス許可の申請 #

ユーザーデータや保護されたリソースを使用する前に、人々の許可を得る必要があります。

許可を求めるのは、アプリが明らかにデータやリソースへのアクセスを必要とする場合のみにしてください 特に明らかな必要性がない場合、個人情報やデバイス機能へのアクセスを要求されると、人々が疑うのは当然のことです。理想的には、人々がアクセスを必要とするアプリの機能を実際に使用するまで、許可を要求するのを待ちます。位置情報の要求については、位置情報ボタンを使用することで、人々がその場で位置情報を共有できるようになります。ガイダンスについては、「位置情報ボタンを使用する」を参照してください。

アプリが機能するためにデータやリソースが必要な場合にのみ、起動時に許可を求めます アプリが情報を必要とする理由が明らかな場合は、起動時の要求に悩まされる可能性は低くなります。ユーザーがアプリを起動したらすぐにアプリのトラッキングを行いたい場合は、トラッキングデータを収集する前に、システムが提供するアラートを表示する必要があります。

システムは、個人情報や保護されたリソースへのアクセス要求を人々に表示する標準的なアラートを提供します。ユーザーは、アプリがアイテムを必要とする理由の説明を提供し、システムはこの説明をアラートに表示します。ユーザーは、「設定」>「プライバシー」で説明を確認し、選択を更新することもできます。

要求しているデータやリソースをアプリがどのように使用するかを明確に説明するコピーを書きます 標準的なアラートでは、アプリ名の後、人々が許可または拒否するために使用するボタンの前に、お客様のコピー（目的文字列または使用説明文字列と呼ばれます）が表示されます。端的で具体的、かつ理解しやすい、簡潔で完全な文章を目指します。大文字小文字を区別し、受動態を避け、最後にピリオドを入れてください。開発者向けのガイダンスとしては、「保護されたリソースへのアクセスを要求する」と「アプリのトラッキングの透明性」を参照してください。

	例	注意事項
✅	このアプリは、いびきの音を検出するために夜間に記録します。	アプリがデータを収集する方法と理由を明確に説明する能動的な文章です。
❎	より良い体験をするためには、マイクへのアクセスが必要です。	曖昧で定義されていない正当性を示す受動的な文章です。
❎	マイクアクセスをオンにします。	正当な理由を示さない命令文です。

位置情報ボタンの使用 #

iOS 15 以降では、Core Location にボタンが用意されており、タスクに必要な時に位置情報へのアクセスをアプリに一時的に許可することができます。位置情報ボタンの外観は、アプリの UI に合わせて変えることができますが、一目でわかる方法で位置情報の共有というアクションを伝えることができます。

位置情報ボタンは、アプリにデバイスの位置情報を要求する一時的な権限を与えます。あなたのアプリに認証ステータスがない場合、位置情報ボタンをタップすると、標準のアラートで「一度だけ許可」を選択した場合と同じ効果が得られます。ユーザーが以前に「アプリ使用中」を選択していた場合、位置情報ボタンをタップしてもアプリのステータスは変わりません。開発者向けのガイダンスについては、LocationButton (SwiftUI)および CLLocationButton (Swift)を参照してください。

ユーザーがアプリを開いて位置情報ボタンを初めてタップしたとき、システムは標準的なアラートを表示します。このアラートは、ボタンを使用することで、アプリによる位置情報へのアクセスがどのように制限されるかを理解してもらうためのもので、共有開始時に表示される位置情報インジケーターを思い出してもらいます。

人々は、ボタンの動作を理解していることを確認した後、あなたのアプリに自分の位置情報へのアクセスを 1 回だけ許可したいときに、位置情報ボタンをタップするだけです。1 回限りの許可は、ユーザーがアプリの使用をやめると失効しますが、ボタンの動作に対する理解を再度確認する必要はありません。

位置情報ボタンを使用して、特定のアプリの機能のために位置情報を共有する簡単な方法を提供することを検討してください 例えば、メッセージや投稿に位置情報を添付したり、お店を探したり、その場所で出会った建物や植物、動物を特定したりすることができます。人々がアプリの Allow Once 許可を頻繁に与えていることがわかっている場合は、位置情報ボタンを使用して、アラートに反応しなくても位置情報を共有することで利益を得られるようにすることを検討してください。

位置情報ボタンは、UI と調和するようにカスタマイズしてください 具体的には、以下のことができます。

“Current Location” や “Share My Current Location” など、機能に合わせてシステムが提供するタイトルを選択する
位置情報のグリフを塗りつぶしたものか、アウトライン化したものかを選択する
背景色、タイトルとグリフの色を選択する
ボタンのコーナー半径を調整する

位置情報ボタンを認知・信頼してもらうために、他の属性はカスタマイズできないようになっています。このシステムでは、コントラストの低い色の組み合わせや半透明の多さなどの問題を警告することで、ロケーションボタンの読みやすさを確保しています。このような問題を修正するだけでなく、ボタンにテキストが収まるようにする責任もあります。たとえば、ボタンのテキストは、すべてのアクセシビリティのテキストサイズで、また他の言語に翻訳されたときにも、切り捨てられることなく収まるようにする必要があります。

重要

カスタマイズした位置情報ボタンに一貫した問題があることがシステムによって確認された場合、人々がボタンをタップしても、アプリケーションはデバイスの位置情報にアクセスできません。このようなボタンは、アプリ固有の他のアクションを実行できますが、位置情報ボタンが期待通りに動作しないと、人々はアプリに対する信頼を失う可能性があります。

ShazamKit アプリでのマイクロフォンの使用について #

ShazamKit は、オーディオサンプルを ShazamKit カタログまたはカスタムオーディオカタログと照合することで、音声認識を可能にします。iOS 15 以降では、アプリが ShazamKit を使用して次のような機能を実現できます。

再生中の音楽のジャンルに対応したグラフィックでアプリケーション体験を向上させる
音声と同期したクローズドキャプションや手話を提供することで、聴覚障がい者がメディアコンテンツにアクセスできるようにする
オンライン学習や小売業などで、アプリ内の体験をバーチャルコンテンツと同期させる

アプリが認識する音声サンプルを得るためにデバイスのマイクが必要な場合は、そのアクセスを要求する必要があります。他のタイプの許可申請と同様に、なぜアクセスを求めるのかを理解してもらうことが重要です。ガイダンスについては、「アクセス許可の申請」を参照してください。

ShazamKit が有効になっている機能のマイクにアクセスする許可を得た後は、以下のガイドラインに従ってください。

できるだけ早く録音を停止してください 認識のためにあなたのアプリケーションが音声を録音することを許可するとき、人々はマイクがオンのままであることを期待していません。プライバシーを守るために、必要なサンプルを得るために必要な時間だけ録音してください。

認識した曲を iCloud ライブラリに保存するかどうか、ユーザーに選択させる アプリが認識した曲を iCloud に保存できる場合は、ユーザーがこのアクションを最初に承認する方法を提供します。音楽認識コントロールと Shazam アプリの両方で、認識された曲のソースとしてあなたのアプリが表示されますが、どのアプリが自分のライブラリにコンテンツを保存できるかをコントロールできることを人々は高く評価します。

開発者向けのガイダンスについては、ShazamKit を参照してください。

警告の前にカスタムメッセージを表示する #

理想的には、ユーザーは文脈に基づいて許可を求める理由をすでに知っていますが、追加の詳細を提供することが不可欠な場合は、アラートが表示される前にカスタムメッセージを表示できます。

カスタムメッセージ画面では、システムアラートを開くことが人々の唯一の行動であることを明確にしてください 人々はプレアラートメッセージを遅延戦術と解釈する可能性があるため、メッセージをすぐに消去してシステムアラートを表示させることが重要です。プライバシー関連の許可要求の前にカスタム画面を表示する場合は、1 つのアクションのみを提供し、システムアラートを表示しなければなりません。アクションのタイトルには「続行」のような言葉を使い、「許可」など、カスタム画面内で許可を与えたり他のアクションを実行していると思わせるような言葉は使わないでください。

トラッキングリクエストの明確化 #

アプリのトラッキングはデリケートな問題です。場合によっては、トラッキングの利点を明確に説明するカスタムメッセージを表示することが理にかなっていることもあります。

システムが提供するアラートの前に、人々を混乱させたり誤解させたりするようなカスタムメッセージを表示しないでください 人はアラートを読まずに素早くタップして消してしまうことがあります。このような行動を利用して選択に影響を与えるようなカスタムメッセージ画面は、App Store Review で却下される可能性があります。

拒否される原因となるカスタムメッセージのデザインには、いくつかの禁止事項があります。例えば、インセンティブを提供すること、リクエストのような画面を表示すること、アラートの画像を表示すること、アラートの後ろの画面に注釈を入れることなどです（下図）。ガイダンスについては、App Store Review Guidelines を参照してください。5.1.1 (iv)を参照してください。

App architecture - settings #

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/settings/

設定 #

アプリの中には、設定や構成を選択する方法を提供する必要があるものもありますが、ほとんどのアプリでは、設定を行わないようにしたり、遅らせたりすることができます。成功するアプリは、多くの人がすぐに使いこなせると同時に、便利な調整方法を提供しています。多くの人が期待する機能を持つようにアプリを設計すると、設定の必要性が減ります。

システムから得られる情報を推測する ユーザー、デバイス、環境に関する情報が必要な場合は、ユーザーに尋ねるのではなく、可能な限りシステムに問い合わせてください。例えば、地域の選択肢を提示するために郵便番号を入力してもらう代わりに、現在地を使用する許可を得る。ユーザーが自分の情報へのアクセスを拒否した場合は、潔く手動入力に戻します。

アプリ内の設定オプションの優先順位を考慮する アプリのメイン画面には、必須のオプションや頻繁に変更されるオプションを配置するとよいでしょう。たまにしか変更されないオプションには、二次画面が適しています。

頻繁に変更されない設定オプションは、「設定」で公開します 「設定」アプリは、システム全体の構成を変更するための中心的な場所ですが、そこに行くにはアプリを離れる必要があります。アプリ内で直接設定を変更する方がはるかに便利です。めったに変更する必要のない設定を提供する必要がある場合は、開発者向けのガイダンスとして、Preferences and Settings Programming Guide の Implementing an iOS Settings Bundle を参照してください。

必要に応じて「設定」へのショートカットを提供します アプリに、「設定 > MyApp > プライバシー > 位置情報サービスに移動」など、ユーザーを「設定」に誘導するテキストが含まれている場合は、その場所を自動的に開くボタンを用意します。開発者向けのガイダンスとしては、UIApplication の openSettingsURLString を参照してください。