【Human Interface Guidelines 翻訳 vol.2】iOS - Mac Catalyst

下記ページの翻訳です。

https://developer.apple.com/design/human-interface-guidelines/ios/overview/mac-catalyst/

Mac Catalyst

When you use Mac Catalyst to create a Mac version of your iPad app, you make your app available to a new audience while giving existing users the opportunity to enjoy it in a new environment.

Mac Catalystを使用してiPadアプリのMacバージョンを作成すると、新しいユーザーがアプリを利用できるようになると同時に、既存のユーザーが新しい環境でアプリを楽しむことができます。

For developer guidance, see Creating a Mac Version of Your iPad App.

開発者向けガイダンスについては、iPadバージョンのMacバージョンの作成を参照してください。

Before You Start（始める前に）

Most iPad apps are great candidates for adaptation, but some rely on iPad features that don’t exist on a Mac. For example, if your app’s essential features require iPad capabilities like gyroscope, accelerometer, or rear camera, iOS frameworks like HealthKit or ARKit, or the app’s main function is something like navigation, it might not be suited for the Mac.

ほとんどのiPadアプリは適応の優れた候補ですが、Macには存在しないiPad機能に依存しているアプリもあります。
たとえば、アプリの重要な機能にジャイロスコープ、加速度計、背面カメラなどのiPad機能が必要な場合、HealthKitやARKitなどのiOSフレームワーク、またはアプリの主な機能がナビなどである場合、Macには適さない可能性があります。

For apps that don’t require iPad-only features, the best way to ensure that your app will work well on a Mac is to make sure it works well on iPad. In particular, your app should:

iPadのみの機能を必要としないアプリの場合、アプリがMacで適切に機能することを保証する最善の方法は、iPadで正しく機能することを確認することです。
特に、アプリは次の条件を満たす必要があります。

• Support multitasking. Apps that do a good job scaling the interface to support Split View, Slide Over, and Picture in Picture approach the ultimate goal of supporting the extensive window resizability that Mac users expect.
• Support drag and drop. When you support drag and drop in your iPad app, you get the same support on the Mac for free.
• Respond to keyboard shortcuts, including common macOS shortcuts. Even though a keyboard may not always be available to your iPad app, both iOS and macOS users appreciate using keyboard shortcuts to streamline their interaction with your app.

• マルチタスクをサポートすること。
  分割表示、スライドオーバー、ピクチャインピクチャをサポートするようにインターフェイスのスケーリングを適切に調整するアプリは、Macユーザーが期待する広範なウィンドウのサイズ変更をサポートするという最終目標に近づきます。
• ドラッグアンドドロップをサポートすること。
  iPadアプリでドラッグアンドドロップをサポートすると、Macでも同じサポートが無料で受けられます。
• 一般的なmacOSショートカットを含むキーボードショートカットに応答すること。
  キーボードがiPadアプリで常に利用できるとは限りませんが、iOSとmacOSの両方のユーザーは、キーボードショートカットを使用してアプリとの対話を効率化することを高く評価しています。

Plan Enhancements for Your Mac App（Macアプリの機能強化を計画する）

When you use Mac Catalyst to create a Mac version of your iPad app, you get automatic support for fundamental Mac features, such as:

Mac Catalystを使用してiPadアプリのMacバージョンを作成すると、次のような基本的なMac機能が自動的にサポートされます。

• System Preferences
• Keyboard, trackpad, mouse, and Touch Bar input, including key focus and keyboard navigation
• Window management
• Rich text interaction, including copy and paste and contextual menus for editing
• File management

• システム環境設定
• キーボード、トラックパッド、マウス、およびタッチバー入力（キーフォーカスとキーボードナビゲーションを含む）
• ウィンドウ管理
• コピーと貼り付け、編集用のコンテキストメニューを含むリッチテキストの操作
• ファイル管理

In addition, many system-provided UI elements automatically convert from iOS to macOS. For example, you get macOS-appropriate versions of the following iOS-provided items:

さらに、システムが提供する多くのUI要素は、iOSからmacOSに自動的に変換されます。たとえば、iOSが提供する次のアイテムのmacOSに適したバージョンを取得します。

• Split view
• File browser
• Activity view
• Form sheet
• Contextual actions

• 分割ビュー
• ファイルブラウザ
• アクティビティビュー
• フォームシート
• コンテキストアクション

To ensure that your app gives people a rich Mac experience, it’s essential to enhance this foundation and go beyond simply displaying your iOS UI in a macOS window. Before you dive in and update specific views and controls, become familiar with the main differences between the platforms so that you can create an app that feels at home on the Mac. (For comprehensive design guidance for macOS apps, see macOS Human Interface Guidelines.)

アプリがMacに豊かなエクスペリエンスを確実に提供するためには、この基盤を強化し、iOS UIを単にmacOSウィンドウに表示するだけでは不十分です。
特定のビューやコントロールに飛び込んでアップデートする前に、プラットフォーム間の主な違いを理解して、Macでくつろげるアプリを作成できるようにします。
（macOSアプリの包括的な設計ガイダンスについては、macOSヒューマンインターフェイスガイドラインを参照してください。）

iOS and macOS each define design patterns and conventions for user interaction that are rooted in the different ways people use their devices. For example, iOS conventions such as swipe to delete, action sheet commands, and controls at the bottom of the screen are optimized for touch interactions on a handheld device. In a similar way, macOS conventions such as dedicated keys and keyboard shortcuts, menu commands, and controls at the top of the window are optimized for keyboard, mouse, and trackpad interactions and a separate display.

iOSとmacOSはそれぞれ、ユーザーがデバイスを使用するさまざまな方法に根ざしたユーザーインタラクションのデザインパターンと規則を定義します。
たとえば、スワイプによる削除、アクションシートのコマンド、画面下部のコントロールなどのiOSの規則は、ハンドヘルドデバイス（持ち運びしやすい小型の端末）でのタッチ操作用に最適化されています。
同様に、ウィンドウ上部の専用キーとキーボードショートカット、メニューコマンド、コントロールなどのmacOSの規則は、キーボード、マウス、トラックパッドの操作と個別のディスプレイ用に最適化されています。

The conventions and design patterns that have the biggest impact on adaptation can be grouped into four key areas.

適応に最大の影響を与える規則と設計パターンは、4つの主要な領域にグループ化できます。

Navigation. Many iOS and macOS apps organize data in similar ways, but they use different controls and visual indicators to help people understand and navigate through the data. For specific guidance, see Adopt macOS App Structure and Navigation Conventions.

ナビゲーション。多くのiOSおよびmacOSアプリは、同様の方法でデータを整理しますが、さまざまなコントロールと視覚的なインジケーターを使用して、ユーザーがデータを理解し、ナビゲートできるようにします。
具体的なガイダンスについては、「macOSアプリの構造とナビゲーション規則の採用」を参照してください。

User input and interactions. Although both iPad and Mac accept user input from a range of devices — such as the Multi-Touch display, keyboard, mouse, and trackpad — touch interactions inform iOS conventions, whereas keyboard and mouse interactions originated the conventions for macOS. For related guidance, see Support macOS User Interactions.

ユーザー入力とインタラクション。 iPadとMacはどちらも、マルチタッチディスプレイ、キーボード、マウス、トラックパッドなどのさまざまなデバイスからのユーザー入力を受け入れます。
タッチ操作はiOSの規則を通知しますが、キーボードとマウスの操作はmacOSの規則を元にしています。
関連するガイダンスについては、「macOSユーザーインタラクションのサポート」を参照してください。

Menus. Mac users are familiar with the persistent menu bar and expect to find all app commands in menu bar menus. iOS, on the other hand, doesn’t have a persistent menu bar, and iOS users expect to find app commands in the app’s UI. For related guidance, see Put App Commands into Menus.

メニュー。 Macユーザーは永続的なメニューバーに精通しており、すべてのアプリコマンドがメニューバーメニューにあることを期待しています。
一方、iOSには永続的なメニューバーがなく、iOSユーザーはアプリのUIでアプリコマンドを見つけることを期待しています。
関連するガイダンスについては、「アプリコマンドをメニューに配置する」を参照してください。

Content scaling. Text in the macOS version of an iPad app looks the same as it does in iOS because SF fonts are available on both platforms. However, the baseline font size in iOS is 17 pt, whereas the most common font size in macOS is 13 pt. To ensure that your text and interface elements are consistent with the macOS display environment, iOS views automatically scale down to 77%. For related guidance, see Typography.

コンテンツのスケーリング。 iPadアプリのmacOSバージョンのテキストは、iOSの場合と同じように見えます。
これは、SFフォントが両方のプラットフォームで利用できるためです。
ただし、iOSのベースラインフォントサイズは17 ptですが、macOSの最も一般的なフォントサイズは13 ptです。
テキストおよびインターフェイス要素がmacOSディスプレイ環境と一致することを保証するために、iOSビューは自動的に77％に縮小されます。
関連するガイダンスについては、「タイポグラフィ」を参照してください。

In addition to adopting macOS interaction and design conventions, you need to update your visual design and layout to take advantage of the wider Mac screen in ways that give macOS users a great experience. For example, you might:

macOSの相互作用と設計規則を採用することに加えて、macOSユーザーに優れたエクスペリエンスを提供する方法でより広いMac画面を利用するには、ビジュアルデザインとレイアウトを更新する必要があります。たとえば、次のようにします。

• Divide a single column of content and actions into multiple columns
• Present an inspector UI next to the main content instead of within a popover
• Simultaneously show two or more levels of an app’s hierarchy

For more guidance, see Visual Design Considerations.

• コンテンツとアクションの単一の列を複数の列に分割する
• ポップオーバー内ではなく、メインコンテンツの横にインスペクターUIを表示する
• アプリの階層の2つ以上のレベルを同時に表示する

詳細については、「ビジュアルデザインの考慮事項」を参照してください。

Ideally, viewing your iPad app from the perspective of macOS design conventions can suggest ways to improve the iOS version, too. Although you want to make sure that each version remains true to the conventions of its platform, take this opportunity to revisit the design of your original app. Especially if your iPad app originated on iPhone, consider reassessing the ways you lay out views and controls to see if there are places where you can make better use of the large iPad screen.

理想的には、macOS設計規則の観点からiPadアプリを表示することで、iOSバージョンを改善する方法も提案できます。
各バージョンがプラットフォームの規則に忠実であることを確認したい場合は、この機会に元のアプリの設計を再確認してください。
特に、iPadアプリがiPhoneで作成された場合は、ビューとコントロールのレイアウト方法を見直して、大きなiPad画面をより有効に活用できる場所があるかどうかを確認してください。

Adopt macOS App Structure and Navigation Conventions（macOSアプリの構造とナビゲーション規則を採用する）

Well-designed app navigation reflects the structure of the data and supports the main purpose of the app in ways that follow the platform’s conventions. To help macOS users feel at home in your app, you need to translate the iOS navigation conventions to the equivalent macOS conventions.

適切に設計されたアプリナビゲーションは、データの構造を反映し、プラットフォームの規則に従う方法でアプリの主な目的をサポートします。
macOSユーザーがアプリでくつろげるようにするには、iOSナビゲーション規則を同等のmacOS規則に変換する必要があります。

Most iPad apps use either flat or hierarchical navigation, and some use a combination of both. Flat navigation presents areas of functionality or categories of data as peer groups that are always available. For example, Music and App Store use flat navigation to give people persistent access to high-level areas such as Library, For You, Browse, Today, and Games. Hierarchical navigation presents information in a tree-like organization through which people navigate by choosing one item per view until they reach their destination. In Settings, for example, people can customize text replacements by choosing General > Keyboards > Text Replacement.

ほとんどのiPadアプリはフラットナビゲーションまたは階層ナビゲーションのいずれかを使用し、一部は両方の組み合わせを使用します。
フラットナビゲーションは、機能の領域またはデータのカテゴリを、常に利用可能なピアグループとして表示します。
たとえば、ミュージックおよびApp Storeはフラットナビゲーションを使用して、ライブラリ、おすすめ、閲覧、Today、ゲームなどの高レベルの領域への永続的なアクセスを提供します。
階層型ナビゲーションは、ツリー状の組織で情報を提示します。
目的地に到達するまで、ビューごとに1つのアイテムを選択することにより、ユーザーはその中を移動します。
たとえば、[設定]で、[一般]> [キーボード]> [テキストの置換]を選択して、テキストの置換をカスタマイズできます。

Typically, iPad apps use the following UIKit controls to implement navigation:

• Tab bar. A tab bar supports flat navigation by displaying top-level categories in a persistent bar at the bottom of the screen.
• Page control. A page control displays dots at the bottom of the screen that indicate the position of the current page in a flat list of pages.
• Split view. A split view enables hierarchical navigation by presenting items and functionality in a primary view (also called a master view) and a secondary view (also called a detail view). When people select an item in the primary view, a split view displays the content associated with that item in the secondary view.

通常、iPadアプリは次のUIKitコントロールを使用してナビゲーションを実装します。

• タブバー。タブバーは、画面下部の固定バーにトップレベルのカテゴリを表示することにより、フラットナビゲーションをサポートしています。
• ページコントロール。ページコントロールは、画面の下部に、ページのフラットリスト内の現在のページの位置を示すドットを表示します。
• 分割ビュー。分割ビューでは、アイテムと機能をプライマリビュー（マスタービューとも呼ばれます）およびセカンダリビュー（詳細ビューとも呼ばれます）に表示することにより、階層的なナビゲーションが可能です。

If you use a tab bar in your iPad app, consider using a segmented control or the sidebar background style in a split view controller. Both items are similar to navigation conventions in Mac-style windows. To choose between these items, consider the following:

iPadアプリでタブバーを使用する場合は、分割ビューコントローラーでセグメント化されたコントロールまたはサイドバーの背景スタイルを使用することを検討してください。
どちらの項目も、Macスタイルのウィンドウのナビゲーション規則に似ています。
これらの項目から選択するには、以下を考慮してください。

• A segmented control and a tab bar both accommodate similar interactions — such as mutually exclusive selection — so a segmented control is a good alternative for a straightforward adaptation. A segmented control is ideal for iPad apps that don’t have a lot of hierarchy within each tab, because it can be paired with a sidebar to enable navigation within a tab.
• A sidebar displays a list of top-level items, each of which can disclose a list of child items. Using a sidebar streamlines navigation because you can let people view each tab’s contents within the sidebar. Sidebars are a good choice for displaying app-defined or user-defined categories that don’t change very often. For example, the Following and Suggested categories in the News sidebar don’t change, even though people can change the items listed in each category.

• セグメント化されたコントロールとタブバーはどちらも、相互に排他的な選択などの同様の相互作用に対応しているため、セグメント化されたコントロールは、直接的な適応に適した代替手段です。
  セグメント化されたコントロールは、サイドバーと組み合わせてタブ内でのナビゲーションを可能にすることができるため、各タブ内に多くの階層を持たないiPadアプリに最適です。

• サイドバーにはトップレベルのアイテムのリストが表示され、各アイテムは子アイテムのリストを開示できます。
  サイドバーを使用すると、サイドバー内の各タブのコンテンツを表示できるため、ナビゲーションが合理化されます。
  サイドバーは、頻繁に変更されないアプリ定義またはユーザー定義のカテゴリを表示するのに適しています。
  たとえば、人々は各カテゴリにリストされているアイテムを変更できますが、ニュースサイドバーの[フォロー中]および[おすすめ]カテゴリは変更されません。

You can also combine a segmented control and a sidebar in your app. For example, you might use a segmented control to contain the tabs, and a sidebar to display the contents of each tab. Regardless of how you adapt the tab bar, be sure to give people quick access to each tab’s content through the macOS View menu. To learn more about menus, see Put App Commands into Menus.

また、セグメント化されたコントロールとサイドバーをアプリで組み合わせることができます。
たとえば、セグメント化されたコントロールを使用してタブを含めたり、サイドバーを使用して各タブのコンテンツを表示したりできます。
タブバーの調整方法に関係なく、必ずmacOSの[表示]メニューから各タブのコンテンツにすばやくアクセスできるようにしてください。
メニューの詳細については、「アプリコマンドをメニューに配置する」を参照してください。

If you use a split view in your iPad app, macOS automatically translates it to a split view in the Mac version of your app. On both platforms, a master view is a good choice for presenting a list of items that can vary — such as the list of mailboxes in Mail — because it lets you include labels and icons and it supports sorting and filtering. However, if your content hierarchy is deeper than two levels, the middle levels between the master view and the current detail view aren’t visible in the Mac-style window. To ensure that people can retrace their steps, include a back button in the toolbar.

iPadアプリで分割ビューを使用すると、macOSはそれをMacバージョンのアプリの分割ビューに自動的に変換します。
どちらのプラットフォームでも、マスタービューはラベルやアイコンを含めたり、並べ替えやフィルタリングをサポートしたりできるので、Mailのメールボックスのリストなど、変化する可能性のあるアイテムのリストを表示するのに適しています。
ただし、コンテンツ階層が2レベルより深い場合、マスタービューと現在の詳細ビューの間の中間レベルは、Macスタイルのウィンドウには表示されません。
人々が自分の手順をたどることができるようにするには、ツールバーに戻るボタンを含めます。

If you use a page control, or another way to enable lateral navigation, give people specific controls to view pages. If you support this type of lateral navigation, you can help people navigate through pages in your Mac-style window by displaying a Next/Previous button in the toolbar and adding navigation commands to a menu bar menu. For example, Stocks in macOS displays both a Back button in the toolbar and Next Story and Previous Story commands in the View menu.

ページコントロール、または横方向のナビゲーションを有効にする別の方法を使用する場合は、ページを表示するための特定のコントロールを提供します。
このタイプのラテラルナビゲーションをサポートしている場合、ツールバーに[次へ] / [前へ]ボタンを表示し、メニューバーメニューにナビゲーションコマンドを追加することで、Macスタイルのウィンドウでページ間を移動できるようにすることができます。
たとえば、macOSの「株価」は、ツールバーの[戻る]ボタンと、[表示]メニューの[次のストーリー]および[前のストーリー]コマンドの両方を表示します。

If you support multiple windows in your iPad app, you get support for multiple windows in the macOS version, too. In addition, many macOS apps let people open documents or other content in a new tab instead of in a new window. For example, people can open a different webpage per tab in a Safari window or a different file system location per tab in a Finder window. When people use System Preferences to prefer tabs over windows, the system dynamically adds the relevant menu items to an app’s menus, such as View > Show Tab Bar and Window > Show Next Tab.

iPadアプリで複数のウィンドウをサポートしている場合、macOSバージョンでも複数のウィンドウがサポートされます。
さらに、多くのmacOSアプリでは、ドキュメントやその他のコンテンツを新しいウィンドウではなく新しいタブで開くことができます。
たとえば、Safariウィンドウのタブごとに異なるWebページを開いたり、Finderウィンドウのタブごとに異なるファイルシステムの場所を開くことができます。
ユーザーがシステム設定を使用してウィンドウよりもタブを優先する場合、システムは関連するメニュー項目を動的にアプリのメニューに追加します。
たとえば、[表示]> [タブバーを表示]や[ウィンドウ]> [次のタブを表示]などです。

Support macOS User Interactions（macOSユーザーインタラクションのサポート）

Selection persistence is a fundamental difference in user interaction between iOS and macOS. Because many macOS users expect to control apps and the system using only the keyboard, the selected state of objects must persist so that people can use one sequence of key presses to select an object and a second sequence to act upon it. In contrast, iOS users expect to act upon an object without selecting it first, so objects don’t need to retain their selected state. As a general rule, iOS apps don’t tend to be optimized for keyboard interactions.

選択の永続性は、iOSとmacOSの間のユーザー操作の根本的な違いです。
多くのmacOSユーザーはキーボードのみを使用してアプリとシステムを制御することを期待しているため、オブジェクトの選択された状態を維持して、人々が1回のキーシーケンスを使用してオブジェクトを選択し、2番目のシーケンスでそれを操作できるようにする必要があります。
対照的に、iOSユーザーはオブジェクトを最初に選択せずに操作することを期待しているため、オブジェクトは選択された状態を保持する必要はありません。原則として、iOSアプリはキーボード操作用に最適化される傾向はありません。

Here are some ways that different interaction conventions can affect the user experience:

さまざまな相互作用規則がユーザーエクスペリエンスに影響を与える可能性があるいくつかの方法を次に示します。

• macOS users often want Next and Previous buttons in place of iPad or trackpad gestures such as swiping among pages.
• On a Mac, people expect to use the Delete key or select a Delete command in a menu, so displaying a Delete button in the UI is usually unnecessary.
• iOS users are accustomed to pulling down on a view to refresh the contents. In contrast, Mac users expect to use a menu command, such as Check for New Content.

• macOSユーザーは、iPadやページ間のスワイプなどのトラックパッドジェスチャーの代わりに、[次へ]ボタンと[前へ]ボタンを必要とすることがよくあります。
• Macでは、Deleteキーを使用するか、メニューで[削除]コマンドを選択することを期待しているため、UIに[削除]ボタンを表示する必要は通常ありません。
• iOSユーザーは、ビューをプルダウンしてコンテンツを更新するのに慣れています。対照的に、Macユーザーは、[新しいコンテンツの確認]などのメニューコマンドを使用することを期待しています。

As you translate iPad user interaction patterns to Mac interactions, focus on letting people manipulate objects in ways that adhere to platform conventions.

iPadのユーザーインタラクションパターンをMacのインタラクションに変換するときは、プラットフォームの規則に準拠した方法でオブジェクトを操作できるようにすることに焦点を当てます。

Keyboard Input（キーボード入力）

Be prepared to support keyboard conventions that let people change a persistent selection by using arrow keys or by pressing letter and number keys.

矢印キーを使用するか、文字と数字キーを押すことで、永続的な選択を変更できるキーボードの規則をサポートする準備をしてください。

If it makes sense in your app, take advantage of the fact that Mac users can easily use the keyboard and the mouse or trackpad at the same time.

アプリでそれが理にかなっている場合は、Macユーザーがキーボードとマウスまたはトラックパッドを同時に簡単に使用できるという事実を利用してください。

If you implement UIKeyCommand in your iPad app to define keyboard sequences for commands, the macOS version of your app translates these shortcuts to the menus. For example, you should map each major view area, such as each tab, to the keyboard shortcuts ⌘1, ⌘2, and so on for display in the View menu of the macOS version of your app.

iPadアプリにUIKeyCommandを実装してコマンドのキーボードシーケンスを定義する場合、アプリのmacOSバージョンはこれらのショートカットをメニューに変換します。
たとえば、アプリのmacOSバージョンの[表示]メニューに表示するには、各タブなどの各主要ビュー領域をキーボードショートカット⌘1、⌘2などにマップする必要があります。

If there’s a Delete button in the UI of your iPad app, consider removing it from the macOS version and letting people use the Delete key or the app’s Edit > Delete menu command instead.

iPadアプリのUIに[削除]ボタンがある場合は、macOSバージョンから削除して、代わりにDeleteキーまたはアプリの[編集]> [削除]メニューコマンドを使用できるようにすることを検討してください。

Gestures（ジェスチャー）

When your iPad app runs in macOS, most gestures convert automatically. For example:

iPadアプリをmacOSで実行すると、ほとんどのジェスチャーが自動的に変換されます。
例えば：

iPad gesture（iPadジェスチャー）	Translates to mouse interaction（マウス操作に変換）
Tap（タップ）	Left or right click（左または右クリック）
Touch and hold（押し続ける）	Click and hold（クリックしてホールド）
Pan（パン）	Left click and drag（左クリックしてドラッグ）

iPad gesture（iPadジェスチャー）	Translates to mouse interaction（トラックパッドのジェスチャーに変換）
Tap（タップ）	click（クリック）
Touch and hold（押し続ける）	Click and hold（クリックしてホールド）
Pan（パン）	click and drag（クリックしてドラッグ）
Pinch（ピンチ）	Pinch（ピンチ）
Rotate（回転）	Rotate（回転）

DEVELOPER NOTE
The two touches in the pinch and rotate gestures get sent to the view under the pointer, not the view under each touch.

開発者ノート

ピンチジェスチャと回転ジェスチャの2つのタッチは、各タッチのビューではなく、ポインタの下のビューに送信されます。

Put App Commands into Menus（アプリコマンドをメニューに配置する）

On a Mac, the menu bar at the top of the screen gives people a consistent location for commands that control both apps and the system. The menu bar contains the standard and custom menus supplied by the current app, in addition to the Apple menu, which lists system-level commands that are always available. Mac users expect every macOS app to make all its commands available in the menu bar.

Macでは、画面の上部にあるメニューバーを使用して、アプリとシステムの両方を制御するコマンドを一貫した場所に配置できます。
メニューバーには、現在利用可能なアプリによって提供される標準メニューとカスタムメニュー、および常に使用可能なシステムレベルのコマンドが一覧表示されるアップルメニューが含まれています。
Macユーザーは、すべてのmacOSアプリがすべてのコマンドをメニューバーで使用できるようにすることを期待しています。

DEVELOPER NOTE
You must use UICommand to represent each command in your iPad app so that these commands can be put into macOS menu bar menus. To support keyboard shortcuts for commands, use UIKeyCommand.

開発者ノート

これらのコマンドをmacOSメニューバーメニューに配置できるように、UICommandを使用してiPadアプリの各コマンドを表す必要があります。
コマンドのキーボードショートカットをサポートするには、UIKeyCommandを使用します。

Because iPad apps use controls to display commands in the main UI, finding a logical and intuitive menu bar location for every app command is a key part of the adaptation process.

iPadアプリはコントロールを使用してメインUIにコマンドを表示するため、すべてのアプリコマンドの論理的で直感的なメニューバーの場所を見つけることは、適応プロセスの重要な部分です。

To design the menu bar menus for the macOS version of your app, start by listing all the actions that people can perform and grouping them into the categories defined by the standard menu bar menus. For example:

アプリのmacOSバージョンのメニューバーメニューを設計するには、まず、ユーザーが実行できるすべてのアクションを一覧表示し、標準のメニューバーメニューで定義されているカテゴリにグループ化します。
例えば：

• App Name
• File
• Edit
• View
• Window
• Help

• アプリ名
• ファイル
• 編集
• 表示
• ウィンドウ
• ヘルプ

NOTE
Most macOS apps include a View menu and a Window menu. Although these menus may seem similar, they have different purposes. People use the View menu to customize the appearance of app windows and to move among different functional areas, whereas they use the Window menu to navigate, organize, and manage the collection of windows in an app. To learn more, see Menu Bar Menus.

注意

ほとんどのmacOSアプリには、表示メニューとウィンドウメニューがあります。これらのメニューは似ているように見えるかもしれませんが、目的は異なります。
ユーザーは[表示]メニューを使用してアプリウィンドウの外観をカスタマイズし、さまざまな機能領域間を移動しますが、[ウィンドウ]メニューを使用して、アプリ内のウィンドウのコレクションを移動、整理、および管理します。
詳細については、メニューバーメニューを参照してください。

If some of the actions on your list don’t make sense in the standard menu bar menus, you might need to add a custom menu. Mac apps often add a custom menu bar menu for commands that are associated with either a core app object or a core app workflow. For example, Mail in macOS uses the Message and Mailbox menus to list commands that operate on these fundamental app objects. In contrast, Keynote uses the Arrange menu to list commands associated with the core workflow of arranging objects in a slide deck.

リストの一部のアクションが標準のメニューバーメニューでは意味をなさない場合は、カスタムメニューを追加する必要があるかもしれません。
Macアプリは、コアアプリオブジェクトまたはコアアプリワークフローのいずれかに関連付けられているコマンドのカスタムメニューバーメニューを追加することがよくあります。
たとえば、macOSのメールでは、メッセージメニューとメールボックスメニューを使用して、これらの基本的なアプリオブジェクトを操作するコマンドを一覧表示します。
対照的に、Keynoteは「配置」メニューを使用して、スライドデッキでオブジェクトを配置するコアワークフローに関連するコマンドを一覧表示します。

After you group your app’s actions into menus, you need to order the items in each menu in a way that makes sense. Each standard menu defines a recommended order for items, so it’s important to follow this order for the items that you support. For example, Mac users expect the File menu to present items in this order:

• New...
• Open...
• Open Recent
• Close

アプリのアクションをメニューにグループ化した後、各メニューのアイテムをわかりやすい順序で並べる必要があります。
各標準メニューはアイテムの推奨順序を定義しているため、サポートするアイテムについてはこの順序に従うことが重要です。
たとえば、Macユーザーは、[ファイル]メニューに次の順序でアイテムが表示されることを期待しています。

• 新規…
• 開く…
• 最近開いたもの
• 閉じる

In a custom menu bar menu, you should order the items according to importance, frequency of use, or another scheme that makes sense in your app. Menu bar menus can also contain submenus and separators that help group items in logical ways. To learn more about these menu components, see Menu Anatomy.

カスタムメニューバーメニューでは、重要度、使用頻度、またはアプリで意味のある別のスキームに従ってアイテムを並べ替える必要があります。
メニューバーメニューには、項目を論理的にグループ化するのに役立つサブメニューとセパレータを含めることもできます。
これらのメニューコンポーネントの詳細については、「メニューの構造」を参照してください。

Also, it’s important to support keyboard shortcuts for all common commands in your menus so that both Mac users and iPad users who use keyboards can benefit. In addition to enabling the shortcuts for standard menu items, you can also define shortcuts for custom items. If custom menu items make sense in your app, be sure to review the guidance for creating custom keyboard shortcuts in Defining Keyboard Shortcuts.

また、キーボードを使用するMacユーザーとiPadユーザーの両方がメリットを得られるように、メニューのすべての一般的なコマンドのキーボードショートカットをサポートすることも重要です。
標準メニュー項目のショートカットを有効にするだけでなく、カスタム項目のショートカットを定義することもできます。
アプリでカスタムメニュー項目に意味がある場合は、キーボードショートカットの定義のカスタムキーボードショートカットを作成するためのガイダンスを確認してください。

Contextual Menus（コンテキストメニュー）

Contextual menus help people discover the actions that they can perform on an object without opening a menu bar menu. If you support context menus in your iPad app, the system automatically converts them to contextual menus in the macOS version of your app.

コンテキストメニューは、メニューバーメニューを開かずにオブジェクトに対して実行できるアクションを見つけるのに役立ちます。
iPadアプリでコンテキストメニューをサポートしている場合、システムはそれらをアプリのmacOSバージョンのコンテキストメニューに自動的に変換します。

To give Mac users the best experience, look for additional places to support contextual menus. For example, if there are common actions that people can perform on an object in your app, add a contextual menu that lists these actions. You can also add a contextual menu to a view that represents an object — for example, folder objects in the Finder support contextual menus that offer actions like Open in New Tab, Rename, and Duplicate.

Macユーザーに最高のエクスペリエンスを提供するには、コンテキストメニューをサポートする追加の場所を探します。
たとえば、アプリ内のオブジェクトに対してユーザーが実行できる一般的なアクションがある場合は、これらのアクションをリストするコンテキストメニューを追加します。
オブジェクトを表すビューにコンテキストメニューを追加することもできます。
たとえば、Finderのフォルダオブジェクトは、[新しいタブで開く]、[名前の変更]、[複製]などのアクションを提供するコンテキストメニューをサポートしています。

Visual Design Considerations（ビジュアルデザインの考慮事項）

To help your iPad app look great when it runs in macOS, take into account the platform differences in the following areas of visual design.

iPadアプリをmacOSで実行するときに見栄えを良くするには、ビジュアルデザインの次の領域におけるプラットフォームの違いを考慮してください。

Layout（レイアウト）

Mac users expect to resize app windows to just about any size from full screen to as small as the app permits. To support this type of infinite resizability — and to take advantage of the Mac’s wider display — use the regular width and regular height size classes and consider reflowing elements in your window’s content area to a side-by-side arrangement when necessary.

Macユーザーは、アプリウィンドウのサイズを、フルスクリーンからアプリが許す限りの小さいサイズまで、ほぼすべてのサイズに変更することを期待しています。
このタイプの無限のサイズ変更をサポートし、Macのより広いディスプレイを利用するには、通常の幅と通常の高さのサイズクラスを使用し、必要に応じてウィンドウのコンテンツ領域の要素を並べて配置することを検討してください。

As much as possible, adopt a top-down layout. macOS apps place the most important actions and content near the top of the window. If your iPad app provides controls in a toolbar or navigation bar, put these controls in the window toolbar of the macOS version of your app.

可能な限り、トップダウンレイアウトを採用します。
macOSアプリは、ウィンドウの上部近くに最も重要なアクションとコンテンツを配置します。 iPadアプリがツールバーまたはナビゲーションバーにコントロールを提供する場合、これらのコントロールをアプリのmacOSバージョンのウィンドウツールバーに配置します。

Consider moving controls from the main UI of your iPad app to the toolbar of your macOS window. Also, list the commands associated with these controls in the menus of your macOS app’s menu bar.

iPadアプリのメインUIからmacOSウィンドウのツールバーにコントロールを移動することを検討してください。
また、macOSアプリのメニューバーのメニューに、これらのコントロールに関連付けられているコマンドをリストします。

NOTE

In macOS, a toolbar button is always visible, but the current context might make it unavailable; in iOS, a toolbar button is always available, but the current context might remove it from the toolbar. For example, if your iPad app includes a toolbar button that works in only one tab, the macOS version displays the button as unavailable in all other tabs. To avoid confusing people, it can work better to use a "gear" button in the toolbar instead, because the items in a gear button's menu differ depending on the current app section.

注意

macOSでは、ツールバーボタンは常に表示されますが、現在のコンテキストでは使用できない場合があります。 iOSでは、ツールバーボタンは常に使用できますが、現在のコンテキストではツールバーから削除される場合があります。
たとえば、iPadアプリに1つのタブでのみ機能するツールバーボタンが含まれている場合、macOSバージョンには、他のすべてのタブでは使用できないボタンが表示されます。
ユーザーを混乱させないようにするには、代わりにツールバーの「歯車」ボタンを使用する方が効果的です。
歯車ボタンのメニューの項目は、現在のアプリセクションによって異なるためです。

Relocate buttons from the left or right edge of the screen. On iPad, placing buttons on the middle left or middle right screen edges can help people reach them, but on a Mac, this ergonomic consideration doesn’t apply. You may want to relocate controls to the top or bottom edge of the content area or put them in the toolbar of your macOS window.

画面の左端または右端からボタンを再配置します。
iPadでは、画面中央左または中央右端にボタンを配置すると、ユーザーがボタンに到達できるようになりますが、Macでは、この人間工学的な考慮事項は当てはまりません。
コントロールをコンテンツ領域の上端または下端に再配置するか、macOSウィンドウのツールバーに配置することができます。

Color（カラー）

Use the system selection color on both platforms. In general, iOS apps define the colors used to tint buttons and to indicate selection, but in macOS, people expect to use System Preferences to choose the selection and button colors they want.

両方のプラットフォームでシステム選択色を使用します。
一般に、iOSアプリはボタンの色付けと選択を示すために使用される色を定義しますが、macOSでは、人々はシステム環境設定を使用して希望の選択とボタンの色を選択することを期待しています。

The dynamic system colors designed for iOS backgrounds automatically map to appropriate macOS equivalents, as shown below.

iOSの背景用に設計された動的なシステムカラーは、以下に示すように、適切なmacOSの同等物に自動的にマッピングされます。

iOS color	Equivalent macOS color（同等のmacOSカラー）
systemBackground インターフェースの主な背景色	selectedContentBackgroundColor 選択され、強調されたコンテンツの背景に使用する色
secondarySystemBackground メインの背景の上に重ねられたコンテンツの色	windowBackgroundColor ウィンドウの背景に使用する色
tertiarySystemBackground セカンダリ背景の上に重ねられたコンテンツの色	selectedContentBackgroundColor (overlaid with quaternaryLabelColor) 選択され、強調されたコンテンツの背景に使用する色（「テキストラベルとセパレーターに使用する4進数の色」でオーバーレイ）
systemGroupedBackground グループ化されたインターフェースの主な背景の色	windowBackgroundColor ウィンドウの背景に使用する色
secondarySystemGroupedBackground グループ化されたインターフェースのメインの背景の上に重ねられたコンテンツの色	selectedContentBackgroundColor 選択され、強調されたコンテンツの背景に使用する色
tertiarySystemGroupedBackground グループ化されたインターフェースの二次的な背景の上に重ねられたコンテンツの色	selectedContentBackgroundColor (overlaid with quaternaryLabelColor) 選択され、強調されたコンテンツの背景に使用する色（「テキストラベルとセパレーターに使用する4進数の色」でオーバーレイ）

Other semantically defined iOS colors — such as the system colors and the label and separator colors — map to similarly named macOS colors. For guidance, see System Colors (macOS) and Dynamic System Colors (macOS).

システムの色、ラベルとセパレーターの色など、意味的に定義された他のiOSの色は、同じ名前のmacOSの色にマッピングされます。
ガイダンスについては、システムカラー（macOS）および動的システムカラー（macOS）を参照してください。

Don’t tint buttons in table rows. In your iPad app, you use a tint to show that buttons in table rows are active, but in macOS, tinted buttons in table rows look out of place.

テーブル行のボタンに色を付けないでください。
iPadアプリでは、濃淡を使用して、テーブル行のボタンがアクティブであることを示しますが、macOSでは、テーブル行の色付きボタンが場違いに見えます。

Typography（タイポグラフィ）

Although the automatic scaling performed by the system gives good results without requiring you to specify different font values on both platforms, you might not get the best results in every situation.

システムによって実行される自動スケーリングでは、両方のプラットフォームで異なるフォント値を指定しなくても良い結果が得られますが、すべての状況で最良の結果が得られるとは限りません。

Make sure small type is legible on the Mac. Be prepared to increase some of the smallest font sizes you use in your iPad app so that all text remains legible in the macOS version. Also, note that Dynamic Type is not supported in macOS.

Macで小さい文字が読みやすいことを確認してください。
iPadアプリで使用する最小フォントサイズをいくつか大きくして、すべてのテキストがmacOSバージョンでも読みやすいように準備してください。
また、動的タイプはmacOSではサポートされていないことにも注意してください。

Custom Icons and Glyphs（カスタムアイコンとグリフ）

Create a macOS version of your app icon. Great macOS app icons are noticeably different from great iOS app icons — for example, macOS icons can have nonrectangular shapes and are often skewed and rotated. By default, macOS applies a drop shadow to your iOS app icon so that it feels more at home on a Mac, but it’s better to design a Mac-specific version of your app icon. To learn more about how to approach the design of a macOS app icon, see App Icon.

アプリアイコンのmacOSバージョンを作成します。
優れたmacOSアプリアイコンは、優れたiOSアプリアイコンとは著しく異なります。
たとえば、macOSアイコンは四角形以外の形状をとることができ、多くの場合、斜めになって回転します。
デフォルトでは、macOSはiOSアプリのアイコンにドロップシャドウを適用するので、Macでよりくつろいでいますが、アプリ固有のバージョンのアプリアイコンを設計することをお勧めします。
macOSアプリアイコンのデザインに取り組む方法の詳細については、アプリアイコンを参照してください。

Create platform-specific glyphs, if necessary. If your iPad app uses custom glyphs that reference the platform in some way, create new glyphs that feel at home on the Mac. Xcode provides a separate asset catalog you can use in your iPad app for macOS-specific glyphs.

必要に応じて、プラットフォーム固有のグリフを作成します。
iPadアプリが何らかの方法でプラットフォームを参照するカスタムグリフを使用している場合は、Macでくつろげる新しいグリフを作成します。
Xcodeは、macOS固有のグリフのiPadアプリで使用できる個別のアセットカタログを提供します。

Preferences（環境設定）

If you supply app settings that appear in the iOS Settings app, macOS automatically displays these items in a preferences window in the Mac version of your app. By default, macOS adds a toolbar button to the preferences window for each item in your iOS settings, giving it the standard system preferences icon and the title you used for the item’s view in the Settings app.

iOS設定アプリに表示されるアプリ設定を指定すると、macOSはこれらの項目をMacバージョンのアプリの設定ウィンドウに自動的に表示します。
デフォルトでは、macOSはiOS設定の各項目の設定ウィンドウにツールバーボタンを追加し、標準のシステム設定アイコンと、設定アプリでの項目の表示に使用したタイトルを与えます。

As Mac users expect, your preferences window appears when they choose the Preferences menu item in your app menu. However, there are a few ways you can refine the display of your settings items and make your app’s preferences experience feel more Mac-like.

Macユーザーが期待するとおり、アプリメニューの[設定]メニュー項目を選択すると、設定ウィンドウが表示されます。
ただし、設定項目の表示を調整して、アプリの設定エクスペリエンスをMacのように感じさせる方法がいくつかあります。

Customize the icon for each item’s toolbar button. Because macOS automatically uses the standard system preferences icon for your settings items, people will have to read each toolbar button’s title to distinguish among multiple items. To improve this experience, supply a custom icon for each settings item.

各アイテムのツールバーボタンのアイコンをカスタマイズします。
macOSは設定項目の標準システム設定アイコンを自動的に使用するため、ユーザーは複数の項目を区別するために各ツールバーボタンのタイトルを読む必要があります。
このエクスペリエンスを向上させるには、各設定項目にカスタムアイコンを提供します。

Make switch controls easier for macOS users to understand. Unlike iPad apps, a macOS app often displays a confirmation alert when someone uses a switch to make changes in System Preferences. In addition, a switch in iOS Settings can include a small amount of text that provides more information about how the switch affects the user experience. In the Mac version of your app, you can provide a brief description to accompany a macOS switch and you can specify content to display in a confirmation alert when people use it to change a setting. For developer guidance, see Displaying a Preferences Window.

macOSユーザーが理解しやすいようにスイッチコントロールを作成します。
iPadアプリとは異なり、macOSアプリは、誰かがスイッチを使用してシステム環境設定を変更したときに確認アラートを表示することがよくあります。
さらに、iOS設定のスイッチには、スイッチがユーザーエクスペリエンスに与える影響に関する詳細情報を提供する少量のテキストを含めることができます。
アプリのMacバージョンでは、macOSスイッチに伴う簡単な説明を提供でき、ユーザーが設定を変更するために使用したときに確認アラートに表示するコンテンツを指定できます。
開発者向けガイダンスについては、「設定ウィンドウの表示」を参照してください。