iPhone Duo 公式 Human Interface Guidelines：デバイス形態は手の動きに合わせて自在に切り替わるが、ユーザーの注意力とワークフローは決して途切れない

Appleはついに自社初の折りたたみスマートフォン、iPhone Duoを発表した。製品はまだ発売されていないが、AppleはすでにHuman Interface Guidelinesを更新し、iPhone Duoのインターフェースをどう設計すべきかを詳しく説明している。

ガイドライン全体の基本綱領は、アプリが2つの画面間でシームレスに適応し、開閉の間も体験が連続していること。中核となる指針は次の3つだ：

• 連続性の優先。閉じる、半折りにする、開くといった動作は単なる物理的な動きにすぎず、ソフトウェア体験の途切れになってはならない。ユーザーがデバイスの形態を変えても、機能、要素の状態、手元のタスクフォーカスはすべて連続して引き継がれなければならない。
• 形態に合わせて適応するが、姿勢ごとに個別対応はしない。システムは形態に合わせてレイアウトを調整する——半折り時にはオーバーレイ表示のビューが左右に分かれ、分割カラムは自動的に等幅になる。しかし同時に、ガイドラインは姿勢ごとに個別のレイアウトを用意してはならないと言い切っている。変わるのはシステムであり、開発者のコードの分岐ではない。
• 適応とは拡大ではない。外側ディスプレイから内側ディスプレイへの移行は、アイコンやフォントサイズを単に拡大することではなく、利用可能領域の拡大に伴って情報の階層構造を再構築することである。1列の表示が2カラムへと広がり、隠されていたドロワーが常駐のサイドバーへと展開される。

iPhone DuoのUI設計ガイドラインを理解するには、まずその物理的な画面にどのような変化が起きたかを見る必要がある。

これまで、iPhoneの画面アスペクト比は長らく19.5:9前後に維持されており、典型的な「縦長」の画面であった。縦に長い画面では、UIの上部にナビゲーションバーを、下部にtab barを配置しても、中央にはユーザーが上下にスクロールしてコンテンツを閲覧するための十分な垂直方向の高さが残されていた。

しかし、iPhone Duoの形態はこの前提を完全に覆した：

• 外側ディスプレイ：5.4インチ OLEDディスプレイ、解像度は 1398 × 2034 ピクセル。依然として縦向きの画面ではあるものの、アスペクト比は約 1.455:1 であり、他のiPhoneの19.5:9に比べて3:2に近く——相対的に横幅が広く、縦が短い。
• 内側ディスプレイ：7.6インチの折りたたみ式OLEDディスプレイで、展開時の解像度は 1878 × 2670 ピクセル。こちらも同様に正方形に近い大画面のプロポーションを持つ。

iPhone Duoの外側ディスプレイのホーム画面：画面比率は従来のiPhoneより幅広く背が低く、UIコントロールのレイアウトの重心はサイド側に寄せられている。

iPhone Duoの展開後の7.6インチ内側ディスプレイのホーム画面：同じホーム画面でありながら、アイコンは外側ディスプレイの4列から8列になっている。

もし外側ディスプレイで従来の「上部ナビゲーションバー ＋ 下部tab bar」という上下から挟み込む設計を踏襲し続ければ、画面中央に残されるコンテンツ閲覧エリアは著しく圧迫され、スクロールするたびにわずか数行しか見えなくなってしまう。

そのため、AppleがiPhone Duoのガイドラインで提示した核心的な解決策は、「コントロールバーを側面に移動させる」ことである。

閉じた状態で外側ディスプレイを使用する際、システムはデフォルトでtoolbar、tab bar、および主要な操作コントロールを画面側面の縦軸へと移動させる。また、内側ディスプレイを横向き（landscape）で開いた際も、これらのコントロールは同様に側面に留まるため、画面を展開したりデバイスを回転させたりしても、縦方向のコンテンツ高が唐突に激変することはない。同時にガイドラインは、これが「依然としてiPhoneのための設計」であり、既存のiOSのパターンやベストプラクティスがそのまま適用できることを繰り返し強調している。標準のシステムコンポーネントを使用し、もともとサイズ調整に対応しているアプリであれば、ほとんど手を加えることなくあらゆる姿勢に適応できる。

ハードウェアの解剖：デュアルスクリーン、パンチホール、不可視カメラの配置ルール

iPhone Duoの内外2つの画面はハードウェア構造が異なっており、これがシステムのインタラクション要素の配置場所を直接決定づけている（表はスマートフォンでは左右にスクロールできる）：

位置関係は把握しておく価値がある：外側ディスプレイのヒンジは片側の側面にあり、カメラはその反対側のトップコーナーにある。一方、内側ディスプレイの折り目は中央を通り、カメラは中央ではなく、折り目の右側の半画面の上部にある。後述する reserved regions のセクションにある切り替え可能な図解で、これら両方の形態を確認できる。

このハードウェア構成に基づき、外側ディスプレイの常時表示フロントカメラと側面コントロールは垂直方向に厳密に整列される。それに対して内側ディスプレイのフロントカメラは画面下への埋め込み方式を採用しており、普段のブラウジングでは完全に目に見えない。カメラを呼び出したりビデオ通話を行ったりしたときにのみ、システムは周囲のUI要素を能動的に両側へ退避させ、レンズの動作位置を明示する。

垂直コントロールシステム（Vertical Controls）：側面のシングルレールはどのように機能するのか

これまで画面の上部と下部に分散していたコントロールは、ここではすべて側面に移動している——ただし1本に統合されるわけではなく、元のグループ分けに従ってそれぞれセクションとして独立している。Appleはガイドラインの中で、この「側面コントロールレール」の階層順序と適応ロジックを規定している。

1. 垂直軸におけるコントロールの順序

片手で外側ディスプレイを持つ際、側面コントロールは厳密に上から下へのロジックに従ってアンカーされる：

1. Dynamic Island：位置はハードウェアによって決まる——外側ディスプレイのカメラパンチホールのソフトウェア形態であり、Live Activities 発生時にここから展開される。側面コントロールレールの起点はこれと整列する。
2. ステータスバー（Status Bar）：時刻、バッテリー、ネットワーク状態を表示する。
3. ツール＆ナビゲーションバー（Toolbar & Navigation）：「戻る」「閉じる」「完了」といった画面の主要な操作を含む。
4. タブバー（Tab Bar）：アプリのコアモジュール切り替えを担い、手の届きやすい底部エリアに配置される。

外側ディスプレイ側面のコントロールバーにおける上から下への4段の配置：Dynamic Island、ステータスバー、toolbar、tab bar。

注意すべき点として、この垂直コントロールバーが有効になるのは、外側ディスプレイ、および内側ディスプレイが横向きの状態にあるときのみである。内側ディスプレイを縦向き（Portrait）で保持しているときは、垂直方向の高さが十分にあるため、システムは従来のiPhoneユーザーにおなじみの上部バーと下部の横型tab barを自動的に復元する。垂直軸上のコントロール配置はiPhone Duoにおける最も中核的なパターンの一つであり、通常はデフォルトのバー配置をオーバーライドすべきではない。また、垂直コントロールはハードウェアと整列を保つため、外側ディスプレイ上ではカメラとの相対位置が固定され、右から左へ記述する言語環境（RTL）であっても反対側に入れ替わることはない。

すべての姿勢でコントロールが側面に配置されるわけではなく（内側ディスプレイの縦向きでは横型バーに戻る）、利用可能空間もそれぞれ異なるからこそ、ガイドラインはコントロールの相対位置を姿勢間で一貫させることを特に強調している。ユーザーが姿勢を変えたからといって、ボタンがどこにあるかを再び探させるようなことがあってはならない。これは「注意力を途切れさせない」という原則をコントロールレベルに落とし込んだ具体的な要件である。

2. 非対称性の衝突回避とマルチタスク分割画面

コントロールが片側に収容されるため、コンテンツの表示領域には自ずと非対称性が生じる。

• 単一アプリモードでは、safe area insets（セーフエリアインセット）に頼ることで、スクロール可能なコンテンツが側面のコントロールに覆い隠されないように担保する必要がある。
• 2つのアプリによる分割画面（Split View multitasking）では、2つのアプリが折り目の両側に分かれて配置される。この時システムは、左側のアプリのコントロールバーは最も左側に、右側のアプリのコントロールバーは最も右側に配置すると定めている。両アプリはそれぞれハードウェアの外側の縁に密着する。ここでのガイドラインの注意喚起は、セーフエリアを用いてコントロールがコンテンツを覆わないようにすること、そして反対側の縁にあるコントロールも計算に入れておくことだ——自身のアプリがどちら側に配置されるかは事前には分からないため、両側のセーフエリアを処理しなければならない。

2つのアプリによる画面分割マルチタスク時、コントロールバーはそれぞれ画面の最左端と最右端の外側エッジに配置され、操作が互いに干渉しない。

3. 操作ボタンの優先度とオーバーフロー時の折りたたみ

側面の縦方向スペースは横方向に比べれば余裕があるものの、機能が増えればやはり過密になる。ガイドラインが提示するデフォルトの順序は下から上へである。ツール項目同士の比較において、下に配置されたものから順に省略記号の overflow menu（側面レール上部のtoolbarグループ内にある）へと折りたたまれていく。

注意したいのは、これがツール項目間でどちらが先に譲るかという話である点だ。toolbarとtab barという2つのバー自体のどちらが先に譲るかについては別の階層のルールであり、後述の第4項で説明する——どちらも「デフォルト」と呼ばれているが、扱っている対象は別のものである。

開発者はAPIを通じて操作の優先度を指定できる（SwiftUIの ToolbarItemVisibilityPriority、UIKitの UIBarButtonItemVisibilityPriority）：

• 高優先度の項目を優先的に保持する：Mailの「新規作成」、Notesの「新規メモ」、バッジ付きなど重要なステータスを伝える項目は、より遅く折りたたまれるようにし、ひと目で視認できるようにすべきである。
• テキストボタンは控えめにし、シンボルを優先する：ガイドラインが示すメカニズムでは、テキストラベル付きのボタンは横方向のバーに留まり、側面の縦軸には移動しないとされている。しかしガイドラインはそこまでしか述べておらず、そもそも横方向のバーが存在しない外側ディスプレイのような形態において、それらのボタンが一体どこに表示されるのか、あるいは一切表示されないのかについては説明していない。この推奨事項の重みは、まさにこの「説明されていない部分」に起因している：アイコンが使えるなら、テキストボタンは避けるべきなのだ。
• タイトルとシンボルの両方を提供する：もともとテキストのみの項目を除き、すべてのtoolbar項目にタイトルとシンボルの両方を提供すると、システムはコンテキストに応じてどちらを使用するかを選択する。シンボルが表示される場合でもタイトルを設定しておく必要がある——overflow menuや展開時の形態ではそのタイトルが使われるためだ。
• 関連項目はグループにまとめ、手動の余白を避ける：関連するtoolbar項目はコンポーネントグループ（SwiftUIの ToolbarItemGroup またはUIKitの UIBarButtonItemGroup）を使って整理する。システムが項目間やグループ間に自動的に適切な間隔を空け、利用可能スペースに適応させるため、固定幅のスペーサーを手動で追加するのは避ける。

4. スペース制約時における2つの圧縮戦略

まず前提を明確にしておく必要がある：側面コントロールレールはハードウェアに結びついている。本体を横向きにして使っても、コントロールレールはハードウェアの同じ辺に留まり（外側ディスプレイのカメラとの相対位置を維持する）、画面の上下へと戻ることはない。その代償として、この辺の利用可能な長さが大幅に短くなり、toolbarとtab barが収まりきらなくなる。ガイドラインはこの状況に対し、2つのフォールバック戦略を定義している：

• ナビゲーション指向（デフォルト）：toolbarのコンテンツが優先的に ... の overflow menu へと折りたたまれ、tab barは完全に保持される。ブラウジングやチャンネル切り替えを中心とするシナリオに適している。
• タスク指向：tab barが単一の最小化されたコントロールへと圧縮され、スペースを空けてtoolbarボタンを完全に表示する。ドキュメント編集、描画、または特定の操作フローに適している。

これら2つの戦略の背景には、「圧縮されるのは表現であって、ユーザビリティではない」というボトムラインがある。利用可能面積の変化に伴い、コントロールが overflow menu に折りたたまれたり、コンテンツが移動したりリサイズされたりすることは許容される。しかし、ユーザーがデバイスをどのように持ち、どのように見ようとも、同じコントロールやコンテンツにアクセスできなければならない——姿勢を変えたからといって機能が削られてはならないのだ。

ナビゲーション指向の圧縮（図は横向きにした外側ディスプレイで、Dynamic Islandの黒いドットが右下にある）：toolbarはoverflow menu（省略記号メニュー）に折りたたまれ、tab barの各項目は完全に保持される。

タスク指向の圧縮（同様に横向きにした外側ディスプレイ）：tab barは1つのコントロールに縮小され、完全なtoolbarボタンにスペースを譲る。

5. ローカルコントロールの近接配置の原則

すべてのボタンを側面レールに放り込めばよいというわけではない。ガイドラインの原則は、コントロールがどのコンテンツ領域に属しているかに応じてそのコンテンツに寄り添って配置すべきであり、統一感のためだけに側面へ移動させてはならない、というものだ——配置位置そのものが、そのボタンが何を操作するものなのかをユーザーに伝えているからである。

カラム分割されたMailアプリを例にとると、メール一覧全体に作用する操作（並べ替えやフィルタなど）は、左側のリストカラム上部に配置しなければならない。現在閲覧中の個別のメールに対する具体的な操作（返信、アーカイブ、削除など）のみが、最右側の垂直ツールバーに配置される。

コントロール近接の原則：左側のリストに影響するコントロールはリスト上部に留まり、右側のメール本文に影響するコントロールのみが最右端のサイドバーに配置される。

予約領域（Reserved Regions）：セーフエリアより複雑な退避の物理学

従来のiOS開発において、UIの退避は主に safe area に依存していた——画面の角丸、下部のホームインジケータ（Home Indicator）、上部のノッチや Dynamic Island を避けることである。しかしiPhone Duoでは、折りたたみ構造の導入に伴い、Appleはこの仕組みをreserved regions（予約領域）へと拡張した。

reserved regions は、画面上で「コンテンツを重ねてはならない」または「コンポーネントが動的に退避しなければならない」物理的および機能的な領域を表す。システムコンポーネントの多くは自ら退避するが、カスタムコンポーネントでは reserved region APIs を使用してコンテンツを退避させ、重要な要素がこれらの位置と重ならないようにする必要がある：

折り目はUIのレイアウトにどう影響するか

ユーザーがiPhone Duoを展開して机の上にフラットに置いて使うとき、中央の折り目は連続した通常のディスプレイスペースにすぎない。しかし、ユーザーがデバイスを部分的に折りたたむ（Partially Folded）と（本を開くような角度にしたり、ノートPCのような形態で置いたりした場合）、システムは中央の折り目を reserved regions（コンポーネント内では「折りたたみ領域」と呼んでいるが同一のもの）としてマークし、退避メカニズムを発動させる：

1. ポップアップとメニューの自動位置移動：システムのアラート（Alerts）、コンテキストメニュー（Context Menus）、ハーフモーダルシート（Sheets）は、折り目の中央に挟まれて不格好に真っ二つに割れることなく、自動的に位置をずらして折り目に重ならないようにする。
2. リスト分割カラムの対称的な再構築：標準アプリのNotesを例にとると、フラットに開いた状態では左側のメモリストが狭く、右側のメモ本文が広い。しかし半折りたたみ状態では、システムの分割カラムビューが左側のカラムを自動的にきっちり50%まで広げ、リストが左画面全体を、本文が右画面全体をちょうど占めるようにする。
3. グリッドには偶数列を使用する：グリッド（Grid）のフローレイアウトを設計する際は、コンテンツが折りたたまれた際に左右2つにきれいに分かれるよう、偶数列（2列、4列など）を優先して使用する。
4. ただし、これに乗じてレイアウトを大幅に変えてはならない：ガイドラインは、折りたたみ時に移動させるのは「動かさなければ見えなくなったりタップできなくなったりする」要素だけにとどめるよう特に注意を促している。コントロールが突然消えたり大きくジャンプしたりするとユーザーが見失ってしまうため、小さな調整のほうが常に全体を白紙に戻して再配置するよりも優れている。

完全展開：左側のメモリストが狭く、右側の本文が広い。

半折りたたみ：左の欄は右の欄と等幅になるよう自動的に広がり、それぞれ物理的な半画面を占める。2枚の公式図は本体の外枠の描き方が同じで、違いは左右の欄の幅の比率のみである。

新たなコンテナ：arrangement view の2つのモード

reserved regions が「システムがあなたの代わりにどの場所を避けてくれるか」を語るものであるとすれば、arrangement view は「これらの変化に追従するために、自分自身の2つのビューをどう配置すべきか」を語るものである。デュアルスクリーンの折りたたみに対して開発者がレイアウト判定コードを書く負担を減らすため、AppleはiOSの体系にこの全く新しいレイアウトコンテナを導入した。

Arrangement View の内部では2つのサブビュー、すなわち主ビュー（Primary View）と副ビュー（Secondary View）が管理される。現在の状態が内側ディスプレイか外側ディスプレイか、横向きか縦向きか、フラットか半折りたたみかに応じて、これら2つのサブビューの幾何学的関係を自動的に調整する。ただし、ガイドラインでは全体を通じて「どのコンテンツを Primary にすべきか」という抽象的な区分基準は示されていない。開発者は具体的な挙動から逆算するほかない——例えば overlay arrangement においては、Primary が上に重なるレイヤー（したがって通常はコントロールパネルや操作カードなど）であり、Secondary こそが下地に敷かれるレイヤーである、といった具合だ。

ガイドラインはこれを大きく2つのカテゴリに分類している：

1. 分割配置（Split Arrangement）

split arrangement は、2つの画面を同時に表示する必要があるシナリオで使用される（ガイドラインに製品の具体例は挙げられていないが、理解しやすいよう2つ例を挙げると：左で動画を観て右でコメントを見る、あるいは上でファインダーを表示して下でアルバムを見る、といったものだ）。

• 水平分割：コンテナの幅が高さより大きい場合、自動的に左右に並ぶ。
• 垂直分割：コンテナの高さが幅より大きい場合、自動的に上下に並ぶ。
• コードの直感と軸の制限：Appleが提示した対応関係によると、SwiftUIにおける水平スタック（HStack）や垂直スタック（VStack）は split arrangement に直接対応付けることができ、もともとそのような構造を持つレイアウトであれば移行を検討できるとガイドラインは推奨している。また、開発者は split arrangement で使用を許可する軸を制限することもできる。一点、ガイドラインが説明していないことがある：split arrangement において primary と secondary のどちらが手前（先頭）に来るのか、どちらが左に来るのかについて、ガイドラインはルールを提示していない。公式の図解では secondary が左、primary が右に描かれている——もし HStack の直感に従って最初のサブビューを primary と見なせば、向きはちょうど逆になる。実際に移行する際には、この順序を自身で実測して確かめる必要がある。

split arrangement：secondary viewとprimary viewが利用可能領域を半分ずつ占める。この図に描かれているのは完全展開の状態である。

2. 重ね合わせ配置（Overlay Arrangement）

overlay arrangement は、メインコンテンツとフローティングパネルを組み合わせるシナリオに適している（これも理解を助けるための例を挙げると：地図を下地に敷いて検索カードを重ねる、動画を全画面再生してフローティングの操作パネルを重ねる、といったものだ）。

• 完全にフラットな状態の時：副ビュー（Secondary View）が画面全体を満たし、より小さな主ビュー（Primary View）がカードやフローティングレイヤーとして副ビューの上に重なる。
• 半折りたたみで設置した時：2つのビューは自動的に重なりを解き、それぞれ独立して物理的な半画面を1つずつ占有する——例えば上半分の立ち上がった画面に映像を表示し、机の上に水平に置かれた下半分をコントローラーとして使う。
• コードの直感と折りたたみスイッチ：これはSwiftUIの重なりコンテナ（ZStack）に直接対応する。副ビューを表示させたくない場合、開発者は明示的にそれを折りたたんで収納することもできる。

overlay arrangement：secondary viewが画面全体に広がり、primary viewがフローティングレイヤーとしてその上に重なる。この図に描かれているのは完全にフラットに開いた状態であり、半折りたたみ時には両者が分かれてそれぞれ片側を占めるが、図には描かれていない。

アーキテクチャ上の越えてはならない一線：arrangement view が担うのは幾何学的な配置のみであり、ナビゲーションは管轄しない。ガイドラインの記述によると、ナビゲーションコンテナは arrangement view の外側に配置すべきであり、内側に入れてはならない——SwiftUIでは NavigationSplitView / TabView、UIKitでは UISplitViewController / UITabBarController がこれに該当する。

6種類の姿勢、なぜAppleは個別対応しないよう忠告するのか

ヒンジによって、iPhone Duoには非常に多くの持ち方や置き方が生まれる。公式からは6種類の姿勢の図解が提示されているが、ガイドライン本文で具体的に名指しされているのは3種類である：本のように半折りにする、机の上にフラットに置く、側面の縁で立てる。

公式の姿勢模式図。6つのコマは左から順に：閉じて縦持ち（右上に外側カメラの開口部が見える）、横向きヒンジでデスク上に斜めに立てかける、完全展開して横向きにフラットに置く、本のようなV字型の半折りたたみ、完全展開して縦向きにフラットに置く、横向きで部分的に折りたたんで立てる。図には文字の注記がなく、ガイドライン本文ではそのうち3種類にしか言及していない。

これほど多くの姿勢を前にして、多くの開発者やデザイナーが最初に抱く疑問は「6通りのレイアウトロジックを書き、デバイスのジャイロスコープやヒンジの角度センサーを監視しなければならないのか？」というものだろう。

ガイドラインの回答はきわめて明快だ：個々の物理的な姿勢に対して個別にレイアウトを設計してはならない。

鍵となるのは使い慣れた仕組み：サイズ分類（Size Classes）

Appleが示した解決策は、iOSに既にある size class の体系を引き続き利用することだ。この体系において、画面スペースはピクセルの絶対値ではなく、緊密（Compact）と標準（Regular）という2つの抽象的な分類で測定される。システムはデバイスタイプ、ウィンドウ構成、マルチタスクの状態に基づいて size class を動的に決定する。Appleの推奨は、外側ディスプレイを compact の幅、内側ディスプレイを regular の幅として設計することであり、この2つの基本レイアウトを用意しておけば、さまざまな姿勢における基本的な形態をカバーするのに十分である。ただし、ここには客観的な制約が1つ存在する：内側ディスプレイは縦向きのとき上部と下部の横型バーに戻り、横向きのときは側面の垂直レールを維持する。これらはまったく異なるコントロール配置であるにもかかわらず、システムが内側ディスプレイの幅に割り当てる size class はいずれも単一の値（Regular）でしかない。縦横の向きの切り替えによって生じるこの差異について、ガイドラインは（標準コンポーネントを使用している限り）システムが自動的に処理すると述べているものの、開発者がカスタムコードを必要とする際に内側ディスプレイの縦向きと横向きをどの具体的な変数で判別すべきかについては、全体を通じて説明していない。

開発者が磨き上げる必要があるのは、次の2つの基本形態だけである：

1. compact の幅で無理なく収まる1列レイアウト。
2. regular の幅でゆったりと広がる複数列またはカラム分割のレイアウト。

もう一つ見落としやすい点がある：ガイドラインが求める画面間の一貫性には3つの階層がある。機能の一貫性が第1層、要素の状態の一貫性が第2層——同じトグルスイッチ、同じ選択状態は画面を切り替えても変わってはならない。そして最も重要なのが第3層、「情報の階層構造は変えず」、より大きな内側ディスプレイにおいてコンテンツが真に必要とするときにのみ、「もう1層多く見せる」ことである。

標準のMailアプリを例にとってみよう：

• 閉じた状態（外側ディスプレイ / compact の幅）では、利用可能面積の制約から、リスト（主）と本文（従）のどちらか一方が選ばれ、ユーザーは同時に1つの層のコンテンツしか見ることができない。
• 展開した状態（内側ディスプレイ / regular の幅）では、もともと段階的だった2つの層が同時に現れる：左側にはリストが常駐し、右側には本文が表示される。階層構造は一切変わっておらず、もう1層多く見せているにすぎない——コードの中に「折りたたみ画面の内側・外側」といった分岐をハードコードする必要はないのだ。

外側ディスプレイモード時：単一階層のリストまたは本文が画面を独占し、典型的なcompactサイズの体験にあたる。

内側ディスプレイ展開時：自動的に2カラム表示へと広がり、左の欄がリスト、右の欄が詳細となり、典型的なregularサイズの体験にあたる。

ゲームUIにおける画面をまたぐ処理

「姿勢ごとにレイアウトを特化させない」という原則に対して、ガイドラインは没入型ゲームに例外の余地を残している：画面の向きを横向きまたは縦向きに固定することが許容される。ただし例外には境界がある——姿勢が変化しても、画面全体を満たし続けなければならない。具体的な推奨事項は以下のとおりだ：

• アスペクト比（Aspect Ratio）の調整を優先する：黒帯の追加（letterboxing / pillarboxing）に比べ、画面を自然に活用できるようアスペクト比を優先して調整することが推奨される。黒帯が避けられない場合は、周囲の余白領域（padding area）にアート素材をあしらい、全画面の没入感を醸成する手助けをする。
• スケーリング時もコントロールの一貫性を維持する：UIを調整および拡大縮小する際、テキストやコントロールのサイズは可能な限り一貫性を保つべきである。

最後の2点：どのような場合に全幅表示が可能か、そして開発者は何を修正すべきか

全幅UIとCalculatorの「4×5」から「5×4」への変化

常駐のコントロールバーを必要としないUIについて、ガイドラインは Dynamic Island やステータスバーと衝突しないことを前提に、全幅（Full Width）を埋めるレイアウトを検討することを推奨している。これはスクロールを伴わない没入型のビジュアルUIに非常に適している。

Calculatorを例にとると、iPhone Duoの外側ディスプレイでは全幅いっぱいに広がり、キーのマトリクスはiPhone 16の4列5行から5列4行へと変更されている。上部にある2つの丸いツールボタンは依然として保持されており——全幅にすることがコントロールを空にすることを意味するわけではない。実際のデザインでは、全幅とインセットを組み合わせることも可能だ：例えば背景画像やヘッダーを全幅でいっぱいに広げつつ、内部のスクロール可能なコンテンツはインセットを維持する、といった設計である。

計算機グリッドの進化：左側のiPhone 16は従来の4列5行の縦向きキーを採用し、右側のiPhone Duo外側ディスプレイは5列4行へと再構築され、より幅の広い物理的な外側ディスプレイにより適した形となっている。

開発者とデザイナーのための移行セルフチェックリスト

前述のとおり、標準のシステムコンポーネントを使用し、もともとサイズ調整をサポートしているアプリであれば、基本的に大幅な変更は不要である。以下のチェックリストが対象としているのはもう一方のタイプ、すなわち幅を固定値でハードコードし、独自にレイアウトを描画し、自前でコントロールを配置しているアプリだ。ガイドラインが定めた実装の原則は、次の5項目に集約できる：

1. すべての固定幅（Fixed Widths）を排除する：幅をハードコードしている箇所や、特定の画面に依存しているレイアウトコードはすべてアダプティブに変更し、safe area insets やシステムの layout margins を使用するように改める。
2. テキストのみのボタンは控えめにする：もともとテキストのみの項目を除き、すべてのtoolbar項目にタイトルとアイコンの両方を指定する（Label("タイトル", systemImage: "...")）——システムは overflow menu や展開時の形態でそのタイトルを使用する。
3. 操作の帰属を切り分け、側面にすべてを積み上げない：左側カラムの絞り込みや新規作成は左カラム上部に配置し、右側詳細に対するアクションのみを右側の縦軸に配置して、コントロールと操作対象との近接親和性を維持する。
4. ツール項目の優先度（Visibility Priority）を整理する：アプリ内の1〜2個のコアとなる高頻度アクション（投稿、検索、チェックアウトなど）を特定して最高の表示優先度を割り当て、その他の補助機能はいつでも省略記号の overflow menu に入る準備をしておく。
5. 並列表示とフローティングレイヤーは Arrangement View に委ねる：UI内の既存の並列カードやフローティングコントロールについて、手書きの座標指定やアニメーションをネイティブの split / overlay コンテナに置き換えれば、折り目の退避や展開時の位置移動はシステムが管理してくれるようになる。

結び：デバイスを「巨大化させる」ことからUIを「立ち上げる」ことへ

iPhone Duoに関するこのHIGは、「アプリのビューポートを単に拡大する」という折りたたみスマホ対応の旧来の手法を踏襲していない。画面が幅広で縦に短くなれば、コントロールを垂直に立ち上げる。ハードウェアに折り目が1本増えれば、それをシステムレベルの reserved regions として抽象化する。姿勢の数が数え切れないほど多ければ、これまでどおり size class に委ねて処理する。

これら3つのステップはいずれも、ひとつの姿勢を指し示している：変わるのはレイアウトをどう配置するかであり、変わらないのは「それが依然として1台のiPhoneである」ということだ——ガイドライン自体もそう述べているように、標準コンポーネントを使い、リサイズをサポートしているアプリであれば、基本的に大きな修正は必要ない。真に知恵を絞る必要があるのは、自前でレイアウトを描画し、自前でコントロールを配置している部分である。これらのルールは、デバイスが実際にユーザーの手に渡って初めて検証可能となる——現時点で確定しているのは、Appleがどのように取り組もうとしているのか、という方針だけである。