更新情報に戻る

iPhone Duo 対応ガイド:5 つのルールとセルフチェックリスト

Apple の「iPhone Duo 向けデザイン」を実践できるルールに分解します。2 画面の形態、予約領域、スプリットビューとアレンジメントビュー、垂直方向のコントロール、ゲーム画面、そして 10 項目のチェックリスト。

対応ガイドデザインガイドライン

Apple は 2026 年 9 月 9 日に「iPhone Duo 向けデザイン」を公開しました。現時点で唯一の公式な形態仕様です。寸法表もブレークポイントもなく、核心はひとこと。標準のシステムコンポーネントを使い、サイズクラスに沿ってレイアウトすれば、アプリはさまざまな姿勢に自動で適応する。

この文書は一行ずつ読む価値がありますが、読み終えて実際に手を動かす箇所は多くありません。ここでは 5 つのルール、つまずきやすい 3 つの細部、そしてセルフチェックリストに分解します。

1. まずデバイスの形を知る

iPhone Duo は 2 画面のデバイスです。折りたたむと外側画面、開くと内側画面を使い、どちらにも前面カメラがあります。

  • 外側画面は他の iPhone より横に広く縦に短い。前面カメラは隅にあり常に見えていて、上方向にダイナミックアイランドの領域へ広がります。システムはツールバーとタブバーを側面に置き、縦の空間をコンテンツに残します。
  • 内側画面のカメラは画面下に隠れ、有効になったときだけ現れ、UI はそれに合わせて避けます。
  • 中央のヒンジは、部分的な折りたたみ、机への平置き、端で立てるなど複数の姿勢に対応します。横向きで開いたときもコントロールは側面に残り、2 画面を行き来しても位置が変わらないようになっています。

重要なのは、これでも iPhone 向けの設計だということ。iOS のパターンとベストプラクティスはそのまま当てはまります。

2. 5 つのベストプラクティス

  1. サイズ変更できるアプリにする。 サイズクラス、レイアウトマージン、セーフエリアで配置し、固定幅や特定の画面への依存を避けます。
  2. 2 つの画面で体験を揃える。 機能と要素の状態は画面をまたいで一貫させます。情報の階層はもう一段深くしてよいですが、別物にはしません。文書の例は「メール」で、折りたたみ時は一覧か 1 通だけ、開くと両方を並べます。
  3. どの姿勢でも機能が揃っている。 利用可能な領域に合わせるとコントロールがはみ出したり、コンテンツが動いたりしますが、同じ操作と同じ内容に届く必要があります。
  4. システムの垂直コントロールに従う。 ツールバー、タブバー、ナビゲーションのコントロールは上下ではなく側面。内側画面を横向きにしたときも側面です。
  5. ゲームはどの姿勢でも遊べる。 縦向き・横向きに固定してもかまいませんが、姿勢が変わったら画面全体を埋めます。

最初の 4 つのうち、1 と 4 は標準コンポーネントでほぼ達成できます。2 と 3 は自分で担保する必要があります。

3. 動的レイアウト:姿勢ごとに設計しない

文書の立場は明確です。姿勢の変化に対応することは、姿勢ごとにカスタムレイアウトを用意することではない。サイズクラス(外側はコンパクト幅、内側はレギュラー幅)を使い、既存のレイアウトを利用可能な空間に合わせて広げます。

本当に追加対応が必要なのは予約領域(reserved regions)です。

予約領域 説明
外側画面のカメラ(常時) 常に表示され、上方向にダイナミックアイランドへ広がる。コントロールが側面にあるときはシステムが自動で避ける
内側画面のカメラ(有効時) 有効になると UI が上に移動し、カメラが見える
折り目(使い方による) 部分的に開くと内側画面が複数の領域に分かれ、中央の折り目部分は使えない

システムコンポーネントの多くは自動で適応します。通知、コンテキストメニュー、フォームは折りたたみ状態に応じて移動し、スプリットビューのような大きなコンポーネントは内側画面の対称性に合わせて列幅とマージンを調整します。カスタムコンポーネントは ReservedRegion(SwiftUI)や UIView.ReservedRegion(UIKit)で内容を避ける必要があります。

実務的なヒントを 3 つ。

  • 折りたたみ時は並べ替えより調整を優先。 必要な要素だけ動かし、見える状態と押しやすさを保ちます。コントロールが突然消えたり大きく動いたりすると、ユーザーは追えません。
  • グリッドは偶数カラムで。 折りたたんだときにきれいに半分に分かれ、半端なマスが出ません。
  • 自動適応するコンテナを使い、自分で計算しない。 たとえば「メモ」のスプリットビューは、折りたたみ時に 2 つのペイン幅を自動で調整します。

4. スプリットビューとアレンジメントビュー

スプリットビューは内側画面で開き、外側画面では 1 つのペインに畳まれます。切り替えの考え方は、他の iPhone でのレギュラー環境とコンパクト環境の切り替えと同じです。標準コンポーネントなら幅とマージンは折りたたみ状態に自動で追従します。

アレンジメントビュー(arrangement views)は文書で新しく示された概念です。1 つのコンテナに主ビューと副ビューを置き、サイズ、向き、予約領域に応じて動的に配置します。2 種類あります。

  • スプリットアレンジメント:幅が高さより大きければ水平に分割、高さが幅より大きければ垂直に分割;
  • スタックアレンジメント:部分的に折りたたむと 2 つのビューが両側に分かれ、それ以外では主ビューが副ビューの上に重なります。

既存のレイアウトはそのまま移行できます。HStack / VStack のような並列・上下構造はスプリットアレンジメントに、ZStack のような重なり構造はスタックアレンジメントに対応します。注意点として、アレンジメントビューはコンテンツだけを並べ、ナビゲーションは扱いません。ナビゲーションスプリットビューやタブビューといった導線のコンテナは、アレンジメントビューの外側に置きます。

5. 垂直コントロール:もっとも間違えやすい部分

外側画面は横に広く縦に短いため、システムはツールバーとタブバーを縦にして側面へ置きます。これが iPhone Duo の最も中心的な操作特性であり、同時に「ネイティブらしくない」と感じさせやすい箇所でもあります。文書の記述が最も細かいので、要点だけ拾います。

  • 上部は主要な導線(戻る、閉じる)に使い、そのあとに目立つ操作(完了)を置きます。残りの項目は元のグループを保ちます。
  • 既定は下から上へ並べ、可視性の優先度で順序を調整します。まずグループ全体、次にグループ内の個別項目。よく使う操作(メールの「作成」、メモの「新規」)は残します。
  • 既定のバー位置は基本的に上書きしない。 側面のコントロールはプラットフォームの約束で、変えるとユーザーが覚え直しになります。
  • バーが不要な画面は全幅を使ってよい(例:計算機)。背景やタイトルを通しにして内容を内側に収めることもできますが、ダイナミックアイランドやステータスバーと衝突しないことが条件です。
  • ToolbarItemGroup でグループ化し、固定の余白を手で入れない。 システムが利用可能な空間に合わせて処理します。
  • コントロールは影響する内容の近くに置く。 メールで一覧に作用する操作は、側面ではなく一覧ペインの上部に残します。
  • テキスト以外の項目にはタイトルとシンボルを両方(Label)。オーバーフローメニューや展開時にタイトルが使われるためです。
  • 空間が足りないときは二択。導線中心の画面ならツールバー項目をオーバーフローに畳んでタブバーを守り、作業中心の画面ならタブバーを圧縮して主要なツールバー操作を守ります。
  • システムのオーバーフローメニューを使い、三点リーダーはオーバーフロー専用に。他のメニューは別のシンボルにします。

6. ゲーム:画面を埋める、黒帯を足さない

ゲームには独立した要件があり、しかも具体的です。

  • 縦向き・横向きに固定してよいが、姿勢が変わったら画面全体を埋める;
  • サイズ変更時は、文字とコントロールの大きさをできるだけ保つ;
  • レターボックスやピラーボックスではなく、アスペクト比を変えることを優先。どうしても避けられない場合は、余白部分にイラストを入れて全画面に見えるようにする。

サイト内の 214 本のゲームのうち 93.9% は iPhone / iPad 共通パッケージで、もともとタブレット用レイアウトを持っています。ただし「レイアウトがある」と「画面を埋める」は別の話で、共通パッケージでも大画面で黒帯が残ることがあります。確認のときに最も差が出るのがここです。

7. サイト内の基準と照らす:何が自動で、何が自前か

文書の要件 システムが自動? 確認で見る点
サイズクラスとレイアウト 標準コンポーネントならほぼ自動 主要画面が開いた状態・閉じた状態の両方で成立するか
予約領域の回避 標準は自動、カスタムは API 対応 内容がカメラや折り目に隠れていないか
垂直コントロール 標準のツールバー・タブバーは自動 側面バーの位置が一貫しているか、オーバーフローが使えるか
画面をまたぐ状態の一致 いいえ 開閉で状態を失わないか、再読み込みしないか
姿勢変化での機能維持 いいえ 部分折りたたみでもコントロールが残り、押せるか
ゲームが画面を埋める いいえ 黒帯がないか、タッチ位置がずれていないか

サイト内で「対応済み」と判定する 3 つの必須条件(主要画面のレイアウト、開閉の切り替え、主要な操作)は、この文書の要件とほぼ重なります。確認記録は HIG の実行可能版として読めますし、逆に対応作業ではサイト内の記録を回帰テストのケースとして使えます。

8. 10 項目のセルフチェック

  1. レイアウトに固定幅を書かず、レイアウトマージンとセーフエリアを基準にしている
  2. 外側はコンパクト幅、内側はレギュラー幅で、特定の姿勢専用のレイアウトを書いていない
  3. 外側カメラ、内側カメラ、折り目の 3 か所が内容を隠さない
  4. 部分折りたたみでは必要な要素だけ動かし、コントロールが突然消えない
  5. グリッドは偶数カラムで、折りたたむときれいに半分に分かれる
  6. 開閉で状態を失わず、ページを再読み込みしない
  7. 側面ツールバーの順序が正しい(戻る/閉じるが上、完了が見やすい位置)
  8. ツールバー項目にタイトルとシンボルが両方ある(Label)
  9. 空間不足時の圧縮方針が決まっている(タブバーを守るか、ツールバーを守るか)
  10. ゲームはどの姿勢でも画面を埋め、黒帯よりアスペクト比の変更を優先している

9. 参考

本文は 2026 年 9 月 9 日版の公式ページに基づきます。公式が更新された場合は原文が優先です。ご自身のアプリで文書と合わない点を見つけたら、フッターのフォームからお知らせください。