-
iPhone Duoのアダプティブレイアウトでポーズを決める
iPhone Duoで快適に使えるレスポンシブでフレキシブルなレイアウトを作成する方法を学びましょう。iPhone Duoを開閉する際にコンテンツを見やすく、操作しやすい状態に保つための変位デザインパターンを見ていきます。SwiftUIとUIKitで配置ビューを使って分割表示とオーバーレイ表示を実現する方法を紹介するとともに、予約領域を照会してヒンジやカメラの周囲に合わせてレイアウトを調整する方法についても解説します。
関連する章
- 0:00 - Introduction
- 0:27 - Reserved regions on iPhone Duo
- 1:29 - Designing around the hinge
- 2:26 - Displacement patterns
- 4:00 - Choose where content moves
- 5:12 - Adapt content to its new region
- 6:39 - Query reserved regions
- 7:50 - Division and occlusion regions
- 8:39 - System containers that adapt
- 9:20 - Introducing arrangements
- 11:17 - Build with ArrangementView
- 12:00 - Configure the split arrangement
- 13:21 - Use the overlay arrangement
- 14:39 - Choose between arrangements
- 16:09 - When not to use an arrangement
- 16:34 - Next steps
リソース
関連ビデオ
Tech Talks
-
このビデオを検索
こんにちは Appleのデザインシステム担当の Mariaです HIデザイナーを務めています UIフレームワークエンジニアの Harryです 本日は iPhone Duoの 独自の特性に適合する レイアウトを作成する 方法についてお話しします
その広大な画面は コンテンツに新たな可能性をもたらし アプリをその形状に適合させる 新しい方法を生み出します
iPhone Duoには複数の ディスプレイが搭載されており それぞれに独自のサイズクラスが 設定されています すでにサイズ変更に対応した デザインを行っている方なら この仕組みは馴染み深いもの だと思います 新しいハードウェア機能も 利用可能なスペースの 形成に影響を与えます これには ヒンジや 外側と内側のディスプレイにまたがる 2つのカメラなどが含まれます
これらを予約領域と呼びますが これについては後ほど Harryが詳しく解説します
これらの領域についても レイアウトがすでに適合している 他の領域と同様に扱ってください たとえば iPadOSの ウインドウコントロールなどです 外側のディスプレイのカメラは常に 表示されており システムツールバーやタブバーは セーフエリア内に縦方向に配置されます 「Raise the Bar with iPhone Duo」 をご覧ください そちらでも私が解説しています
内側のディスプレイでは 折り目や アクティブ時の FaceTimeカメラに合わせて インターフェースを 適合させることができます ファインダーがユーザー体験の 中心となる場合は 重要なコンテンツや コントロールをその領域から 離して配置してください レイアウトにおけるヒンジの扱いは これらとは異なります デバイスが本のように 部分的に折りたたまれている 場合 ディスプレイが中央で 湾曲するため 内側のディスプレイは 複数の利用可能な領域に分割されます
Maria この本を見てください 見開き2ページにまたがる この写真を見てください あまり見栄えが良くないですよね？ そうですね のどに近づくにつれて 画像の一部が見えにくくなり 1つの連続した画像として 認識されなくなってしまいます アプリでも同じことが 起こり得るのでしょうか？ もちろんです 折り目部分にまたがる コンテンツやコントロールも 非常によく似た挙動を示します そこで アプリをこうした変化に 適合させ iPhone Duoに 自然に馴染む一連のデザインパターンと ツールを開発しました まずはディスプレイスメントパターンと その背後にあるデザイン原則を 説明します その後 新しいUIパターンである アレンジメントについて お話しします
それでは 始めましょう
iPhone Duo向けの優れたデザインは いつ適合させるかを 把握することにかかっています 多くのインターフェースは 予約領域の周りに自然に配置できますが 一部のインターフェースでは ディスプレイスメントと呼ばれる パターンを活用します より意図的なアプローチとして 既存の要素の枠を 利用可能なスペースに合わせて 調整することで 部分的に折りたたまれていても 重要なコンテンツを 見やすく操作しやすい状態に保ちます 一般的なデザインでは デバイスが開いている状態で 要素が画面の中央に配置されます 折りたたむと その要素は目的に適した 領域に移動します
単一の要素という小さな例から 始めますが ディスプレイスメントの適用範囲は ボタンから コンテナ全体 さらには レイアウトのより大きな部分にまで 広げることができます
コンテンツに最も適した 範囲を選択してください
要素が個別に適合できる場合は その要素だけを移動します また 要素が連携して 機能する場合は 関係を維持するため まとめて移動させます なお 過度な移動には注意してください
要素を元の位置から遠くに 移動させると 視覚的な関係が 弱まってしまいます
たとえば アルバム内の 写真を選択する際 コンテキストメニューを 末尾側の領域で 中央揃えにするのではなく 両方の要素を一緒に移動させ 折り目周辺で位置を揃えます
記事やフィード ドキュメント リストなどの連続スクロール コンテンツは配置を変更しません これらのコンテンツはすでに スクロールで対応しているため 利用可能な領域間で 移動させると 連続性が 損なわれる可能性があります コンテンツの配置を変更する 際は その目的に 基づいて移動先を決めてください デバイスの使用状態によって 適切な配置場所が変わる場合があります 本のように部分的に 折りたたまれている場合 アラートなどの要素は 末尾側の領域に移動します
これにより デバイスが閉じられ 外側のディスプレイで体験が 継続される際に それらが表示される場所に近くなります デバイスをテーブルの上に 立てかけた場合 2つの領域はそれぞれ異なる 種類の体験をサポートします
上部の領域は 離れた場所からでも 視認しやすいコンテンツに適しています 同じアラートも 見つけやすいように ここに移動させることができます
下部の領域は インタラクティブな コントロールに適しています
メディアコントロールなどの タップ可能な要素をここに移動させます タッチ操作のための より安定した領域を提供できます また 複数の領域が適している場合は 文脈に沿った配置を優先してください
iPhoneと同様に 検索フィールドに フォーカスがあるときは キーボードの上に表示されます デバイスが開かれている ときは 検索フィールドはその 余分なスペースを活用します
デバイスが折りたたまれると 幅と位置が調整され 検索対象のビューの上に 表示され続けます 要素をどこに移動させるかを決めたら 新しい環境にどのように 適合させるかを検討します 位置やサイズが 最も一般的な変更点ですが その他の視覚的プロパティも 適合させることができます アクションシート アラート メニュー ポップオーバーはすべて予約領域の上に 表示できる軽量な コンテキスト体験です したがって 主な目標は それらを完全に可視状態に保つことです システムは 予約領域の周囲にある コンポーネントの位置を自動的に 調整します
「リマインダー」のような Split Viewアプリでは システムが両方の列の幅を調整し 50/50の均等な分割になるように 配置することで 両方の列を 常に表示したままにします
この「Fitness」のデザインでは デバイスが折りたたまれても グリッド内のすべての項目が 操作可能な状態を維持したいと考えます 外側の余白を維持しつつ ヒンジ周辺の間隔を広げることで 各コンテナをそれぞれの領域内に 収めることができます
これらの例に共通しているのは すでに存在する 要素を移動、サイズ変更 または再配置している点です
コンテンツ 機能 レイアウトを常に 利用可能な状態に保ち iPhone Duoをどのように 使用していても 完全な体験に アクセスできるようにします これで 予約領域への適合について 考え方が お分かりいただけたかと思います Harry デベロッパが知るべき 新しいAPIはありますか？
素晴らしい質問ですね Maria 新しいAPIほど 私が好きなものはありません 実際 皆さんにお話ししたい 新しいAPIがいくつかあります
SwiftUIでは GeometryReaderや onGeometryChange修飾子から取得した GeometryProxyを使用して 予約領域を照会します GeometryProxyの新しい reservedRegionメソッドを使用すると ビュー内で利用可能な 領域を取得できます 予約領域にはいくつかの種類があります ここでは 折りたたみ部分は 分割予約領域に基づいています これはより 広い領域を複数の小さな領域に 分割しているためです
UIKitでは UIViewで利用可能な reservedRegionメソッドを使用します 予約領域のframeプロパティを 照会することで 独自のレイアウトに 組み込むことができます 領域はアクティブまたは 非アクティブの状態をとれます デフォルトではアクティブな 領域のみが返されますが reservedRegionメソッドの includeInactiveクエリオプションを使用し 非アクティブな領域を 取得することも可能です iPhone Duoでは デバイスが折りたたまれているときのみ 折り目の分割領域が アクティブになります 平らに開いているときは非アクティブで 幅はゼロになります
非アクティブな領域を活用することで アプリに関する高レベルの 判断を行うことができます たとえば グリッド状のレイアウトでは 分割領域が存在する場合 そのアクティブ状態にかかわらず 列数を偶数にすることを優先できます オクルージョン領域と呼ばれる もう1つの予約領域もあります これらは領域を分割するのではなく 領域を遮蔽します ビューの境界内にある 小さなフレームと考えてください iPhone Duoでは FaceTimeカメラが オクルージョン領域として表現されます reservedRegionメソッドに オクルージョンの種類を渡すことで これらを取得できます 折り目の分割領域と同様に この領域はカメラが アクティブなときにアクティブになり カメラが非アクティブなときは 非アクティブになります
ありがとう Harry どんな質問にも的確に 答えてくれますね カスタムビューで予約領域を使うのが 本当に楽しみです 楽しみです しかし システムデザイナーとして 言わせてもらえば 折り目に適合する標準コンポーネントを 活用できることには さらに大きな期待を寄せています
NavigationStacksや NavigationSplitViews TabViewsなど その多くは皆さんご存知かと思います これらのシステムコンテナを使えば ユーザーが アプリ内を移動する際の 一般的なパターンを活用できます また ListやScrollViewといった ビューもあり これらはコンテンツを 格納するコンテナです
Harry 質問があるのですが Split Viewに似た レイアウトがあるのですが 展開や折りたたみの動作は あまり必要ないんです 他に何か使えるものはありますか？ Maria また素晴らしい質問ですね はい もう1つ紹介したいコンテナがあります
レイアウトコンテナは これらのナビゲーションコンテナと コンテンツコンテナの中間に 位置します
これらのレイアウトコンテナは 一連のルールに従って 2つのビューを配置します これらをアレンジメントと呼びます では「配置」や「ルール」とは 具体的に何を指すのでしょうか？ 説明のため「ポッドキャスト」アプリを 開いてみましょう ここでは iPadで ポッドキャストの再生を開始しており ビューが表示されています 右下に を 表示するボタンがあります そのボタンをタップすると トランスクリプトビューが表示され レイアウトが半分に分割されます
iPhone Duoで同じビューを表示しても ほぼ同様の挙動になります デバイスを折りたたんだ後でも同様です iPadのこの分割レイアウトは iPhone Duoにも非常によく適合します もう一度 ボタンを 切り替えるとどうなるか見てみましょう トランスクリプトビューは 再び消えますが ビューは iPadのように 中央には配置されません 折り目によって定義された 左側の領域に収まったままになります
Mariaが話していたように コントロールに簡単に手が届き 視界を遮られることもありません iPhone Duoを縦長に回転させると と トランスクリプトの両ビューは 分割レイアウトを 一切使用しなくなります その代わりに トランスクリプトビューは インライン表示されます したがって ビューの適切な レイアウトを決定するには ビューの水平および 垂直のサイズクラス 幅と高さの比率 アクティブな分割領域の有無など 複数の要素を考慮する必要があります
これらの要素に 基づいて ビューの レイアウトを決定できます 関する決定を下すことができます 例えば そのビューを 表示すべきかどうか 表示する場合のフレームを どう設定するかなどです こうした入力から出力への一連の処理を アレンジメントと呼びます また iOS 27.1では システム提供のアレンジメントを自身の アプリで使用できるようになりました 先ほどMariaが多くの素晴らしい 指摘をしてくれましたが 私もメモを取るべきでした まったくの偶然ですが 私も現在 音声メモアプリの開発に 取り組んでいます 私のアプリでこれらの新しいAPIを どのように活用できるか 紹介します こちらが私の NavigationStackです まず このスタック内に ArrangementViewを追加します ArrangementViewには プライマリビューと セカンダリビューを指定します そこで 現在再生中の音声メモに 関する情報を表示する PlayerViewと 再生終了後に 再生されるメモを表示する UpNextViewを指定します UIKitでは UIArrangementViewControllerを UINavigationControllerの ルートビューコントローラとして 追加します
次に PlayerViewControllerと UpNextViewControllerを ArrangementViewControllerの プライマリおよび セカンダリビューコントローラとして 設定します 希望する配置は arrangementViewStyle修飾子で 設定します デフォルトのスタイルは splitと呼ばれており ここでは手動で指定します
ご想像の通り splitスタイルでは 指定された境界がプライマリビューと セカンダリビューの間で分割されます デフォルトでは ビューの幅が 高さよりも広い場合 アスペクト比の広い iPadで使用する場合や
iPhoneやiPhone Duoで
同様のアスペクト比の場合など 水平方向に分割されます デバイスを回転させると ビューの高さが幅よりも高くなるため splitスタイルでは 垂直方向に分割されます 私の ビューについては 常に水平方向に分割したいと考えます そこで split ArrangementStyleの axesメソッドを使用して 分割する軸を指定します
split Arrangementが 軸に沿って分割できず それがプライマリ軸である場合 ArrangementViewは単一の ビューのみを表示します ここでは ArrangementViewの 高さが幅よりも大きいため PlayerViewのみを 表示します つまり 主軸は垂直ですが 分割できるのは水平方向のみです
UIKitでは UIArrangementViewControllerの updateArrangementメソッドを呼び出し SwiftUIで設定したのと同じ 水平軸で構成された UISplitArrangementを使用します こちらが 分割配置を使用した iPhone Duo上のPlayerViewと UpNextViewです ビューの配置について 別の 配置方法を検討してみたいと思います それはオーバーレイアレンジメントと 呼ばれます コンテンツを並べて 配置するスプリットスタイルとは異なり オーバーレイアレンジメントでは コンテンツを上下に 配置することを優先します ここでは 配置ビューを更新して オーバーレイアレンジメントの スタイルを使用するようにします これをMariaに見せる前に もう少し仕上げたいと思います ので PlayerViewと UpNextViewの位置を入れ替え 折りたたみ状態を追加します
これでうまくいきました
さて デバイスを折りたたむと オーバーレイ配置では プライマリビューとセカンダリビューが 並列に配置される傾向があります これにより UpNextViewに余裕が 生まれますので この 特性を活かしたいと思います オーバーレイ配置を使用する場合 overlayArrangementZIndexという 環境プロパティを照会できます UpNextViewでは ユーザーがデバイスを折りたたんだり 広げたりするたびに この値が 変化します これを利用して UpNextViewの折りたたみ 状態と展開状態を切り替えます
UIKitでは UIArrangementViewControllerの stateForViewPlacementメソッドを使用し 返された状態のZ index プロパティを取得することで プライマリビューのZインデックスを 照会できます Harry 選択肢がたくさんありますね お聞きしたいのですが これらの中からどのように 選択すべきか検討されましたか？
もちろんです まず 既存のアプリパターンに 必ず従うようにしてください HStackやVStackなどの コンポーネントを使用して アプリの一部でスプリットのような レイアウトをすでに 実装している場合は スプリット配置の使用をご検討ください アプリの一部で ZStackなどの コンポーネントを使って オーバーレイ風のレイアウトをすでに 実装している場合は オーバーレイ配置の 使用を検討してください これらのコンポーネントは iPhone Duoに対する 組み込みのサポートにより それぞれの配置に自然に適合します 既存のパターンに依拠できない場合は ビュー間に明確な前景と 背景の関係がある 場合は オーバーレイ配置を 検討してください たとえば こちらの 「アクセシビリティリーダー」 では コントロールが前景にあり 読み取り可能なコンテンツが 背景にあります
読み取り可能なコンテンツは オーバーレイ上をスクロールできるため 時折一部が隠れても問題ありません そのため オーバーレイ配置を 採用するのが最適です
コンテンツ間に「メインと詳細」 という関係性がより強い場合は スプリット配置を検討してください Podcastsの例に戻ると トランスクリプトビューは 現在再生中のポッドキャストに 関する詳細情報を提供しています どちらのコンテンツも決して 隠れてしまわないことが重要ですので ここではスプリット配置を使用するのが 最適な選択です
Maria ちゃんと 聞いていましたか？ 私の音声メモアプリには どの配置を使えばいいでしょうか？ うーん
Up Nextリストは PlayerViewとの背景関係という より 再生状態に関する 詳細情報を提供している ものなので Split ArrangementViewを 使用すべきだと思います その通りです 適切な配置を選択することは重要ですが ArrangementViewが適していない 場合についても考慮してください 例えば ArrangementViewはアプリに ナビゲーション基盤を提供しません ですから NavigationSplitViewなどのコンテナを ArrangementView内に入れるのは避けます また ListやScrollViewといった ビューの性質上 これらのスクロール可能な コンテナ内に ArrangementViewを配置することも 避けてください iPhone Duoでは アプリ向けの 新しい構成が数多く導入されています アプリがiPhone Duoに 対応できるよう準備するには まずアプリのセンター配置レイアウトを 見直してください 2列レイアウトに変更できるか そのユースケースにおいてどのような ディスプレイスメントパターンが 適切かを検討してください
標準のシステムコンテナや プレゼンテーションを使用している場合 多くの動作が自動的に 実現されることに気づくでしょう また よりカスタマイズされた 水平分割レイアウトや オーバーレイレイアウトを 使用している場合は アプリの対応デバイス全体で このレイアウトを処理するために ArrangementViewの 使用を検討してください 最後に ビュー内で 手動レイアウトされた コントロールの中で 優先度の高いものを特定し 必要に応じて ReservedRegions APIを採用して 独自の配置調整を実装することを 検討してください
では レイアウト以外にも ヒンジを活用できるでしょうか？ 試してみたい とても面白い インタラクションのアイデアがあります それは楽しそうですね デバイスの折りたたみ 状態に応答できる別のAPIもあります
詳細については 「Leverage Multiple Displays and Scenes on iPhone Duo」をご覧ください アダプティブレイアウトにより あらゆる姿勢において アプリが丁寧に設計されている と感じさせることができます 体験が向上する場合にのみ 移動やサイズ変更 適合を行います こうした新しい可能性が広がる中 皆さんがどのようなアプリを 構築されるのか楽しみにしています
-
-
6:46 - Query reserved regions in SwiftUI
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .division) } -
7:03 - Query reserved regions in UIKit
// UIKit let regions = view.reservedRegions( kind: .division) // Query the frame to incorporate it into your own layout let frames = regions.map(\.frame) -
7:22 - Include inactive regions
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .division, options: .includeInactive) let frames = regions.map(\.frame) // ... } -
8:07 - Query occlusion regions
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .occlusion) let frames = regions.map(\.frame) // ... } -
11:23 - Add an ArrangementView
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } } } -
11:26 - Add a UIArrangementViewController
// UIKit let arrangementVC = UIArrangementViewController() let navController = UINavigationController(rootViewController: arrangementVC) let playerVC = PlayerViewController() arrangementVC.setViewController(playerVC, for: .primary) let upNextVC = UpNextViewController() arrangementVC.setViewController(upNextVC, for: .secondary) -
12:00 - Specify the split arrangement style
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } .arrangementViewStyle(.split) } } -
12:41 - Restrict the split to one axis
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } .arrangementViewStyle( .split.axes(.horizontal)) } } -
13:07 - Update the arrangement in UIKit
// UIKit let arrangementVC = UIArrangementViewController() // ... arrangementVC.updateArrangement(.split.axes(.horizontal)) -
13:26 - Switch to the overlay arrangement
// SwiftUI var body: some View { NavigationStack { ArrangementView { UpNextView() } secondary: { PlayerView() } .arrangementViewStyle(.overlay) } } -
14:07 - Respond to the overlay Z index
// SwiftUI enum UpNextMinimization { case collapsed; case expanded } struct UpNextView: View { @Environment(\.overlayArrangementZIndex) private var zIndex: Int var body: some View { UpNextList(minimization: minimization) } var minimization: UpNextMinimization { zIndex > 0 ? .collapsed : .expanded } } -
14:21 - Read the Z index in UIKit
// UIKit let arrangementVC = UIArrangementViewController() // ... let primaryState = arrangementVC.state(for: .primary) myModel.minimization = (primaryState?.zIndex ?? 0) > 0 ? .collapsed : .expanded
-
-
- 0:00 - Introduction
Maria, a Human Interface Designer on Apple's design system, and Harry, a UI Frameworks engineer, introduce how to create layouts that adapt to the unique characteristics of iPhone Duo.
- 0:27 - Reserved regions on iPhone Duo
iPhone Duo has multiple displays, each with its own size class, plus hardware features that shape the available space — the hinge and the cameras on the outer and inner displays. These are called reserved regions, and you treat them like any other area your layout adapts to, such as window controls on iPadOS.
- 1:29 - Designing around the hinge
When the device is partially folded like a book, the hinge divides the inner display into multiple usable regions as the display curves through the center. Just as a photo spread across a book's spine stops reading as one continuous image, content and controls that span the fold become harder to see.
- 2:26 - Displacement patterns
Many interfaces flow naturally around reserved regions, while others benefit from displacement — adjusting the frame of existing elements based on available space. Displacement can scope from a single button to an entire container. Move elements independently when they can adapt alone, together when they work as a unit, and avoid excessive movement that weakens visual relationships. Continuously scrolling content like articles and feeds shouldn't displace.
- 4:00 - Choose where content moves
Let purpose guide where content moves, and note that the right destination changes with how the device is used. Partially folded like a book, alerts move to the trailing side, closer to where they'll appear as the device closes. Propped on a table, the top region suits content viewed at a distance while the bottom suits interactive controls. When multiple regions work, keep things contextual.
- 5:12 - Adapt content to its new region
Position and size change most often, but other visual properties adapt too. The system automatically repositions action sheets, alerts, menus, and popovers around reserved regions to keep them fully visible. In a split view like Reminders it keeps both columns visible with an even split, and a grid can preserve outer margins while increasing spacing around the hinge. Throughout, you're moving, resizing, or reorganizing what's already there.
- 6:39 - Query reserved regions
In SwiftUI, query reserved regions with the new reservedRegion method on a GeometryProxy from GeometryReader or the onGeometryChange modifier. In UIKit, use the reservedRegion method on UIView. Query a region's frame to incorporate it into your layout. The fold is backed by a division region, because it divides a larger area into smaller ones.
- 7:50 - Division and occlusion regions
Regions can be active or inactive; only active ones are returned by default, but the includeInactive query option surfaces the rest. The fold's division region is active only when the device is folded, and has zero width when flat — inactive regions still support high-level decisions, like preferring an even number of grid columns. Occlusion regions occlude rather than divide, and represent the FaceTime camera.
- 8:39 - System containers that adapt
Navigation containers like NavigationStack, NavigationSplitView, and TabView provide common navigation patterns, while content containers like List and ScrollView hold your content. Both adapt to the fold for free.
- 9:20 - Introducing arrangements
A layout container sits between navigation and content containers, arranging two views according to a set of rules called an arrangement. Using the Podcasts Now Playing and transcript views as an example, an arrangement is a function of inputs — size classes, the view's aspect ratio, and any active division regions — to outputs, like whether to show a view and what frame it gets. iOS 27.1 makes system-provided arrangements available in your app.
- 11:17 - Build with ArrangementView
An ArrangementView takes a primary and a secondary view — here a player view and an up-next view — and goes inside a NavigationStack. In UIKit, use UIArrangementViewController as the root view controller of your UINavigationController, configuring the primary and secondary view controllers.
- 12:00 - Configure the split arrangement
Set the preferred arrangement with the arrangementViewStyle modifier; the default split style divides its bounds between the primary and secondary views. It splits horizontally when the view is wider than it is tall and vertically when taller. Restrict this with the axes method, and note that when the arrangement can't split along its primary axis it shows only a single view. In UIKit, use the update arrangement method with UISplitArrangement.
- 13:21 - Use the overlay arrangement
Unlike split, the overlay arrangement prefers positioning content above or below, moving to side by side when the device folds. Query the overlayArrangementZIndex environment property to respond as the user folds and unfolds — useful for switching between collapsed and expanded versions of a view. In UIKit, use the state for view placement method on UIArrangementViewController and read the returned state's Z index.
- 14:39 - Choose between arrangements
Follow your app's existing patterns: HStack or VStack layouts translate to the split arrangement, ZStack layouts to overlay. Without an existing pattern, choose overlay when there's a clear foreground/background relationship — as in Accessibility Reader, where partially obscuring scrollable content is acceptable — and split when there's a main/detail relationship, as with the Podcasts transcript where neither view should be obscured.
- 16:09 - When not to use an arrangement
ArrangementViews don't provide navigation infrastructure, so avoid putting navigation containers like NavigationSplitView inside one. Because of how List and ScrollView behave, avoid putting an ArrangementView inside a scrollable container.
- 16:34 - Next steps
Audit your app's centered layouts and consider whether a two-column layout or a displacement pattern fits. Standard system containers and presentations give you a lot of behavior for free. For custom horizontal split or overlay layouts, consider ArrangementView, and adopt the ReservedRegions API for your highest-priority manually laid out controls.