iPhone Duo のデザイン：動くもの、分かれるもの、留まるもの

iPhone Duo 向けのデザインには何が必要でしょうか。 必要なのはポーズごとのレイアウトではなく、2つのレイアウトです。「外側ディスプレイ用の compact width レイアウトと内側ディスプレイ用の regular width レイアウトがあれば、すべてのポーズに対応する基礎が整います」とされ、Apple 自身のアドバイスは「アプリを自由にリサイズできるように設計する」ことです。(4:32)¹² この土台の上に、ガイドと3本の Tech Talk が説明する4つのパターンが乗ります。コントロールはディスプレイの側面へ移動し、上から下への順序を保つ。コンテンツは意図的にフルブリードにする場合を除き、そのコントロールからオフセットされる。インタラクティブな要素は折り目から離れるように変位するが、スクロールするコンテンツは変位しない。そして新しいコンテナである arrangement が、ルールに従って2つのビューを分割または重ね合わせる。最後の2つを支える API はトークで解説されており、arrangement は iOS 27.1 で登場します。³

Apple は基調講演当日の午後、Human Interface Guidelines に Designing for iPhone Duo を公開し、あわせてデザイン向けの Tech Talk を3本公開しました。「Design for iPhone Duo」「Strike a pose with adaptive layouts on iPhone Duo」「Raise the bar with iPhone Duo」の3本です。¹²³⁴ 本サイトの開発者向け記事では、ポイント数の計算と SDK のルールを扱いました。この記事で扱うのは、ガイドが求めるデザイン上の判断です。Apple 自身の言葉を各トークのタイムスタンプ付きで引用し、それを自分のアプリでどう扱うつもりかをまとめます。

TL;DR: 2つのサイズクラス向けにデザインし、ポーズの処理はシステムに任せましょう。バーは外側ディスプレイの側面と、横向きの内側ディスプレイで縦方向になります。縦向きの内側ディスプレイだけは、横方向のバーのままです。⁴ アイコンを持つ項目は縦方向へ、テキストのみの項目は横方向のまま。縦バーの最上部は Back または Close のための場所で、その次に Done のような目立つアクションが続きます。⁴ コンテンツは、没入型でスクロールしない場合を除き、水平方向のセーフエリアを通じてバーからオフセットされます。² 折り目まわりでは、ブックポーズで「アラートのような要素は trailing 側へ移動」(4:09) し、テーブルに置いたポーズではインタラクティブなコントロールが下半分へ移動します。一方で「記事、フィード、ドキュメント、リストのような連続的にスクロールするコンテンツは変位しません」(3:46)。³ arrangement は新しいレイアウトコンテナで、split か overlay のいずれかです。選び方のルールは、すでに使っているものそのままです。水平または垂直のスタックは split に、ZStack は overlay になります。³

パターンの前に、ひとつのルール

3本のうち2本のトークとガイドが、同じ一文を繰り返しています。デザインの出発点にすべき一文です。Apple のデザインチームの Vince はこう述べています。「人々は iPhone Duo をさまざまなポーズで使います。そのすべてでアプリが美しく見えてほしいはずです。しかしそれは、ポーズごとにカスタムレイアウトを作るという意味ではありません。そうではなく、2つのサイズクラスに集中してください。外側ディスプレイの compact width と、内側ディスプレイの regular width です。固定幅やブレークポイント、特定の画面に紐づいた数値は避けてください」(3:50)。² ガイドもポーズの節で同じことを述べています。¹ Vince はもう1つ、任意のレイアウトを挙げます。ノートパソコンのようにテーブルへ置いた状態向けのもので、「メディアを上部に置き、タップ可能なコントロールは下部の安定した土台に配置できます」(4:48)。ただし「他のポーズと同じコントロールと全体的な階層を備えている」(4:57) ことが条件です。²

Apple の2026年9月9日のイベント配信より、太平洋時間 午前11時05分のフレーム。スタンディングポーズです。ガイドが挙げるリストは「本のように部分的に折りたたむ、面に置く、縁で立てる」となっています。

以下の内容はすべて、この土台を前提としています。リサイズ可能な iPhone のチェックリストが点検し、iPad のリサイズ対応の記事が解説しているのと同じ土台です。レイアウトがサイズクラス、レイアウトマージン、セーフエリアインセットから組み立てられているなら、Vince の約束はこうです。「あなたのアプリはすでに iPhone Duo に適応しているはずです」(4:27)。²

側面：何が移動し、何が留まるか

外側ディスプレイでは、これまで上下にあったコントロールが「垂直方向のスペースを最大化し、右手の親指で届きやすくするために、ディスプレイの右側へ移動」します (1:18)。² 側面が受け持つのは、タブバー、ツールバー、Back のようなナビゲーションコントロール、ステータスバー、そして「Live Activities が届くと垂直方向に展開する」Dynamic Island です (1:48)。² 内側ディスプレイでは、横向きのときバーは縦のままで、縦向きになると横方向に戻ります。縦向きは「横方向のバーを残した唯一のポーズ」(5:27) であり、その理由は「アプリのコンテンツのための垂直方向のスペースが十分にある」(5:32) からです。² Split View では、「アプリが左側にあるとき、コントロールもディスプレイの左端へ移動します」(3:11)。² さらにバーはハードウェアに合わせて配置されるため、「右から左に書く言語でも、デバイスの同じ側に留まります」(4:21)。⁴

Apple の2026年9月9日のイベント配信より、太平洋時間 午前10時59分のフレーム。内側ディスプレイをこちらに向けて途中まで折られたデバイスと、その右端にあるサイドマウントのコントロールです。

あるコントロールが縦方向になるかどうかは、2つの要素で決まります。1つめはコンテナです。UI Frameworks の Anna はこう述べます。「TabView や NavigationStack のようなナビゲーションコンテナが提供するバーを使っていることを確認してください」(2:19)。カスタムの UIToolbar、UINavigationBar、UITabBar インスタンスのコンテンツは「考慮されない」(2:58) からです。⁴ スプリットビューでは「detail カラムのみが対象となり」(3:43)、インスペクタは「独自のバーを持ちません」(3:53)。⁴ 2つめは項目のコンテンツです。縦バーは「項目の高さが可変で、幅は固定」(6:10) であり、そのため「シンボルのみの項目表現に適しています」(6:13)。⁴ したがって「back や share ボタンのようにアイコンを持つ項目は、軸を縦方向に変えます。edit ボタンのようなテキストのみの項目は、横方向の軸に留まり続けます」(7:06)。⁴ Vince による言い換えは、デザイナー向けのものです。「テキストボタンやセグメンテッドコントロールのように、右側のスペースに対して幅が広すぎるツールバー項目は、iPhone Duo でもナビゲーションバーに留めるべきです」(6:22)。²

順序のルールは短いものです。「最上部は back や close のような主要なナビゲーションコントロールのために確保し、その次に done のような目立つアクションを置いてください」(4:47)。⁴ SwiftUI では、カスタムの Back や Close に cancellationAction プレースメントを使い (5:02)、目立つアクションには topBarPinnedTrailing を使います (5:24)。UIKit では、leading の項目に対して leftItemSupplementsBackButton をデフォルトの false のままにしておき (5:06)、目立つアクションには pinnedTrailingGroup を使います (5:27)。⁴ それ以外は元のグループ分けを保ち、「縦方向のスペーサーが上部と下部のプレースメントを視覚的に分離します」(5:34)。⁴

バーのトークが示す、個々の項目についてのルールです。それぞれ手がかりとなる一言を添えます。⁴

• カスタム項目の判定基準：「それは単にシンボルを補強しているだけなのか、それとも単独で情報を担っているのか」(9:36)
• 件数はバッジに入れます。そうすればテキストとシンボルの項目がシンボルのみの項目になり、「縦バーになじみます」(9:23)。一方で「金額を表示するカートボタン」は横方向のままです (9:52)。
• Edit のようにシンボルとテキストを切り替える項目は、横方向のままです。システムの Edit ボタンはすでにそうなっており、カスタムのものには横方向のみの AxisBehavior を指定します (8:11、8:32)。
• カスタムビューや複雑なビューは、デフォルトでは横方向に留まります (8:40)。「縦方向の表現に対応している」(8:48) 場合は、縦方向を優先する axis behavior を指定することでバーに入れられます (8:54)。
• シンボルを表示する項目にも、必ずタイトルを付けてください。「項目がオーバーフローメニューや展開表示に移動するたびに、システムがそれを使う」(7:44) からです。
• キーボードアクセサリバーは「縦方向の軸へ移動させるのではなく、キーボードに付いたままにすべきです」(10:00)。
• カスタムビューは toolbarVerticalEdge 環境プロパティ（UIKit ではトレイト）を読むことで、縦バーが存在するかどうかを判断できます (10:35)。

オーバーフローはデザイン上の優先順位が表れる場所であり、トークは5つのルールを挙げています。⁴

• 「デフォルトでは、項目は下から上へオーバーフローします」(13:23)。各項目には high、low、またはカスタムの表示優先度を持たせられます。優先度はまず「グループ単位で」(13:36) 割り当て、その後グループ内で割り当てます。優先度とオーバーフローの API は WWDC26 で追加されたツールバー関連の API で、本サイトの iOS 27 SwiftUI の記事で扱いました。13:49 では、SwiftUI の新機能に関する Apple の WWDC26 セッションが案内されます。
• 何から先に圧縮するかを決めます。ナビゲーション中心のビューでは「ツールバーが先に圧縮され、主要な遷移先にアクセスできる状態が保たれます」(12:07)。これがデフォルトです。タスク中心のビューでは「頻繁に使うアクションを残すために、タブバーが先に圧縮されます」(12:18)。指定には toolbarCompressionBehavior を使います (12:22)。
• アプリ独自のオーバーフローメニューは、システムのものに統合します。SwiftUI では ToolbarOverflowMenu、UIKit では additionalOverflowItems を使い (12:36、12:43)、省略記号はオーバーフロー専用に留めます (12:53)。
• 「Mail の Compose や Notes の New Note のような頻繁に使うアクションは、オーバーフローへ移動するのが最も遅い部類であるべきです」(13:59)。
• バッジの付いた項目は「ひと目で把握できる状態を保つために、より長く表示されたままであるべきです」(14:11)。

縦バーは必須ではありません。Calculator のように単一ページで下部が重いレイアウトや、Close のようなツールバー項目が1つだけのシートでは、toolbarVerticalBehavior または preferredVerticalBarBehavior でバーをオフにできます (14:28、14:37、14:47)。⁴

中央に置くか、オフセットするか

バーが片側に寄ることで、「多くのレイヤーが非対称になります」(6:33)。² Vince は3つの配置を挙げます。ほとんどのコンテンツは、コントロールの背後に隠れないようオフセットを取ります。「アプリが水平方向のセーフエリアインセットに沿っていれば、そのオフセットは自動的に適用されます」(6:58)。² 一部の UI は、オフセットなしでディスプレイ全体の中央に配置されたままになります。これは「スクロールしない没入型で視覚性の高いインターフェースに適しています。ただし、インタラクティブな要素が右側のコントロールに遮られないと確信できる場合に限ります」(7:10)。² そして両者を混ぜる形もあります。「全幅の背景画像やヘッダーと、インセットされたスクロール可能な前景コンテンツ」(7:22) という組み合わせで、条件は「インタラクティブな要素がすべてそのスクロール領域の内側にあり、何も覆われないこと」(7:28) です。² ガイドのセーフエリアに関する注記は、Split View のケースを付け加えています。反対側の端にはもう一方のアプリのコントロールが来る可能性があるため、セーフエリアは両端で意味を持ちます。¹

折り目：displacement（変位）

Apple の2026年9月9日のイベント配信より、太平洋時間 午前11時08分のフレーム。ディスプレイのレイヤー構造です。部分的に折りたたんだとき、中央を走る曲面がガイドの言う「folding region」にあたります。

Apple のデザインシステムを担当する Human Interface Designer の Maria は、原則から話を始めます。「iPhone Duo の優れたデザインは、いつ適応させるかを知ることにかかっています」(2:25)。³ 多くのインターフェースは「reserved region のまわりを自然に流れることができます」(2:30)。それ以外は displacement（変位）を使います。これは「利用可能なスペースに基づいて既存の要素のフレームを調整し、デバイスが部分的に折りたたまれていても、重要なコンテンツが見え、手が届き、遮られない状態を保つ」ものです (2:39)。³ このパターンには「ボタン1つからコンテナ全体、あるいはレイアウトのより大きな部分まで」(3:03) という適用範囲があり、2つのルールが伴います。「要素が単独で適応できるなら、単独で動かしてください。要素どうしが連携している場合は、その関係を保つために一緒に動かしてください」(3:17)。そして「過度な移動には注意してください」(3:26)。「要素を元の位置から遠くへ動かすと、視覚的な関係が弱まる」(3:29) からです。³ Maria の例は、選択した写真に対するコンテキストメニューです。メニューを trailing 側の領域の中央に置くのではなく、「2つの要素が一緒に動き、折り目のまわりで揃います」(3:39)。³

例外は、デザイナーが最も頼ることになるものです。「記事、フィード、ドキュメント、リストのような連続的にスクロールするコンテンツは変位しません。こうした体験はすでにスクロールによって適応しているため、利用可能な領域のあいだで動かすと連続性が途切れるおそれがあります」(3:46)。³ Vince は逆の側から同じことを述べます。システムがインタラクティブな要素を曲面の外へ押し出すのは、「ボタンが折り目のちょうど上に来るとタップしづらい」(9:28) からです。この挙動は「シート、アラート、メニュー、ツールバーボタンなど」(9:40) に組み込まれており、「スクロール可能なコンテンツはこの領域を避ける必要がありません」(9:57)。²

折り目の向きが領域を決めます。ブックポーズでは折り目が垂直に走り、領域は左と右になります。テーブルに置いた場合や縦向きでは、折り目が水平に走り、領域は上と下になります。²³ 変位した要素がどこへ行くかはポーズによって決まり、その理由を語る Maria の説明が有用な部分です。ブックポーズでは「アラートのような要素は trailing 側へ移動します。こうすることで、デバイスを閉じて体験が外側ディスプレイへ続くときに表示される位置に近づきます」(4:09)。³ テーブルに立てかけた場合は「上側の領域は、離れた場所からの視認性が活きるコンテンツに適しています」(4:29)。そして「下側の領域はインタラクティブなコントロールに適しています」(4:39)。「メディアコントロールのようなタップ可能な要素はここへ移動でき、タッチに対してより安定した面を提供します」(4:43)。³ 原則を扱うトークも同じことを述べています。縦向きで部分的に折りたたんだ状態では、「インタラクティブな要素がディスプレイの下半分へ移動し、デバイスを面に安定させたまま手が届きやすくなります」(2:33)。² 複数の領域が候補になる場合は、文脈に沿わせます。検索フィールドは、デバイスが開いているときに「余分なスペースを活用し」(5:00)、折りたたまれるにつれて「検索対象のビューの上に留まるよう、幅と位置が適応します」(5:04)。³

この大半はシステムが処理します。「アクションシート、アラート、メニュー、ポップオーバーはいずれも軽量な文脈的体験であり、reserved region の上に表示されることがあります」(5:23)。そしてシステムが「reserved region のまわりでコンポーネントの位置を自動的に調整します」(5:34)。³ スプリットビューは「幅を調整し、均等な 50/50 の分割に配置することで、両方のカラムを表示したままにします」(5:40)。³ 自分で受け持つのはグリッドです。Maria による Fitness のデザインでは、「外側のマージンを保ちながらヒンジまわりの間隔を広げ、各コンテナをそれぞれの領域内に収められます」(5:56)。³ すべての例に対する Maria のまとめが、そのままデザインの指針になります。「私たちがしているのは、すでにそこにあるものを動かし、サイズを変え、並べ替えることです。人々が iPhone Duo をどう使っていても体験の全体にアクセスできるよう、コンテンツ、機能、レイアウトを利用可能な状態に保ってください」(6:04)。³

Reserved region：変位を支える仕組み

Maria はアダプティブレイアウトのトークで、この用語を導入します。「新しいハードウェアの特徴も、利用可能なスペースの形を決める役割を果たします。ヒンジと、外側および内側ディスプレイにまたがる2つのカメラです。これらを reserved region と呼びます」(0:37)。そして、これらを「レイアウトがすでに適応している他の領域とまったく同じように」(0:53) 扱うよう勧めます。例として挙げるのは iPadOS のウィンドウコントロールです。³ reserved region は3つあります。外側カメラ、アクティブなあいだの内側カメラ、そして折り目です (1:00、1:18、1:32)。³ それぞれについてのガイドの定義と、ガイドがこれらの API のドキュメントをリンクしていないという私の確認結果は、開発者向け記事にまとめてあります。そのためこの節では、仕組みの側に絞ります。¹ UI Frameworks のエンジニアである Harry が、API を説明しています。「SwiftUI では、GeometryReader または onGeometryChange モディファイアから得た GeometryProxy を使って reserved region を問い合わせます。geometry proxy の新しい reservedRegion メソッドを使うと、そのビューで利用可能な領域を取得できます」(6:38)。UIKit では「UIView で利用できる reservedRegion メソッドを使います」(7:03)。そして「reserved region の frame プロパティを問い合わせて、自分のレイアウトに組み込めます」(7:07)。³

種類は2つあります。折り目は「より大きな領域を複数の小さな領域に分割するため、division の reserved region に支えられています」(6:55)。そして「デバイスが折りたたまれているときにのみアクティブになります。平らなときは非アクティブで、幅はゼロです」(7:26)。³ カメラは occlusion の領域です。こちらは「領域を分割せず、代わりに遮ります」(7:54)。領域は「カメラがアクティブなときにアクティブになり、カメラが非アクティブなときに非アクティブになります」(8:12)。³ 非アクティブな領域は includeInactive オプションで問い合わせられます。Harry がそれを見るべきだと言う理由は、デザイン上の判断にあります。「グリッド状のレイアウトでは、division の領域が存在する場合、そのアクティブ状態にかかわらず偶数のカラム数を選びたくなることがあります」(7:41)。³ ガイドもこれをルールとして繰り返しています。¹ 基調講演当日の太平洋時間 午後4時15分の時点で、ガイドはこれらの API のドキュメントページをリンクしておらず、Apple の開発者向けページは Xcode 27.1 beta を「今月後半」としています。¹⁵

Arrangement：split か overlay か

Apple の2026年9月9日のイベント配信より、太平洋時間 午前11時00分のフレーム。Apple が80パーセント大きいと呼ぶ内側ディスプレイ、すなわち arrangement が対象とするキャンバスです。

Harry の定義はこうです。「レイアウトコンテナは、ナビゲーションコンテナとコンテンツコンテナのあいだに位置します。これらのレイアウトコンテナは、一連のルールに従って2つのビューを配置します。これを arrangement と呼びます」(9:20)。³ ルールが受け取る入力は「ビューの水平・垂直のサイズクラス、ビューの高さに対する幅のアスペクト比、そしてアクティブな division の領域があるかどうか」(10:37) です。出力は「そもそもビューを表示すべきか」(10:52)、表示するなら「そのフレームはどうなるか」(10:54) です。³ そして時期についてはこうです。「iOS 27.1 では、システムが提供する arrangement を自分のアプリで使えます」(11:02)。³

SwiftUI では ArrangementView が primary と secondary のビューを受け取り (11:25)、スタイルは arrangementViewStyle で設定します (11:57)。UIKit では UIArrangementViewController が primary と secondary のビューコントローラを受け取ります (11:39)。³ デフォルトである split スタイルは「ビューが高さより幅の方が大きいときは水平に分割し」(12:13)、高さの方が大きいときは垂直に分割します。片方の軸に限定することもできます。主軸で分割できない場合は「単一のビューのみを表示することを選びます」(12:49)。³ overlay スタイルは「コンテンツを上下に重ねて配置することを優先します」(13:31)。デバイスが折りたたまれると「primary と secondary のビューを横に並べて配置することを優先します」(13:51)。ビュー側は overlayArrangementZIndex 環境プロパティでこれを検知し、折りたたんだ形と展開した形を切り替えられます (14:01)。³

2つの使い分けは、このトークで最も明快なアドバイスであり、ガイドもそれを採用しています。「アプリの一部で HStack や VStack のようなコンポーネントを使って、すでに split に近いレイアウトを実装しているなら、split arrangement の利用を検討してください。ZStack のようなコンポーネントを使って、すでに overlay に近いレイアウトを実装しているなら、overlay arrangement の利用を検討してください」(14:44)。³ 既存のパターンがない場合、overlay を使うのは「ビューのあいだに明確な前景と背景の関係があるとき」(15:10) です。Accessibility Reader で読み物の上にコントロールが重なるような場合が該当します。split を使うのは「主と詳細の関係に近いとき」(15:32) で、ポッドキャストとその文字起こしのように「どちらも決して隠れないことが重要」(15:43) な場合です。³ 2つの制約、すなわち arrangement の内側ではなく外側にナビゲーションコンテナを置くことと、List や ScrollView の内側に arrangement を置かないことは、トークの 16:15 と 16:26 にあります。ガイドが述べているのは前者だけで、その一文は開発者向け記事に引用しています。¹³

内側ディスプレイ：3つの誠実なレイアウト

「単に引き伸ばした iPhone アプリでは物足りません」(7:39)。² Vince は3つの形を示します。1つめはスプリットビューで、「アプリ階層の複数のレベルを同時に」(7:46) 見せます。条件は、その階層が「外側ディスプレイと内側ディスプレイで変わらない」(7:51) ことです。人々は「アプリの使用中にデバイスを頻繁に開閉する可能性があるため、内と外で予測可能かつ一貫している必要がある」(7:59) からです。² 2つめは Music にならったリフローで、「垂直に積み重ねたレイアウト」(8:15) が「水平方向のスペースが増えたときに2カラムのレイアウト」(8:18) になります。² 3つめはタブバーを「内側ディスプレイでサイドバーとして」(8:26) 見せる形で、「Health のこの例のような情報密度の高いアプリに最も適しています」(8:33)。² ガイドの Mail の例はスプリットビューのケースです。閉じているときはリストかメッセージのどちらか、開いているときは両方を横に並べます。¹

シートには独自のルールがあります。外側ディスプレイでは「シートのコントロールも側面へ移動します」(8:46)。ツールバーボタンが1つだけのシートではこれをオフにでき、その場合「シートは前面カメラの手前で止まり、ステータスバーが自ら位置を変えます」(9:04)。² 内側ディスプレイでは、シートはデフォルトで「標準的な横方向のバーを使います」(9:13)。デバイスが部分的に折りたたまれているときは「折り目に重ならないよう横へずれます」(9:20)。² バーのトークは、配置に関する例外を付け加えています。内側ディスプレイのシートは「デフォルトで中央に配置され、項目は横方向のままです」(4:03)。ただし preferredPlacement API を使うと、「左に配置されたシートは縦バーを持たないままで、右に配置されたシートは縦バーを受け取ります」(4:11)。⁴

点検リスト

バーのトークとアダプティブレイアウトのトークは、それぞれ点検リストで締めくくられています。ここでは1つにまとめます。バーのトークの締めのリスト (15:10) はこうです。縦バーは SDK によるオプトインなので、最新の SDK でビルドすること (2:06)。バーとその順序を点検し (4:41)、カスタム項目が縦方向にレイアウトできるよう更新すること。そして「システムが適応できるように」(15:26) 表示優先度を割り当てること。⁴ 続いて、アダプティブレイアウトのトーク (16:40) からはこうです。「まずアプリの中央寄せレイアウトを点検することから始めてください。2カラムのレイアウトにできるか、あるいはそのユースケースではどの displacement のパターンが妥当かを検討します」。標準のコンテナとプレゼンテーションを使い、無償で得られる挙動を活かすこと (16:49)。カスタムの split や overlay のレイアウトには ArrangementView を使うこと。そして「ビューの中で手動でレイアウトしているコントロールのうち、最も優先度の高いものを特定し、必要に応じて ReservedRegions API を採用して独自の displacement を実装することを検討してください」(17:06)。³

これをどう使うつもりか

私のアプリのうち3つは iPhone アプリで、ガイドはそれらをきれいに仕分けてくれます。以下の仕分けは Apple のものではなく、私自身の読み方です。

• Get Bananas はリストです。リストは変位しません。システムのコンテナを使い続けている限り、タブバーとツールバーは自動的に側面へ移動します。唯一のデザイン上の判断は表示優先度です。項目を追加するアクションが私にとっての Compose なので、最後までオーバーフローさせないべきものになります。
• Reps は各セットを、重量、レップ数、記録アクションの行として記録します。ワークアウト中はグリッド表示になり、これはまさに Maria の Fitness の例です。判断はこうです。ブックポーズでは3カラムの行だと真ん中のカラムがヒンジに乗ってしまうため、グリッドは2カラムのペアに変えます。テーブルポーズでは、記録アクションを下半分に置きます。トレードオフは、1セットあたりタップが1回増えることと引き換えに、ターゲットが決して折り目に乗らないことです。Vince の言うとおり、折り目では「ボタンはタップしづらい」(9:28) のです。² レストタイマーは上部に留めます。Maria が「離れた場所からの視認性が活きるコンテンツ」(4:29) に適していると述べている領域です。³
• Return はヘルスチャートを描画します。これはスクロールコンテンツです。現在チャートとその範囲ピッカーが垂直スタックに並んでいる箇所は、Harry のルールに従えば split arrangement に対応します。これならデバイスが折りたたまれても、両方が見えたままになります。チャート自体は決して変位させるべきではありません。

要点

デザイナー向け： - ポーズではなく、2つのサイズクラスで考えます。外側は compact width、内側は regular width です。¹ Apple のデザイナーが挙げる唯一の任意の追加は、同じコントロールを保ったテーブル用レイアウトです。² - アイコンは縦方向へ、テキストは横方向のまま。サイドバーの最上部は Back または Close、その次に Done。頻繁に使うアクションとバッジ付きの項目は、最後にオーバーフローさせます。⁴ - スクロールコンテンツは決して変位しません。アラート、メニュー、シート、コントロールは変位し、その行き先は目的に従います。アラートはブックポーズでは trailing 側へ、テーブルポーズでは上側の領域へ。タッチ操作するコントロールは下半分へ移動します。²³

デザインエンジニア向け： - 折り目は division の領域で、折りたたまれているときのみアクティブになり、平らなときは幅ゼロです。内側カメラは occlusion の領域で、カメラがアクティブなときのみアクティブです。どちらも GeometryProxy または UIView から問い合わせられます。³ - arrangement は iOS 27.1 で登場します。スタックは split に、ZStack は overlay になり、ナビゲーションコンテナはその外側に置きます。³ - ナビゲーションコンテナが提供するシステムのバーを使ってください。そうしなければ、縦方向のレイアウトは決して起きません。⁴

よくある質問

ポーズごとにレイアウトが必要ですか。

いいえ。Apple は2つのサイズクラス、つまり外側ディスプレイの compact width と内側ディスプレイの regular width に向けてデザインし、固定幅やブレークポイント、画面に紐づいた数値を避けるよう述べています。¹² デザインのトークが挙げる唯一の任意の追加は、同じコントロールと階層を備えたテーブルポーズ用のレイアウトです。²

iPhone Duo で横方向のまま留まるコントロールはどれですか。

テキストのみの項目、セグメンテッドコントロールのようにサイドバーには幅が広すぎる項目、Edit のようにシンボルとテキストを切り替える項目、そしてキーボードアクセサリバーです。さらに、選択すれば、下部が重い単一ページのアプリやツールバー項目が1つだけのシートでは、バー全体を横方向のままにできます。²⁴

displacement（変位）とは何ですか。

デバイスが部分的に折りたたまれているときにも要素が見え、手が届く状態を保てるよう、既存の要素を動かし、サイズを変え、並べ替える Apple のパターンです。アラート、メニュー、ポップオーバー、シート、ツールバーボタンは、システムから自動的に適用されます。スクロールコンテンツは対象外です。²³

arrangement view と reserved region の API はいつ登場しますか。

アダプティブレイアウトのトークによれば、システムが提供する arrangement は iOS 27.1 で自分のアプリでも使えるようになります。Apple の開発者向けページは、Xcode 27.1 beta を9月後半としています。デザインガイドは、どちらの API についてもまだドキュメントをリンクしていません。¹³⁵

スクロールコンテンツは折り目を避ける必要がありますか。

いいえ。デザインのトークもアダプティブレイアウトのトークも、スクロールコンテンツを対象外としています。スクロールによって、すでに適応しているためです。²³

出典