ipados-design-guidelines

iPadOS デザインガイドライン

Appleのヒューマンインターフェイスガイドラインに沿って、iPadネイティブアプリを構築するための包括的なルールです。iPadは大きなiPhoneではありません。アダプティブレイアウト、マルチタスク対応、ポインター操作、キーボードショートカット、アプリ間のドラッグ＆ドロップが求められます。これらのルールは、より大きく高機能な画面に合わせてiOSのパターンを拡張します。

---

1. レスポンシブレイアウト（最重要）

1.1 アダプティブなサイズクラスを使用する

iPadには、2種類の横方向のサイズクラスがあります。レギュラー（フルスクリーン、大きな分割表示）とコンパクト（Slide Over、狭い分割表示）です。両方を考慮して設計してください。寸法をハードコードしないでください。

struct AdaptiveView: View {
    @Environment(\.horizontalSizeClass) var sizeClass

    var body: some View {
        if sizeClass == .regular {
            TwoColumnLayout()
        } else {
            StackedLayout()
        }
    }
}

1.2 iPhoneのUIを拡大しない

iPadのレイアウトは、iPad専用に設計する必要があります。iPhoneのレイアウトを13"ディスプレイいっぱいに引き伸ばすと、スペースが無駄になり、使い勝手も損なわれます。レギュラー幅では、マルチカラムレイアウトやマスター・ディテールパターンを使用し、表示する情報量を増やしてください。

1.3 すべてのiPadの画面サイズに対応する

iPad Mini（8.3"）、iPad（11"）、iPad Air（11"/13"）、iPad Pro（11"/13"）のすべてを想定して設計してください。単に拡大するのではなく、コンテンツを再配置する柔軟なレイアウトを使用してください。

1.4 レギュラー幅ではカラムベースのレイアウトを使用する

レギュラー幅では、コンテンツをカラムに整理してください。最も一般的なのは2カラム（サイドバー＋詳細）です。階層が深い場合は3カラム（サイドバー＋リスト＋詳細）が適しています。大画面で、画面幅いっぱいの単一カラムレイアウトを使うのは避けてください。

struct ThreeColumnLayout: View {
    var body: some View {
        NavigationSplitView {
            SidebarView()
        } content: {
            ContentListView()
        } detail: {
            DetailView()
        }
    }
}

1.5 セーフエリアを尊重する

iPadのセーフエリアはiPhoneとは異なります。古いiPadにはホームインジケーターがありません。横向きのiPadは、縦向きの場合とはインセットが異なります。常にsafeAreaInsetを使用し、ノッチやインジケーターに合わせたパディングをハードコードしないでください。

1.6 縦向きと横向きの両方に対応する

iPadアプリは、縦向きと横向きのどちらでも快適に使える必要があります。横向きは生産性向上を目的とした利用が主流です。縦向きは読書によく使われます。向きに応じてカラム数とレイアウトの情報密度を調整してください。

---

2. マルチタスク（最重要）

2.1 Split Viewに対応する

アプリはSplit Viewで画面幅の1/3、1/2、2/3のいずれでも正しく動作する必要があります。幅が1/3の場合、アプリにはコンパクトな横方向のサイズクラスが適用されます。どの分割比率でも、コンテンツを使いやすい状態に保ってください。

2.2 Slide Overに対応する

Slide Overでは、画面右端にコンパクト幅のオーバーレイとしてアプリが表示されます。iPhone幅のアプリのように動作します。この狭いモードでも、すべての機能にアクセスできるようにしてください。

2.3 Stage Managerに対応する

Stage Managerでは、ウィンドウを自由にサイズ変更でき、複数のウィンドウを同時に表示できます。アプリは次の要件を満たす必要があります。

• 任意のサイズに滑らかにリサイズできる
• 異なるコンテンツを表示する複数のシーン（ウィンドウ）に対応する
• 固定のサイズやアスペクト比を前提としない

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        // Support multiple windows
        WindowGroup("Detail", for: Item.ID.self) { $itemId in
            DetailView(itemId: itemId)
        }
    }
}

2.4 フルスクリーンを前提にしない

アプリはSplit ViewやStage Managerで直接起動される場合があります。セットアップ、オンボーディング、その他のフローで、フルスクリーンの寸法に依存しないでください。あらゆるサイズでアプリをテストしてください。

2.5 サイズ変更にスムーズに対応する

ユーザーがマルチタスク機能を使ってサイズを変更したときは、レイアウトの変化を滑らかにアニメーションさせてください。サイズ変更の前後で、スクロール位置、選択状態、ユーザーの作業状況を維持してください。サイズ変更時にコンテンツを再読み込みしないでください。

2.6 複数のシーンに対応する

UIScene / SwiftUI WindowGroupを使用して、異なるコンテンツを表示するアプリの複数のインスタンスをユーザーが開けるようにしてください。各シーンは独立しています。状態の復元にはNSUserActivityに対応してください。

---

3. ナビゲーション（最重要）

3.1 メインナビゲーションにはサイドバーを使用する

レギュラー幅では、iPhoneのタブバーをサイドバーに置き換えてください。サイドバーはより多くのナビゲーション項目を表示でき、セクションにも対応し、iPadに適したネイティブな操作感をもたらします。

struct AppNavigation: View {
    @State private var selection: NavigationItem? = .inbox

    var body: some View {
        NavigationSplitView {
            List(selection: $selection) {
                Section("Main") {
                    Label("Inbox", systemImage: "tray")
                        .tag(NavigationItem.inbox)
                    Label("Drafts", systemImage: "doc")
                        .tag(NavigationItem.drafts)
                    Label("Sent", systemImage: "paperplane")
                        .tag(NavigationItem.sent)
                }
                Section("Labels") {
                    // Dynamic sections
                }
            }
            .navigationTitle("Mail")
        } detail: {
            DetailView(for: selection)
        }
    }
}

3.2 タブからサイドバーへの自動変換

.sidebarAdaptableスタイルを指定したSwiftUIのTabViewは、レギュラー幅で自動的にサイドバーへ変換されます。これを使用すると、iPhoneからiPadへのシームレスな適応が実現できます。

TabView {
    Tab("Home", systemImage: "house") { HomeView() }
    Tab("Search", systemImage: "magnifyingglass") { SearchView() }
    Tab("Profile", systemImage: "person") { ProfileView() }
}
.tabViewStyle(.sidebarAdaptable)

3.3 複雑な階層には3カラムレイアウトを使用する

情報アーキテクチャが「カテゴリ > リスト > 詳細」の3階層になっている場合は、NavigationSplitViewを3カラムで使用してください。例として、メール（アカウント > メッセージ > メッセージ本文）、ファイルマネージャー、設定などがあります。

3.4 画面上部のツールバー

iPad では、ツールバーは iPhone のように画面下部ではなく、ナビゲーションバーのある画面上部に配置します。適切な配置を指定して、コンテキストに応じたアクションを .toolbar に配置してください。

.toolbar {
    ToolbarItemGroup(placement: .primaryAction) {
        Button("Compose", systemImage: "square.and.pencil") { }
    }
    ToolbarItemGroup(placement: .secondaryAction) {
        Button("Archive", systemImage: "archivebox") { }
        Button("Delete", systemImage: "trash") { }
    }
}

3.5 詳細ビューを空のままにしない

リストやサイドバーで項目が選択されていない場合は、詳細領域に意味のある空の状態を表示します。空白の画面ではなく、アイコンと説明テキストを含むプレースホルダーを使用してください。

3.6 広いキャンバスでのナビゲーションで記憶への依存を減らす

サイドバーの選択状態、検索語句、開閉状態を、サイズ変更やシーンの切り替え後も表示したまま維持してください。複数列のレイアウトでは、ユーザーが記憶に頼らず、画面上の構造を手がかりに作業を再開できるようにします。

---

4. ポインターとトラックパッド（高）

4.1 インタラクティブな要素にホバー効果を追加する

タップ可能なすべての要素は、ポインターのホバーに反応する必要があります。標準コントロールには、システムが自動的にホバー効果を適用します。カスタムビューには .hoverEffect() を使用してください。

Button("Action") { }
    .hoverEffect(.highlight)  // Subtle highlight on hover

// Custom hover effect
MyCustomView()
    .hoverEffect(.lift)  // Lifts and adds shadow

4.2 ボタンへのポインターの吸着

ポインターはボタンの範囲に吸着（引き寄せられる）する必要があります。標準の UIKit／SwiftUI ボタンでは、これが自動的に適用されます。カスタムのヒット領域では、.contentShape() を使ってポインター領域がタップ可能な領域と一致するようにしてください。

4.3 右クリックのコンテキストメニューに対応する

右クリック（二次クリック）でコンテキストメニューを表示する必要があります。.contextMenu を使うと、長押し（タッチ）と右クリック（ポインター）の両方に自動的に対応できます。

Text(item.title)
    .contextMenu {
        Button("Copy", systemImage: "doc.on.doc") { }
        Button("Share", systemImage: "square.and.arrow.up") { }
        Divider()
        Button("Delete", systemImage: "trash", role: .destructive) { }
    }

4.4 トラックパッドのスクロール動作

慣性を伴う2本指スクロールに対応してください。適切な場面ではピンチ操作でズームできるようにします。スクロール方向の設定を尊重してください。カスタムのスクロールビューでは、タッチ操作と併用してトラックパッドのジェスチャーが自然に感じられるようにしてください。

4.5 コンテンツ領域に応じてカーソルを変更する

状況に応じてカーソルの外観を変更してください。テキスト領域では I ビーム、リンクではポインタの手、サイズ変更ハンドルではサイズ変更カーソルを表示します。ドラッグ可能な項目には、つかむ形のカーソルを表示してください。

4.6 ポインター操作によるドラッグ＆ドロップ

ポインターを使うユーザーは、クリックしてドラッグすることで、コンテンツの並べ替え、選択、移動ができることを期待します。Shift キーを押しながらのクリックや Cmd キーを押しながらのクリックによる複数選択にも対応してください。

---

5. キーボード（高）

5.1 主要なすべてのアクションに Cmd+キーのショートカットを設定する

主要なすべてのアクションにキーボードショートカットが必要です。次の標準ショートカットは必須です。

ショートカット	アクション
Cmd+N	新しい項目
Cmd+F	検索
Cmd+S	保存
Cmd+Z	元に戻す
Cmd+Shift+Z	やり直す
Cmd+C/V/X	コピー／貼り付け／切り取り
Cmd+A	すべて選択
Cmd+P	印刷
Cmd+W	ウィンドウ／タブを閉じる
Cmd+,	設定／環境設定
Delete	選択した項目を削除

Button("New Document") { createDocument() }
    .keyboardShortcut("n", modifiers: .command)

5.2 Cmd キー長押しオーバーレイで見つけやすくする

ユーザーが Cmd キーを長押しすると、iPadOS にショートカットのオーバーレイが表示されます。すべてのショートカットを .keyboardShortcut() で登録し、このオーバーレイに表示されるようにしてください。関連するショートカットは論理的にグループ化します。

5.3 Tab キーでフィールド間を移動する

Tab キーで次のフォームフィールドやフォーカス可能な要素に進み、Shift+Tab で前に戻れるようにしてください。.focusable() と @FocusState を使って、キーボードフォーカスの順序を管理します。

struct FormView: View {
    @FocusState private var focusedField: Field?

    var body: some View {
        Form {
            TextField("Name", text: $name)
                .focused($focusedField, equals: .name)
            TextField("Email", text: $email)
                .focused($focusedField, equals: .email)
            TextField("Phone", text: $phone)
                .focused($focusedField, equals: .phone)
        }
    }
}

5.4 システムショートカットを上書きしない

システム用に予約されているショートカットは使用しないでください。対象は Cmd+H（ホーム）、Cmd+Tab（アプリスイッチャー）、Cmd+Space（Spotlight）、Globe キーの組み合わせです。これらは機能せず、混乱を招きます。

5.5 ハードウェアキーボードを検出する

ハードウェアキーボードが接続されているときは、UI を適応させてください。画面上のキーボードショートカットバーを非表示にし、キーボード操作に最適化されたコントロールを表示します。状態の検出には GCKeyboard を使うか、キーボードの表示状態を追跡してください。

5.6 矢印キーによるナビゲーション

リスト、グリッド、コレクションの移動に矢印キーを使えるようにしてください。複数選択には Shift キーとの組み合わせにも対応します。これは生産性重視のアプリに不可欠です。

5.7 ショートカットを見つけやすくする

ユーザーがショートカットの知識を暗記することに頼らないでください。Cmd キー長押しのオーバーレイ、メニューのラベル、目に見えるフォーカス移動を通じてコマンドを表示し、ユーザーが認識と反復によってショートカットを覚えられるようにします。

---

6. Apple Pencil（中）

6.1 Scribbleのサポート

iPadOSは、標準のテキストフィールドで手書きを自動的にテキストに変換します。Scribbleを無効にしないでください。カスタムのテキスト入力では、UIScribbleInteractionを採用してください。すべてのテキスト入力箇所でScribbleが機能することをテストしてください。

6.2 ダブルタップによるツールの切り替え

Apple Pencil 2以降では、ダブルタップしてツール（ペンから消しゴムなど）を切り替えられます。アプリに描画ツールがある場合は、UIPencilInteractionのデリゲートを実装してダブルタップを処理してください。

6.3 描画時の筆圧と傾き

描画アプリでは、ペンシルのタッチイベントから取得できるforce（筆圧）とaltitudeAngle／azimuthAngle（傾き）に対応してください。線の幅や不透明度の変化、陰影付けに使用してください。

6.4 ホバー検出（M2以降のPencil）

ホバーに対応したApple Pencil（M2 iPad Pro以降）では、画面に触れる前の位置データが得られます。プレビュー効果、ツールサイズのインジケーター、精度の向上に活用してください。

// UIKit hover support via UIHoverGestureRecognizer
let hoverRecognizer = UIHoverGestureRecognizer(target: self, action: #selector(pencilHoverChanged(_:)))
hoverRecognizer.allowedTouchTypes = [NSNumber(value: UITouch.TouchType.pencil.rawValue)]
canvas.addGestureRecognizer(hoverRecognizer)

@objc func pencilHoverChanged(_ hover: UIHoverGestureRecognizer) {
    let location = hover.location(in: canvas)
    showBrushPreview(at: location)
}

6.5 PencilKitとの統合

メモや注釈には、PencilKitのPKCanvasViewを使用してください。ツールピッカー、取り消し、インク認識を備えた、充実した描画機能をすぐに利用できます。

import PencilKit

struct DrawingView: UIViewRepresentable {
    @Binding var canvasView: PKCanvasView

    func makeUIView(context: Context) -> PKCanvasView {
        canvasView.tool = PKInkingTool(.pen, color: .black, width: 5)
        canvasView.drawingPolicy = .anyInput
        return canvasView
    }
}

---

7. ドラッグ＆ドロップ（高）

7.1 アプリ間のドラッグ＆ドロップは必須

iPadユーザーは、アプリ間でコンテンツをドラッグできることを期待しています。コンテンツをドラッグして取り出す（ソース）操作と、コンテンツをドロップする（デスティネーション）操作の両方に対応してください。これはiPadの基本的な操作です。

// As drag source
Text(item.title)
    .draggable(item.title)

// As drop destination
DropTarget()
    .dropDestination(for: String.self) { items, location in
        handleDrop(items)
        return true
    }

7.2 複数項目のドラッグ

ユーザーは1つの項目を持ち上げた後、ほかの項目をタップしてドラッグに追加できます。複数のNSItemProvider項目を提供し、複数項目のドラッグに対応してください。ドラッグのプレビューにバッジで件数を表示してください。

7.3 スプリングロード操作

ナビゲーション要素（フォルダー、タブ、サイドバー項目）の上にドラッグしたとき、少し待つと移動先が「スプリングオープン」するようにしてください。ナビゲーションコンテナーにスプリングロードを実装し、階層の深いドロップ先を有効にしてください。

7.4 ドラッグ＆ドロップの視覚的フィードバック

状態を明確に表示してください。

• 持ち上げ：ドラッグ開始時に項目を影付きで持ち上げます
• 移動：有効な移動先の上にドラッグすると、その移動先を強調表示します
• ドロップ：ドロップ位置への挿入をアニメーション表示します
• キャンセル：項目を元の位置に戻すアニメーションを表示します

7.5 Universal Controlのサポート

Universal Controlを使うと、iPadとMacの間で項目をドラッグできます。アプリが標準のNSItemProviderとUTTypesを使ったドラッグ＆ドロップに対応していれば、Universal Controlは自動的に機能します。

7.6 カスタム動作のためのドロップデリゲート

DropDelegateを使うと、ドロップ内容の検証、リスト内での並べ替え、ドロップ位置の処理など、ドロップ動作を細かく制御できます。

struct ReorderDropDelegate: DropDelegate {
    let item: Item
    @Binding var items: [Item]
    @Binding var draggedItem: Item?

    func performDrop(info: DropInfo) -> Bool {
        draggedItem = nil
        return true
    }

    func dropEntered(info: DropInfo) {
        guard let draggedItem,
              let fromIndex = items.firstIndex(of: draggedItem),
              let toIndex = items.firstIndex(of: item) else { return }
        withAnimation {
            items.move(fromOffsets: IndexSet(integer: fromIndex),
                      toOffset: toIndex > fromIndex ? toIndex + 1 : toIndex)
        }
    }
}

---

8. 外部ディスプレイ（中）

8.1 ミラーリングだけでなく、拡張コンテンツを表示

外部ディスプレイに接続したときは、iPadの画面を複製するのではなく、補完的なコンテンツを表示してください。プレゼンテーション、参考資料、拡張ビューは外部ディスプレイに表示し、操作部はiPadに残します。

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        // Additional scene for external display
        WindowGroup(id: "presentation") {
            PresentationView()
        }
    }
}

8.2 ディスプレイの接続と切断への対応

SceneDelegateのUIWindowSceneイベントを監視するか、UISceneのセッション通知（UIApplication.didConnectSceneSessionNotification／UIApplication.didDisconnectSceneSessionNotification）をリッスンして、外部ディスプレイのライフサイクルを監視してください。外部ディスプレイがプレゼンテーションの途中で切断された場合は、データを失わずにコンテンツをiPadの画面に戻すなど、適切に移行してください。

// SceneDelegate: detect when a scene (external display window) connects or disconnects
func scene(_ scene: UIScene,
           willConnectTo session: UISceneSession,
           options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene else { return }
    configureExternalDisplay(for: windowScene)
}

func sceneDidDisconnect(_ scene: UIScene) {
    restoreContentToiPad()
}

8.3 外部ディスプレイの全解像度への対応

外部ディスプレイの解像度とアスペクト比を最大限に活用してください。コンテンツにレターボックスやピラーボックスを適用しないでください。iOS 16以降のマルチシーン環境では、UIScreen.mainは非推奨です。UIWindowScene.coordinateSpace.boundsとUIWindowScene.screen.scaleを使って接続済みディスプレイを取得するか、SwiftUIで@Environment(\.displayScale)を使用してください。

---

9. アクセシビリティ（最重要）

影響度：最重要

ルール9.1：すべてのインタラクティブ要素にVoiceOverラベルを設定

すべてのボタン、コントロール、インタラクティブ要素には、意味のあるアクセシビリティラベルを設定する必要があります。アイコンのみのツールバー項目とカスタムビューには、.accessibilityLabel()を使用してください。

正しい例：

Button(action: compose) {
    Image(systemName: "square.and.pencil")
}
.accessibilityLabel("Compose new message")

誤った例：

Button(action: compose) {
    Image(systemName: "square.and.pencil")
}
// VoiceOver reads "square.and.pencil" — meaningless to users

ルール 9.2：アクセシビリティサイズを含む Dynamic Type に対応する

セマンティックなテキストスタイル（title、body、caption）を使い、テキストがユーザーの希望するサイズに合わせて拡大縮小されるようにします。iPad の広いキャンバスでは、テキストサイズを制限したり、拡大縮小を無効にしたりしないでください。5 段階すべてのアクセシビリティサイズでテストします。

Text("Section Header")
    .font(.headline)  // Scales with Dynamic Type automatically

ルール 9.3：ポインターのアクセシビリティ — ホバーだけを手がかりにしない

ホバー状態（.hoverEffect）はポインター入力を補助しますが、インタラクティブであることを示す唯一の手がかりにしてはいけません。すべてのインタラクティブ要素が、VoiceOver やキーボードのみを使うユーザーにも色、形状、ラベルで区別できるようにします。

ルール 9.4：フルキーボードアクセスとフォーカスの経路制御

フルキーボードアクセスが有効なとき、Tab キーで論理的な順序に沿って、すべてのインタラクティブ要素にフォーカスを移動できる必要があります。Split View や複数ウインドウのレイアウトでは、フォーカスが非表示または覆われたウインドウに移動しないようにします。@FocusState と .focusable() を使って、キーボードフォーカスのグラフを制御します。

struct FormView: View {
    @FocusState private var focusedField: Field?

    var body: some View {
        VStack {
            TextField("Name", text: $name)
                .focused($focusedField, equals: .name)
            TextField("Email", text: $email)
                .focused($focusedField, equals: .email)
        }
    }
}

ルール 9.5：Split View での VoiceOver — フォーカスコンテキストを分離する

Split View では、各アプリが独自の VoiceOver フォーカスコンテキストを持ちます。アプリが画面全体を占有していると想定してはいけません。画面幅が 1/3 または 1/2 の場合でも、VoiceOver で表示中のインターフェイス全体を操作できるようにします。操作可能なコンテンツを表示領域の外に隠す場合は、アクセシビリティツリーからも削除してください。

ルール 9.6：太字テキストに対応する

ユーザーが「設定」で「文字を太くする」を有効にした場合、カスタム描画のテキストもそれに対応する必要があります。SwiftUI のテキストスタイルは自動的に対応します。UIKit のコードでは UIAccessibility.isBoldTextEnabled を確認するか、SwiftUI で @Environment(\.legibilityWeight) を使います。

正しい例：

// SwiftUI — handled automatically for standard text styles
Text("Section Header")
    .font(.headline)

// SwiftUI — custom rendering respects legibilityWeight
@Environment(\.legibilityWeight) var legibilityWeight

var body: some View {
    Text("Custom Label")
        .fontWeight(legibilityWeight == .bold ? .bold : .regular)
}

誤った例：

// Hardcoded weight ignores Bold Text preference
label.font = UIFont.systemFont(ofSize: 17, weight: .regular)
// Missing: re-query font when UIAccessibility.boldTextStatusDidChangeNotification fires

ルール 9.7：コントラストを上げる設定に対応する

ユーザーが「設定」で「コントラストを上げる」を有効にした場合、カスタムカラーでは、よりコントラストの高いバリエーションを用意する必要があります。SwiftUI では @Environment(\.colorSchemeContrast) を、UIKit では UIAccessibility.isDarkerSystemColorsEnabled を使います。

正しい例：

// SwiftUI
@Environment(\.colorSchemeContrast) var contrast

var separatorColor: Color {
    contrast == .increased ? Color.primary : Color.secondary
}

// UIKit
let useHighContrast = UIAccessibility.isDarkerSystemColorsEnabled
let borderColor: UIColor = useHighContrast ? .label : .separator

誤った例：

// Static color ignores Increase Contrast setting
let borderColor = UIColor.separator // Always low-contrast; ignores user preference

---

評価チェックリスト

このチェックリストを使って、iPad への対応状況を確認します。

レイアウトとマルチタスク

• horizontalSizeClass を使ったアダプティブレイアウトを採用している
• Split View のすべての比率（1/3、1/2、2/3）でテストしている
• Slide Over（コンパクト幅）でテストしている
• Stage Manager：任意のサイズにスムーズにリサイズできる
• 複数のシーン／ウインドウに対応している
• 縦向きと横向きの両方で正しく動作する
• どのサイズでもコンテンツが切り取られない
• すべての iPad モデルでセーフエリアを尊重している

ナビゲーション

• レギュラー幅ではサイドバーを表示する
• コンパクト幅ではタブバーを使う
• 選択項目がない場合、詳細ビューにプレースホルダーを表示する
• ツールバー項目を下部ではなく上部に配置する
• 適切な箇所で 3 列レイアウトを使う

ポインターとトラックパッド

• すべてのインタラクティブ要素にホバーエフェクトを設定している
• 右クリックのコンテキストメニューを利用できる
• ポインターカーソルがコンテンツに応じて変化する（テキストには I ビームなど）
• クリックしてドラッグする操作で並べ替えができる

キーボード

• 主要な操作すべてに Cmd+キーのショートカットを設定している
• Cmd キーを押し続けたときに表示されるオーバーレイにショートカットが表示される
• Tab キーでフォームフィールド間を移動できる
• システムのショートカットと競合しない
• 矢印キーでリストやグリッドを操作できる
• Return／Enter キーでデフォルトのアクションを実行できる

Apple Pencil

• すべてのテキストフィールドでスクリブルを使える
• 描画アプリが筆圧と傾きに対応している
• ダブルタップ操作に対応している（該当する場合）

ドラッグ＆ドロップ

• コンテンツをほかのアプリへドラッグできる
• ほかのアプリからコンテンツをドロップできる
• 複数項目のドラッグに対応している
• すべてのドラッグ状態で視覚的なフィードバックを表示する

外部ディスプレイ

• ミラーリングだけでなく、拡張コンテンツを表示する
• 接続／切断を適切に処理する

アクセシビリティ

• アイコンのみのボタンとカスタムのインタラクティブ要素すべてにVoiceOverラベルを設定する
• テキストにはセマンティックなタイプスタイルを使用し、アクセシビリティサイズを含むDynamic Typeに合わせて拡大縮小する
• すべての機能にフルキーボードアクセスで到達できる（Tabによるナビゲーション、論理的なフォーカス順）
• インタラクティブ要素は、ホバー状態のみに頼らず識別できる
• すべてのSplit View幅でVoiceOverが正しく移動する
• 太字テキストの設定を尊重する（SwiftUIでは自動的に処理され、UIKitではUIAccessibility.isBoldTextEnabledを確認する）
• コントラストを上げる設定を尊重する（カスタムカラーでは、colorSchemeContrastまたはisDarkerSystemColorsEnabledを介してコントラストの高いバリエーションを用意する）

---

アンチパターン

禁止：iPhoneのレイアウトを拡大する

iPhone向けの単一カラムUIを引き伸ばしてiPadの画面を埋めるのは、スペースを無駄にし、手抜きに見え、使い勝手を損ないます。必ず大きなキャンバスに合わせて再設計してください。

禁止：マルチタスクを無効にする

マルチタスクのサポートを無効にしてはいけません。ユーザーはすべてのアプリがSplit ViewとSlide Overで動作することを期待しています。フルスクリーンを必須にすると、iPadのワークフローに支障をきたします。

禁止：キーボードを無視する

多くのiPadユーザーはMagic KeyboardやSmart Keyboardを使用しています。キーボードショートカットがないアプリでは、頻繁に画面に手を伸ばす必要があります。よく使うすべての操作にショートカットを用意してください。

禁止：通常幅でiPhone風の下部タブバーを使う

画面下部のタブバーはiPadでは縦方向のスペースを無駄にし、場違いに見えます。通常幅ではサイドバーによるナビゲーションに切り替えてください。SwiftUIでは.sidebarAdaptableによって自動的に切り替わります。

禁止：ポップオーバーをフルスクリーンシートとして表示する

iPadでは、ポップオーバーはフローティングパネルとして、元の要素にアンカーする必要があります。フルスクリーンシートを使うのは、没入型のコンテンツや、本当にフルスクリーンを必要とするフローに限ってください。あらゆるものをシートにするiPhoneのパターンは避けてください。

禁止：ポインターのホバー状態を無視する

ホバー時の効果がないと、トラックパッド使用時にアプリが壊れているように感じられます。ユーザーはどれがインタラクティブなのか判断できません。カスタムのインタラクティブ要素には、必ずホバー時のフィードバックを追加してください。

禁止：寸法をハードコードする

特定のiPadモデルに基づいて幅、高さ、位置をハードコードしてはいけません。動的なサイズ調整には、Auto Layoutの制約、SwiftUIの柔軟なフレーム、GeometryReaderを使用してください。

禁止：ドラッグ＆ドロップを忘れる

iPadでは、アプリ間のドラッグ＆ドロップが中核的なワークフローです。これをサポートしないと、アプリ内のコンテンツを外部で利用できません。最低限、テキスト、画像、URLのドラッグによる受け渡しをサポートしてください。

禁止：システムのキーボードショートカットを上書きする

Cmd+H、Cmd+Tab、Cmd+Space、またはGlobeショートカットを割り当てても機能せず、システムの動作を期待するユーザーを混乱させます。割り当てる前に、Appleの予約済みショートカット一覧を確認してください。

禁止：スクロールなしで大量のコンテンツを表示する

iPadの大画面では、デザイナーはすべてを一度に表示したくなりがちです。表示領域を超えるコンテンツは、引き続きスクロールできるようにしてください。スクロールを避けるためにコンテンツを切り詰めてはいけません。