読み方

日本人はまず日本語で読むのが早いでしょ...英語で頑張って読まないで。という思いのもと、日本語訳をDeepL先生に訳してもらったものを掲載していきます。日本語がおかしいと思ったところは英語で読めるように英語も記載しておきます。基本的に日本語だけ読めばOK

後ほど図もこちらに差し込みます（いいねしておいてもらえば後で見返せるように。少々お待ちを。）

2021年12月現在のiOSのHuman Interface Guidlineの翻訳になります。

iOSデザインテーマ

アプリデザイナーには、App Storeのランキングで上位に食い込むような、優れた製品を提供するチャンスがあります。そのためには、品質と機能に対する高い期待に応えなければなりません。

iOSは、3つの主要なテーマによって他のプラットフォームと差別化されています。

わかりやすさ。システム全体を通して、テキストはどのサイズでも読みやすく、アイコンは正確かつ明瞭に、装飾は控えめかつ適切に、そして機能性を重視したシャープなデザインが動機となっています。ネガティブスペース、カラー、フォント、グラフィック、インターフェイスの各要素は、重要なコンテンツをさりげなく強調し、インタラクティビティを伝えています。

ディファレンス流麗な動きと鮮明で美しいインターフェイスは、人々がコンテンツを理解し、交流するのに役立つ一方で、決してコンテンツと競合することはありません。コンテンツは通常、画面いっぱいに表示されますが、半透明やぼかしによって、より多くのコンテンツを暗示することができます。ベゼル、グラデーション、ドロップシャドウを最小限に抑えることで、コンテンツを最優先しながらも、軽快で風通しのよいインターフェイスを実現しています。

奥行き。明確な視覚層とリアルな動きは、階層を表現し、活力を与え、理解を促します。また、タッチ操作や発見しやすさによって、コンテキストを失うことなく機能やコンテンツにアクセスすることができます。トランジションは、コンテンツをナビゲートする際に、奥行きを感じさせます。

iOS Design Themes

As an app designer, you have the opportunity to deliver an extraordinary product that rises to the top of the App Store charts. To do so, you'll need to meet high expectations for quality and functionality.

Three primary themes differentiate iOS from other platforms:

Clarity. Throughout the system, text is legible at every size, icons are precise and lucid, adornments are subtle and appropriate, and a sharpened focus on functionality motivates the design. Negative space, color, fonts, graphics, and interface elements subtly highlight important content and convey interactivity.

Deference. Fluid motion and a crisp, beautiful interface help people understand and interact with content while never competing with it. Content typically fills the entire screen, while translucency and blurring often hint at more. Minimal use of bezels, gradients, and drop shadows keep the interface light and airy, while ensuring that content is paramount.

Depth. Distinct visual layers and realistic motion convey hierarchy, impart vitality, and facilitate understanding. Touch and discoverability heighten delight and enable access to functionality and additional content without losing context. Transitions provide a sense of depth as you navigate through content.

デザインの原則

インパクトとリーチを最大化するために、以下の原則を念頭に置いて、アプリのアイデンティティを想像してください。

Design Principles
To maximize impact and reach, keep the following principles in mind as you imagine your app’s identity.

美的完全性

アプリの外観や動作が、その機能といかにうまく融合しているかを表すのが「美的完成度」です。たとえば、真剣な作業を支援するアプリは、控えめで控えめなグラフィック、標準的な操作、予測可能な動作を使用することで、人々の集中力を維持することができます。一方、ゲームなどの没入型アプリでは、楽しさと興奮を約束する魅力的な外観を実現し、発見を促します。

Aesthetic Integrity
Aesthetic integrity represents how well an app’s appearance and behavior integrate with its function. For example, an app that helps people perform a serious task can keep them focused by using subtle, unobtrusive graphics, standard controls, and predictable behaviors. On the other hand, an immersive app, such as a game, can deliver a captivating appearance that promises fun and excitement, while encouraging discovery.

一貫性

一貫性のあるアプリは、システムが提供するインターフェース要素、よく知られたアイコン、標準的なテキストスタイル、統一された用語などを使用し、慣れ親しんだ標準やパラダイムを実装しています。このアプリは、人々が期待する方法で機能や動作を組み込んでいます。

Consistency
A consistent app implements familiar standards and paradigms by using system-provided interface elements, well-known icons, standard text styles, and uniform terminology. The app incorporates features and behaviors in ways people expect.

直接操作

画面上のコンテンツを直接操作することで、人々の興味を引き、理解を促します。デバイスを回転させたり、ジェスチャーを使って画面上のコンテンツに影響を与えることで、ユーザーは直接的な操作を経験することができます。このような直接的な操作により、ユーザーは自分の行動の結果をすぐに目にすることができます。

Direct Manipulation
The direct manipulation of onscreen content engages people and facilitates understanding. Users experience direct manipulation when they rotate the device or use gestures to affect onscreen content. Through direct manipulation, they can see the immediate, visible results of their actions.

フィードバック

フィードバックは、行動を認め、結果を示し、人々に情報を提供するものです。iOSに内蔵されたアプリケーションは、ユーザーのあらゆるアクションに反応して、目に見える形でフィードバックを提供します。インタラクティブな要素をタップすると短くハイライト表示され、長く続く操作の状況をプログレスインジケーターで伝え、アニメーションとサウンドで操作の結果を明確にします。

Feedback
Feedback acknowledges actions and shows results to keep people informed. The built-in iOS apps provide perceptible feedback in response to every user action. Interactive elements are highlighted briefly when tapped, progress indicators communicate the status of long-running operations, and animation and sound help clarify the results of actions.

メタファー

アプリのバーチャルなオブジェクトやアクションが、現実世界やデジタル世界に根ざした身近な体験のメタファーであれば、人はより早く学習することができます。iOSでは、人々が物理的にスクリーンとインタラクトするため、メタファーがうまく機能します。ビューを邪魔にならないように動かして、下にあるコンテンツを露出させます。コンテンツをドラッグしたりスワイプしたりします。スイッチを切り替えたり、スライダーを動かしたり、ピッカー値をスクロールしたりします。本や雑誌のページをめくることさえあります。

Metaphors
People learn more quickly when an app’s virtual objects and actions are metaphors for familiar experiences—whether rooted in the real or digital world. Metaphors work well in iOS because people physically interact with the screen. They move views out of the way to expose content beneath. They drag and swipe content. They toggle switches, move sliders, and scroll through picker values. They even flick through pages of books and magazines.

ユーザーコントロール

iOSでは、アプリではなく人がコントロールします。アプリは行動を提案したり、危険な結果を警告することはできますが、意思決定をアプリに委ねることは通常、誤りです。最高のアプリケーションは、ユーザーを支援することと、望ましくない結果を回避することのバランスをうまく取っています。アプリは、インタラクティブな要素を身近で予測可能なものに保ち、破壊的な行動を確認し、すでに進行中の操作を簡単にキャンセルできるようにすることで、人々が自分がコントロールしているように感じられるようにすることができます。

User Control
Throughout iOS, people—not apps—are in control. An app can suggest a course of action or warn about dangerous consequences, but it’s usually a mistake for the app to take over the decision-making. The best apps find the correct balance between enabling users and avoiding unwanted outcomes. An app can make people feel like they’re in control by keeping interactive elements familiar and predictable, confirming destructive actions, and making it easy to cancel operations, even when they’re already underway.

インターフェイスの要点

ほとんどのiOSアプリは、共通のインターフェース要素を定義したプログラミングフレームワークであるUIKitのコンポーネントを使って作られています。このフレームワークにより、アプリケーションはシステム全体で一貫した外観を実現すると同時に、高度なカスタマイズ性を提供することができます。UIKitの要素は、柔軟で親しみやすいものです。また、システムが外観を変更すると、自動的に更新されます。UIKitが提供するインターフェイス要素は、主に3つのカテゴリに分類されます。

バー。アプリ内の位置を示し、ナビゲーションを提供し、アクションを開始したり情報を伝えたりするためのボタンやその他の要素を含むことができます。

ビュー。テキスト、グラフィック、アニメーション、インタラクティブ要素など、アプリで表示される主要なコンテンツが含まれます。ビューでは、スクロール、挿入、削除、配置などの動作が可能です。

コントロール。アクションを開始したり、情報を伝達したりします。ボタン、スイッチ、テキストフィールド、進捗インジケータなどがコントロールの例です。

UIKit は、iOS のインターフェイスを定義するだけでなく、アプリケーションが採用できる機能も定義しています。たとえば、このフレームワークを通じて、アプリケーションはタッチスクリーン上のジェスチャーに反応し、描画、アクセシビリティ、印刷などの機能を有効にすることができます。

iOSは、Apple Pay、HealthKit、ResearchKitなど、他のプログラミングフレームワークやテクノロジーとも密接に統合されているので、驚くほどパワフルなアプリケーションを設計することができます。

Interface Essentials
Most iOS apps are built using components from UIKit, a programming framework that defines common interface elements. This framework lets apps achieve a consistent appearance across the system, while at the same time offering a high level of customization. UIKit elements are flexible and familiar. They’re adaptable, enabling you to design a single app that looks great on any iOS device, and they automatically update when the system introduces appearance changes. The interface elements provided by UIKit fit into three main categories:

Bars. Tell people where they are in your app, provide navigation, and may contain buttons or other elements for initiating actions and communicating information.

Views. Contain the primary content people see in your app, such as text, graphics, animations, and interactive elements. Views can enable behaviors such as scrolling, insertion, deletion, and arrangement.

Controls. Initiate actions and convey information. Buttons, switches, text fields, and progress indicators are examples of controls.

In addition to defining the interface of iOS, UIKit defines functionality your app can adopt. Through this framework, for example, your app can respond to gestures on the touchscreen and enable features such as drawing, accessibility, and printing.

iOS tightly integrates with other programming frameworks and technologies too, such as Apple Pay, HealthKit, and ResearchKit, enabling you to design amazingly powerful apps.

ローンチ

起動時の体験は、アプリに対する人々の印象に大きな影響を与えます。使用するデバイスや最後にアプリを開いてからの時間に関係なく、起動時の体験は迅速かつシームレスであるべきです。

以下のガイドラインは、快適な起動エクスペリエンスを設計するために役立ちます。開発者のためのガイダンスについては、「アプリの起動時の対応」を参照してください。

起動画面を用意する。システムは、アプリの起動と同時に起動画面を表示し、すぐにアプリの最初の画面に置き換えます。起動画面の機能は、アプリが高速で応答性が高いという印象を人々に与え、同時に初期コンテンツの読み込みを可能にすることです。起動画面からシームレスに移行するために、アプリの最初の画面に似たプレーンな画面を設計し、それ自体に注目されないようにします。ガイダンスについては、「起動画面」を参照してください。

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

設定情報を前もって要求するのは避けましょう。人々は、アプリがただ動くことを期待しています。大多数のユーザーのためにアプリを設計し、異なる設定を希望する少数のユーザーには、そのニーズに合わせて設定を調整してもらいましょう。可能な限り、デバイスの設定やデフォルト、または同期ソフトウェアから設定情報を取得します。

Launching
The launch experience has a significant impact on the way people feel about your app. Regardless of the device people are using or how long it's been since they last opened your app, the launch experience should be fast and seamless.

The guidelines below can help you design a delightful launch experience. For developer guidance, see Responding to the Launch of Your App.

Provide a launch screen. The system displays your launch screen the moment your app starts and quickly replaces it with your app's first screen. The function of a launch screen is to give people the impression that your app is fast and responsive, while allowing initial content to load. To ensure a seamless transition from your launch screen, design a plain screen that resembles your first app screen and doesn't draw attention to itself. For guidance, see Launch Screen.

Launch in the appropriate orientation. If your app supports both portrait and landscape modes, it should launch using the device’s current orientation. If your app only runs in one orientation, it should always launch in that orientation and let people rotate the device if necessary. Unless there’s a compelling reason not to, an app in landscape mode should orient itself correctly, regardless of whether the device was rotated left or right. For guidance, see Adaptivity and Layout.

Avoid asking for setup information up front. People expect apps to just work. Design your app for the majority of users and let the few that want a different configuration adjust settings to meet their needs. As much as possible, get setup information from device settings and defaults, or through a synchronization s

オンボーディング

オンボーディングは、新しいユーザーを歓迎し、リピーターと再びつながることができます。素早く、楽しく、教育的なオンボーディングエクスペリエンスをオプションで用意すれば、ユーザーの邪魔になることなく、アプリを最大限に活用することができます。

Translateアプリの新機能画面のスクリーンショット。新機能や重要な機能が説明されており、「続ける」というタイトルのボタンがあります。
アプリをセットアップするだけでなく、アプリを楽しんでもらうためのオンボーディングを提供する。人々は、あなたのアプリについてもっと学ぶ機会をありがたく思いますが、ただ機能することも期待しています。オンボーディング・エクスペリエンスにセットアップやライセンスの詳細を含めないようにしましょう。ガイダンスについては、「起動」を参照してください。

アクションをすばやく開始する。システムが起動画面をアプリの初期画面に置き換えたら、ユーザーはすぐにアプリに飛び込んで、楽しみ始めることができます。チュートリアルやイントロシーケンスを提供する必要がある場合は、それらをスキップする方法を提供し、人々が戻ってきたときに自動的にそれらを表示しないようにします。

ヘルプが必要な場合を想定する。人々が行き詰まる可能性があることを積極的に探します。例えば、ゲームが一時停止しているときや、キャラクターが進んでいないときに、役立つヒントをさりげなく表示することができます。チュートリアルを繰り返し遊んでもらうことで、初見でわからないことがあっても安心です。

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

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

Onboarding
Onboarding lets you welcome new users and reconnect with returning ones. An optional onboarding experience that’s fast, fun, and educational can help people get the most from your app without getting in their way.

Screenshot of the Translate app’s What’s New screen, which describes new and important features and includes a filled button titled Continue.
Provide onboarding that helps people enjoy your app, not just set it up. People can appreciate the opportunity to learn more about your app, but they also expect it to just work. Avoid including setup or licensing details in your onboarding experience. For guidance, see Launching.

Get to the action quickly. After the system replaces your launch screen with your initial app screen, let people dive right in and start enjoying your app. If you need to provide tutorials or intro sequences, give people a way to skip them and don’t automatically show them when people return.

Anticipate the need for help. Proactively look for times when people might be stuck. A game, for example, could casually show useful tips when paused or when a character isn’t advancing. Let people replay tutorials in case they miss something the first time.

Stick to the essentials in tutorials. It’s fine to provide guidance for beginners, but education isn’t a substitute for great app design. First and foremost, make your app intuitive. If people seem to need too much guidance, revisit the design of your app.

Make learning fun and discoverable. Learning by doing is a lot more fun and effective than reading a list of instructions. Use animation and interactivity to teach gradually and in context. Avoid displaying static screenshots that appear interactive.

ローディング

コンテンツの読み込み中に空白や静止画面があると、アプリがフリーズしているように見え、混乱とフラストレーションを招き、アプリを離れる原因になる可能性があります。

楽曲をダウンロード中のダウンロード画面の一部です。曲名とアーティストの下に表示されたプログレスバーは、ダウンロードが約75%完了したことを示し、プログレスバーの下のテキストには、1.0GBのうち758MBと表示されています。

読み込み中であることを明確にする。最低でもアクティビティ・スピナーを表示し、何かが起こっていることを伝える。さらに、待ち時間がわかるように、進行状況を明示するのもよいでしょう。

コンテンツはできるだけ早く表示する。コンテンツがロードされるのを待たせて、期待通りの画面が表示されないようなことは避けましょう。すぐに画面を表示し、コンテンツがまだない場所にはプレースホルダーのテキスト、グラフィック、アニメーションを使用します。コンテンツが読み込まれたら、これらのプレースホルダーを置き換える。可能な限り、アニメーションの再生中やユーザーがレベルやメニューを操作している間など、バックグラウンドで今後のコンテンツをあらかじめロードしておく。

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

ローディング画面をカスタマイズする。標準的な進行状況インジケータは通常問題ありませんが、時には文脈から外れているように感じられることがあります。アプリやゲームのスタイルに合ったカスタムアニメーションやエレメントを使用して、より没入感のあるエクスペリエンスをデザインすることを検討してください。

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

Loading
When content is loading, a blank or static screen can make it seem like your app is frozen, resulting in confusion and frustration, and potentially causing people to leave your app.

Partial screenshot of a Downloads screen in which a song is downloading. A progress bar displayed below the song title and artist shows that the download is about 75% complete and text below the progress bar states 758 MB of 1.0 GB.

Make it clear when loading is occurring. At minimum, show an activity spinner that communicates something is happening. Even better, display explicit progress so people can gauge how long they’ll be waiting.

Show content as soon as possible. Don’t make people wait for content to load before seeing the screen they're expecting. Show the screen immediately, and use placeholder text, graphics, or animations to identify where content isn't available yet. Replace these placeholder elements as the content loads. Whenever possible, preload upcoming content in the background, such as while an animation is playing or the user is navigating a level or menu.

Educate or entertain people to mask loading time. Consider showing hints about gameplay, entertaining video sequences, or interesting placeholder graphics.

Customize loading screens. Although standard progress indicators are usually OK, they can sometimes feel out of context. Consider designing a more immersive experience through custom animations and elements that match the style of your app or game.

For additional guidance, see Progress Indicators.

モダリティ

モダリティとは、コンテンツを一時的に表示し、終了するために明示的なアクションを必要とするデザイン手法のことである。モダリティを利用することで、以下のことが可能になります。

自己完結したタスク、または密接に関連した一連のオプションに集中できるようにする
重要な情報を確実に受け取り、必要であれば行動に移すことができる。

システムで定義されたさまざまなモーダルエクスペリエンスを実現するために、iOS はアラート、アクティビティビュー、シェアシート、アクションシートを提供しています。アプリでカスタムモーダルコンテンツを表示するには、次のプレゼンテーションスタイルのいずれかを使用します。

自動。デフォルトのプレゼンテーションスタイル（通常はシート）を使用します。
フルスクリーン。前のビューを覆い、閉じるためのボタンが必要です。
ポップオーバー。横長環境ではポップオーバーを、コンパクト環境ではシートを表示します。
ページシートとフォームシート。前のビューを部分的にカバーします。ガイダンスについては、「シート」を参照してください。
現在のコンテキスト。特定の前のビューをカバーします。
カスタム。カスタムのコンテナでコンテンツを表示するために、カスタムのアニメーションを使用します。
開発者のためのガイダンスについては、UIModalPresentationStyle を参照してください。

注意
現在のコンテキストモーダルビュースタイルを使用して、モーダルコンテンツを分割ビューペイン、ポップオーバー、またはフルスクリーンでないその他のビュー内に表示する場合、モーダルコンテンツをコンパクトな環境で表示するときは、シートの使用に切り替えてください。

モーダルは、意味のあるときに使用します。モーダルエクスペリエンスを作成するのは、現在のタスクとは異なる選択またはタスクの実行に人々の注意を集中させることが重要な場合だけにしてください。モーダルエクスペリエンスは、人々を現在のコンテキストから引き離し、解除するためのアクションを必要とするため、明確な利益をもたらす場合にのみ使用することが肝要です。

アラートは、必要不可欠な、そして理想的には実用的な情報の配信に限定してください。一般的に、アラートが表示されるのは、何か問題が発生したときです。アラートは現在の体験を中断させ、タップして解除する必要があるため、その中断が正当であると人々に感じてもらうことが重要です。詳しくは、「アラート」をご覧ください。

一般に、モーダルタスクは、シンプルで短く、焦点を絞ったものにします。モーダルタスクが複雑すぎると、モーダルコンテキストに入ったときに中断したタスクを見失ってしまうことがあります。アプリの中にアプリがあるようなモーダルエクスペリエンスを作成しないように注意してください。特に、モーダルタスクの中でビューの階層を表示すると、元のタスクへの戻り方を忘れてしまうことがあるので、注意が必要です。モーダルタスクにサブビューを含める必要がある場合、階層を通る単一のパスと、完了までの明確なパスを提供します。タスクの完了以外の目的で [完了] ボタンを使用しないようにします。

没入感のあるコンテンツや複雑なタスクには、フルスクリーンモーダルスタイルの使用を検討してください。フルスクリーンモーダルでは、気が散るのを最小限に抑えられるので、動画、写真、カメラビューを表示したり、文書のマークアップや写真の編集などの複数ステップのタスクを実行したりするのに適しています。

モーダル表示を解除するボタンを必ず配置します。たとえば、Done や Cancel を使用することができます。ボタンを含めることで、モーダルビューを支援技術で確実に利用できるようになり、解除のジェスチャーに代わる方法が提供されます。

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

モーダルビューのタスクを簡単に識別できるようにする。ユーザーは、モーダルビューに入ると、それまでのコンテキストから切り替わり、すぐには戻れないかもしれません。モーダルビューのタスク名を示すタイトル、またはタスクの説明やガイダンスを示す追加テキストを提供すると、ユーザーがアプリ内で自分の位置を維持しやすくなります。

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

アプリで意味のあるモーダル遷移スタイルを選択します。アプリと協調し、一時的なコンテキストシフトの認識を高める遷移スタイルを使用します。デフォルトのトランジションは、モーダルビューを画面の下から上にスライドさせ、終了すると下に戻すものです。アプリ全体で一貫したモーダル遷移スタイルを使用します。

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

Modality
Modality is a design technique that presents content in a temporary mode that requires an explicit action to exit. Presenting content modally can:

Help people focus on a self-contained task or set of closely related options
Ensure that people receive critical information and, if necessary, act on it

To enable various system-defined modal experiences, iOS provides alerts, activity views, share sheets, and action sheets. To present custom modal content in your app, you can use one of the following presentation styles.

Automatic. Uses the default presentation style, typically a sheet.
Fullscreen. Covers the previous view, and requires a button for dismissal.
Popover. Presents a popover in a horizontally regular environment and a sheet in compact environments.
Page sheet and form sheet. Partially covers the previous view; for guidance, see Sheets.
Current context. Covers a particular previous view.
Custom. Uses custom animation to present content in a custom container.
For developer guidance, see UIModalPresentationStyle.

NOTE
If you use the current context modal view style to display modal content within a split view pane, popover, or other view that isn’t fullscreen, switch to using a sheet when presenting modal content in a compact environment.

Use modality when it makes sense. Create a modal experience only when it’s critical to focus people’s attention on making a choice or performing a task that’s different from their current task. A modal experience takes people out of their current context and requires an action to dismiss, so it’s essential to use it only when it provides a clear benefit.

Reserve alerts for delivering essential — and ideally actionable — information. Typically, an alert appears because something has gone wrong. Because an alert interrupts the current experience and requires a tap to dismiss, it’s important for people to feel that the intrusion is warranted. For guidance, see Alerts.

In general, keep modal tasks simple, short, and narrowly focused. If a modal task is too complicated, people can lose sight of the task they suspended when they entered the modal context. Take care to avoid creating a modal experience that feels like an app within your app. In particular, be wary of presenting a hierarchy of views within a modal task, because people can forget how to retrace their steps to their original task. If a modal task must contain subviews, provide a single path through the hierarchy and a clear path to completion. Avoid using a Done button for anything other than completing the task.

Consider using a fullscreen modal style for immersive content or a complex task. A fullscreen modal experience minimizes distractions, so it can work well for presenting videos, photos, or camera views, or to enable a multistep task like marking up a document or editing a photo.

Always include a button that dismisses the modal view. For example, you might use Done or Cancel. Including a button ensures that the modal view is accessible to assistive technologies and provides an alternative to dismissal gestures.

When necessary, help people avoid data loss by getting confirmation before closing a modal view. Regardless of whether people use a dismiss gesture or a button to close the view, if the action could result in the loss of user-generated content, present an action sheet that explains the situation and gives people ways to resolve it.

Make it easy to identify a modal view’s task. When people enter a modal view, they switch away from their previous context and might not return to it right away. When you provide a title that names the modal view’s task — or additional text that describes the task or provides guidance — you can help people keep their place in your app.

Coordinate the modal view’s appearance with your app. For example, when a modal view includes a navigation bar, it should use the same appearance as the navigation bar in your app.

Choose a modal transition style that makes sense in your app. Use a transition style that coordinates with your app and enhances the awareness of the temporary context shift. The default transition vertically slides the modal view up from the bottom of the screen and back down when it’s dismissed. Use consistent modal transition styles throughout your app.

For developer guidance, see UIViewController and UIPresentationController.

アプリのナビゲーションは、期待に沿えないものであった場合に初めて意識される傾向があります。あなたの仕事は、それ自体に注目することなく、アプリの構造と目的をサポートするような方法でナビゲーションを実装することです。ナビゲーションは、自然で親しみやすいものでなければならず、インターフェイスを支配したり、コンテンツからフォーカスをそらしたりするものであってはなりません。iOSでは、3つの主なナビゲーションのスタイルがあります。

階層型ナビゲーション
目的地に着くまで、1画面につき1つの選択をする。別の目的地に行くには、歩みをたどるか、最初からやり直し、別の選択をしなければなりません。設定」や「メール」などがこのスタイルです。

7つの正方形が階層的につながっている図。一番上の正方形は、その下の列に表示されている3つの正方形とつながっています。2行目の左端のマスは、3行目の残りの3つのマスにつながっています。

フラットナビゲーション
複数のコンテンツカテゴリーを切り替えることができます。ミュージックとApp Storeがこのナビゲーションスタイルを採用しています。

1列に4つのマス、その下に残りの4つのマスが並ぶ8つのマスを示した図。1列目の1マス目は、1列目の2マス目と双頭の矢印でつながっています。同じように、2番目のマスは3番目のマスに、3番目のマスは4番目のマスに接続する。1列目の各マスは、2列目のその下のマスと片頭の矢印でつながっている。

コンテンツ駆動型ナビゲーションとエクスペリエンス駆動型ナビゲーション
コンテンツの中を自由に移動する、あるいはコンテンツそのものがナビゲーションを定義している。ゲーム、書籍、その他の没入型アプリは、一般的にこのナビゲーションスタイルを採用しています。

9つの円を片頭の矢印でつないだ図。1つの円にしかつながらない円もあれば、複数の円につながる円もあります。この図は、9つの場所の集合を通過するランダムな経路を示唆しています。

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

常に明確な経路を提供する。ユーザーは、アプリのどこにいて、どのように次の目的地に行くかを常に知っている必要があります。ナビゲーションのスタイルにかかわらず、コンテンツを通過する経路が論理的で、予測可能で、簡単にたどれることが重要です。一般に、各画面への経路は1つにします。1つの画面を複数のコンテキストで表示する必要がある場合は、アクションシート、アラート、ポップオーバー、モーダルビューの使用を検討してください。詳しくは、アクションシート、アラート、ポップオーバー、モーダル表示をご覧ください。

コンテンツにすばやく簡単にアクセスできる情報構造を設計する。タップ、スワイプ、スクリーンの数が最小限になるように、情報構造を整理します。

タッチジェスチャーを使用して、流動性を生み出します。摩擦を最小限に抑え、インターフェイス内を簡単に移動できるようにします。例えば、画面の横からスワイプして前の画面に戻ることができるようにします。

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

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

タブバーを使用して、コンテンツや機能のピアカテゴリーを表示します。タブバーを使用すると、現在の場所に関係なく、すばやく簡単にカテゴリーを切り替えることができます。具体的な方法は、タブバーを参照してください。

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

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

Navigation
People tend to be unaware of an app’s navigation until it doesn’t meet their expectations. Your job is to implement navigation in a way that supports the structure and purpose of your app without calling attention to itself. Navigation should feel natural and familiar, and shouldn’t dominate the interface or draw focus away from content. In iOS, there are three main styles of navigation.

Hierarchical Navigation
Make one choice per screen until you reach a destination. To go to another destination, you must retrace your steps or start over from the beginning and make different choices. Settings and Mail use this navigation style.

Diagram that shows seven squares connected in a hierarchy. The top square connects to three squares shown on a row below it. The leftmost square on the second row connects to the three remaining squares shown on a third row.

Flat Navigation
Switch between multiple content categories. Music and App Store use this navigation style.

Diagram that shows eight squares, with four squares in one row and the remaining four squares in a row below it. The first square in the first row connects to the second square in the first row with a double-headed arrow. In the same way, the second square connects to the third square and the third square connects to the fourth square. Each square in the first row uses a single-headed arrow to connect to the square below it in the second row.

Content-Driven or Experience-Driven Navigation
Move freely through content, or the content itself defines the navigation. Games, books, and other immersive apps generally use this navigation style.

Diagram that shows nine circles that are connected by single-headed arrows. Some circles connect to exactly one other circle and other circles connect to more than one other circle. The diagram suggests a random path through a set of nine locations.

Some apps combine multiple navigation styles. For example, an app that uses flat navigation may implement hierarchical navigation within each category.

Always provide a clear path. People should always know where they are in your app and how to get to their next destination. Regardless of navigation style, it’s essential that the path through content is logical, predictable, and easy to follow. In general, give people one path to each screen. If they need to see a screen in multiple contexts, consider using an action sheet, alert, popover, or modal view. To learn more, see Action Sheets, Alerts, Popovers, and Modality.

Design an information structure that makes it fast and easy to get to content. Organize your information structure in a way that requires a minimum number of taps, swipes, and screens.

Use touch gestures to create fluidity. Make it easy to move through your interface with minimum friction. For example, you could let people swipe from the side of the screen to return to the previous screen.

Use standard navigation components. Whenever possible, use standard navigation controls such as page controls, tab bars, segmented controls, table views, collection views, and split views. Users are already familiar with these controls, and will intuitively know how to get around your app.

Use a navigation bar to traverse a hierarchy of data. The navigation bar’s title can show the current position in the hierarchy, and the back button makes it easy to return to the previous location. For specific guidance, see Navigation Bars.

Use a tab bar to present peer categories of content or functionality. A tab bar lets people quickly and easily switch between categories, regardless of the current location. For specific guidance, see Tab Bars.

On iPad, use a split view instead of a tab bar. Split views provide the same quick navigation as tab bars while making better use of the large display. For guidance, see Split Views.

Use a page control when you have multiple pages of the same type of content. A page control clearly communicates the number of pages available and which one is currently active. The Weather app uses a page control to show location-specific weather pages. For specific guidance, see Page Controls.

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

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

位置情報、健康情報、財務情報、連絡先、その他の個人を特定できる情報を含む個人データ
電子メール、メッセージ、カレンダーデータ、連絡先、ゲームプレイ情報、Apple Musicアクティビティ、HomeKitデータ、オーディオ、ビデオ、写真コンテンツなどのユーザーが作成したコンテンツ
Bluetooth周辺機器、ホームオートメーション機能、Wi-Fi接続、ローカルネットワークなどの保護されたリソース
カメラやマイクなどのデバイスの機能
重要事項
iOS 14.5およびiPadOS 14.5以降、ユーザーを追跡したり、デバイスの広告識別子にアクセスする場合は、AppTrackingTransparencyフレームワークを使用してユーザーの許可を要求する必要があります。詳しくは、「ユーザのプライバシーとデータの使用」をご覧ください。

新規または更新されたアプリケーションを提出する場合、App Storeが製品ページに情報を表示できるように、お客様のプライバシー慣行および収集するプライバシー関連データについて詳細を提供する必要があります。(お客様は、App Store Connectでいつでもこの情報を管理できます）人々は、お客様のアプリケーションをダウンロードする前に、製品ページのプライバシーに関する詳細を参考にして、十分な情報を得た上で意思決定します。詳しくは、App Storeのアプリのプライバシーの詳細を参照してください。

アプリのApp Store商品ページの「App Privacy（アプリのプライバシー）」画面のスクリーンショット。画面の一番上のカードは、「Data Used to Track You」と題され、連絡先、場所、識別子が記載されています。下のカードは「Data Linked to You」と題され、財務情報、連絡先情報、位置情報、購入履歴、識別子、閲覧履歴がリストアップされています。
アプリケーションのApp Storeの製品ページでは、アプリケーションをダウンロードする前に、そのアプリケーションのプライバシー慣行を理解することができます。

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

アプリがデータやリソースへのアクセスを明らかに必要とする場合にのみ、許可を求めてください。個人情報やデバイスの機能へのアクセスを要求されると、特にその必要性が明らかでない場合は、不審に思うのは当然です。理想的には、アクセスを必要とするアプリの機能を実際に使用するまで、許可を要求するのを待つことです。位置情報のリクエストについては、位置情報ボタンを使用することで、位置情報をその場で共有する方法を提供できます。

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

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

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

目的の文字列の例備考
緑色の丸の中に白色のチェックが入っているのが、正しい例であることを示します。このアプリは、夜間に録音していびき音を検出するものです。アプリがデータを収集する方法と理由を明確に説明するアクティブセンテンスです。
灰色の丸の中に白の×印があり、誤った例であることを示しています。より良い体験のためには、マイクの使用が必要です。曖昧で未定義の正当性を示す受動文。
グレーの丸の中に白い×印があり、不正確な例であることを示しています。マイク接続をオンにする。正当な理由を示さない命令文。

以下は、標準的なシステムアラートのいくつかの例です。

例1

例2

例3
Pal Aboutアプリの許可アラートのスクリーンショットで、「Pal Aboutがあなたの位置情報にアクセスすることを許可しますか」という目的の文字列が表示されています。位置情報サービスをオンにすると、パルが近くにいるときに表示することができます'と表示されています。文字列の下には、Precise Onの通知を含む小さなマップ画像があり、マップの下には3つのボタンが重なっています。ボタンは上から順に、「一度だけ許可」「アプリ使用中に許可」「許可しない」となっています。
位置情報ボタンの使い方
iOS 15以降では、Core Locationは、タスクが必要とする瞬間に、位置情報にアクセスする一時的な権限をアプリに付与できるようにするためのボタンを提供します。位置情報ボタンの外観は、以下のようにさまざまです。

Accessing User Data and Resources
User privacy is paramount. To help people trust your app, it’s crucial to be transparent about the privacy-related data and resources you require and how you use them. For example, you must request permission to access:

Personal data, including location, health, financial, contact, and other personally identifying information
User-generated content like emails, messages, calendar data, contacts, gameplay information, Apple Music activity, HomeKit data, and audio, video, and photo content
Protected resources like Bluetooth peripherals, home automation features, Wi-Fi connections, and local networks
Device capabilities like camera and microphone
IMPORTANT
Beginning in iOS 14.5 and iPadOS 14.5, you must use the AppTrackingTransparency framework to request the user’s permission if you want to track them or access their device’s advertising identifier. To learn more, see User Privacy and Data Use.

When you submit a new or updated app, you must provide details about your privacy practices and the privacy-relevant data you collect so the App Store can display the information on your product page. (You can manage this information at any time in App Store Connect.) People use the privacy details on your product page to make an informed decision before they download your app. To learn more, see App privacy details on the App Store.

Screenshot of the App Privacy screen in an app’s App Store product page. The top card in the screen is titled ’Data Used to Track You’ and lists contact info, location, and identifiers. The bottom card is titled ’Data Linked to You’ and lists financial and contact info, location, purchases, identifiers, and browsing history.
An app’s App Store product page helps people understand the app’s privacy practices before they download it.

Requesting Access Permission
Before you can use user data or protected resources, you must get people’s permission to do so.

Request permission only when your app clearly needs access to the data or resource. It’s natural for people to be suspicious of a request for personal information or access to a device capability, especially if there’s no obvious need for it. Ideally, wait to request permission until people actually use an app feature that requires access. For location requests, using the location button lets you give people an in-the-moment way to share their location; for guidance, see Using the Location Button.

Request permission at launch only when the data or resource is necessary for your app to function. People are less likely to be bothered by a launch-time request when it’s obvious why your app needs the information. If you want to perform app tracking as soon as people launch your app, you must display the system-provided alert before you collect any tracking data.

The system provides a standard alert that lets people view your request to access their private information or protected resources. You supply a description of why your app needs the items, and the system displays this description in the alert. People can also view your description — and update their choice — in Settings > Privacy.

Write copy that clearly describes how your app uses the data or resource you’re requesting. The standard alert displays your copy (called a purpose string or usage description string) after your app name and before the buttons people use to grant or deny their permission. Aim for a brief, complete sentence that’s straightforward, specific, and easy to understand. Use sentence case, avoid passive voice, and include a period at the end. For developer guidance, see Requesting Access to Protected Resources and App Tracking Transparency.

Example purpose string Notes
White check in a green circle to indicate a correct example. The app records during the night to detect snoring sounds. An active sentence that clearly describes how and why the app collects the data.
White X in a gray circle to indicate an incorrect example. Microphone access is needed for a better experience. A passive sentence that provides a vague, undefined justification.
White X in a gray circle to indicate an incorrect example. Turn on microphone access. An imperative sentence that doesn’t provide any justification.

Here are several examples of the standard system alert:

Example 1

Example 2

Example 3
Screenshot of a permission alert for the Pal About app displaying a purpose string that reads ’Allow Pal About to access your location? Turning on location services allows us to show you when pals are nearby.’ Below the string is a small map image containing the Precise On notice and below the map are three buttons in a stack. From the top, the buttons are titled Allow Once, Allow While Using App, and Don’t Allow.
Using the Location Button
In iOS 15 and later, Core Location provides a button so people can grant your app temporary authorization to access their location at the moment a task needs it. Although a location button’s appearance can vary to match your app’s UI, it always communicates the action of location sharing in a way that’s instantly recognizable.

Image of a lozenge-shaped blue button that displays a white location indicator — that is, a narrow arrow head shape that points to the top right — followed by the text Current Location.

The location button grants your app temporary authorization to request the device location. If your app has no authorization status, tapping the location button has the same effect as when a person chooses Allow Once in the standard alert. If people previously chose While Using the App, tapping the location button doesn’t change your app’s status. For developer guidance, see LocationButton (SwiftUI) and CLLocationButton (Swift).

The first time people open your app and tap a location button, the system displays a standard alert. The alert helps people understand how using the button limits your app’s access to their location, and reminds them of the location indicator that appears when sharing starts.

Screenshot of the alert displayed by the location button that appears on top of a background image showing a partial map of the Western Hemisphere. The alert reads ’Park Finder can only access your location when you choose to share it. When you share your location with this app, a blue location indicator will appear in the status bar.’ Below this text the alert displays a small image of the map, zoomed in to show part of Cupertino. Below the map are two buttons; from the top the titles are OK and Not Now.
After people confirm their understanding of the button’s action, they simply tap the location button when they want to give your app one-time permission to access their location. Although each one-time authorization expires when people stop using your app, they don’t need to reconfirm their understanding of the button’s behavior.

Consider using the location button to give people a lightweight way to share their location for specific app features. For example, your app might help people attach their location to a message or post, find a store, or identify a building, plant, or animal they’ve encountered in their location. If you know that people often grant your app Allow Once permission, consider using the location button to help them benefit from sharing their location without having to interact with the alert.

Consider customizing the location button to harmonize with your UI. Specifically, you can:

Choose the system-provided title that works best with your feature, such as “Current Location” or “Share My Current Location”
Choose the filled or outlined location glyph
Select a background color and a color for the title and glyph
Adjust the button’s corner radius
To help people recognize and trust location buttons, other visual attributes aren't customizable. The system also ensures a location button remains legible by warning you about problems like low-contrast color combinations or too much translucency. In addition to fixing such problems, you're responsible for making sure the text fits in the button — for example, button text should fit without truncation at all accessibility text sizes and when translated into other languages.

IMPORTANT
If the system identifies consistent problems with your customized location button, it won’t give your app access to the device location when people tap it. Although such a button can perform other app-specific actions, people may lose trust in your app if your location button doesn’t work as they expect.

Using the Microphone in a ShazamKit App
ShazamKit enables audio recognition by matching an audio sample against the ShazamKit catalog or a custom audio catalog. In iOS 15 and later, apps can use ShazamKit to enable features like:

Enhancing app experiences with graphics that correspond with the genre of currently playing music
Making media content accessible to people with hearing disabilities by providing closed captions or sign language that syncs with the audio
Synchronizing in-app experiences with virtual content in contexts like online learning and retail
If you need the device microphone to get audio samples for your app to recognize, you must request access to it. As with all types of permission requests, it’s important to help people understand why you’re asking for access; for guidance, see Requesting Access Permission.

After you receive permission to access the microphone for features that have ShazamKit enabled, follow these guidelines.

Stop recording as soon as possible. When people allow your app to record audio for recognition, they don’t expect the microphone to stay on. To help preserve privacy, only record for as long as it takes to get the sample you need.

Let people opt in to storing your app’s recognized songs to their iCloud library. If your app can store recognized songs to iCloud, give people a way to first approve this action. Even though both the Music Recognition control and the Shazam app show your app as the source of the recognized song, people appreciate having control over which apps can store content in their library.

For developer guidance, see ShazamKit.

Displaying Custom Messaging Before the Alert
Ideally, people already know why you’re requesting their permission based on context, but if it’s essential to provide additional details, you can display a custom message before the alert appears.

Make it clear that opening the system alert is the only action people can take in your custom-messaging screen. People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like "Continue" to title the action; don’t use "Allow" or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.

Screenshot of an app’s pre-alert screen that reads ’Allow tracking on the next screen for special offers and promotions just for you, advertisements that match your interests, an improved personalized experience over time. You can change this option later in the Settings app.’ Below the text is a button titled Continue.
White check in a green circle to indicate a correct example.

Screenshot of the Pal About app’s pre-alert screen that reads ’Turning on location services allows us to provide features like: Alerts when your pals are nearby, news of events happening near you, tagging and sharing your location.’ Below the text is a button titled Continue and below the button is the text ’You can change this later in the Settings app.
White check in a green circle to indicate a correct example.

Clarifying Tracking Requests
App tracking is a sensitive issue. In some cases, it might make sense to display custom messaging that clearly describes the benefits of tracking.

Never precede the system-provided alert with custom messaging that could confuse or mislead people. People sometimes tap quickly to dismiss alerts without reading them. A custom messaging screen that takes advantage of such behaviors to influence choices will lead to rejection by App Store Review.

There are several prohibited custom-messaging designs that will cause rejection. Some examples are offering incentives, displaying a screen that looks like a request, displaying an image of the alert, and annotating the screen behind the alert (shown below). For guidance, see App Store Review Guidelines: 5.1.1 (iv).

設定方法

アプリによっては、設定や構成を選択する方法を提供する必要があるかもしれませんが、ほとんどのアプリは、それを回避したり、遅らせたりすることができます。成功するアプリは、多くの人にとってすぐに使えると同時に、使い勝手を調整する方法もいくつか提供しています。多くの人が期待するようにアプリを設計すれば、設定の必要性は低くなります。

天気予報を表示するアプリのスクリーンショット。ナビゲーションバーの右端に設定アイコンがある。
システムから推測できることは推測する。ユーザー、デバイス、環境に関する情報が必要な場合、ユーザーに尋ねる代わりに、可能な限りシステムに問い合わせます。たとえば、地域情報を表示するために郵便番号を入力するようユーザーに求める代わりに、現在地を使用する許可を求めます。ユーザーが自分の情報へのアクセスを拒否した場合は、手動入力に潔く戻る。

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

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

アプリの設定画面のスクリーンショット。
適切な場合は、設定へのショートカットを提供します。アプリに「Go to Settings > MyApp > Privacy > Location Services」のようにユーザを設定に誘導するテキストが含まれている場合、その場所を自動的に開くボタンを提供します。開発者のためのガイダンスについては、UIApplicationのopenSettingsURLStringを参照してください。

Settings
Some apps may need to provide a way to make setup or configuration choices, but most apps can avoid or delay doing so. Successful apps work well for most people right away, while also offering some convenient ways to adjust the experience. When you design your app to function the way most people expect, you decrease the need for settings.

Screenshot of an app that displays weather forecasts. A settings icon is in the right end of the navigation bar.
Infer what you can from the system. If you need information about the user, device, or environment, query the system for it whenever possible instead of asking the user. For example, instead of asking someone to enter their zip code so you can present local options, ask permission to use their current location. Gracefully fall back to manual entry if the user denies access to their information.

Thoughtfully prioritize configuration options within your app. Your app’s main screen is a good place for options that are essential or that change frequently. Secondary screens are better for options that change only occasionally.

Expose infrequently changed configuration options in Settings. The Settings app is a central location for making configuration changes throughout the system, but people must leave your app to get there. It’s far more convenient to adjust settings directly within your app. If you must provide settings that rarely require change, see Implementing an iOS Settings Bundle in Preferences and Settings Programming Guide for developer guidance.

Screenshot of an app's settings screen.
Provide shortcuts to Settings when appropriate. If your app includes text that directs users to Settings, such as “Go to Settings > MyApp > Privacy > Location Services,” provide a button that opens that location automatically. For developer guidance, see openSettingsURLString in UIApplication.

参照

2021年12月 iOS Human Interface Guidlineの翻訳版 vol.1

読み方