-
iPhone Duoでさらなる高みへ
iPhone Duo独自のディスプレイに合わせて、ナビゲーション、ツール
バー、タブバーを適応させる方法を紹介します。新しいバーレイアウトの背景にあるデザイン原則を見ていくとともに、カスタムビュー表現を設定してオーバーフローを管理し、パワフルでレスポンシブなアプリを作る方法を学びましょう。関連する章
- 0:00 - Introduction
- 0:28 - Why bars move to the side
- 1:29 - Agenda
- 2:00 - Opt in to vertical bars
- 3:09 - Understand the shared bar region
- 4:29 - Order items in a vertical bar
- 5:56 - Prepare toolbar content
- 8:00 - Control the axis of an item
- 9:00 - Prefer symbol-only items
- 10:07 - Adapt custom views
- 11:40 - Manage the overflow menu
- 13:10 - Prioritize item visibility
- 14:21 - When to opt out
- 14:53 - Next steps
リソース
関連ビデオ
Tech Talks
WWDC26
WWDC25
-
このビデオを検索
こんにちは UIフレームワークチームの エンジニアのAnnaです そして Appleのデザインシステムを 担当する ヒューマンインターフェース デザイナーのMariaです ええ なぜ私が ここにいるのでしょうか？ すべてのデザイナーはエンジニアであり すべてのエンジニアはデザイナーです 優れたアプリを作るには その両方を理解する必要があります 本日は Annaと私が iPhone Duoにおける バーのデザイン水準をさらに 高める方法について説明します iPhone Duoは Apple初の マルチディスプレイ対応iPhoneであり その場の状況に合わせて自由に 使いこなせる自由度を提供します
一目見ただけで お気づきになると思いますが これまでとは異なり 新しく独特なシルエットを採用します そして その形状は重要です アスペクト比が広くなったことで アプリにはより多くの横方向の スペースが確保されました その幅を最大限に活かし コンテンツ用の縦領域を確保するため 通常は上部や下部に 配置されるコントロールが側面に 移動し より操作しやすくなっています
この新しいデザインにより 外側のディスプレイ上の 縦方向のコンテンツスペースが 最大化されます また iPhone Duoを 内側ディスプレイで 横向きに開いた場合でも その位置は一貫して維持されます しかし デバイスを縦向きに開くと 大きなディスプレイは 水平バーを備えた馴染みの配置に 戻ります
なお これらは同じ コンポーネントであり 異なるレイアウトに 適合させただけです その基本原則を 理解したところで iPhone Duo上で 優れたバー体験の設計と実装で 考慮すべき点を紹介します まず 新しい軸への対応として iPhone Duo上で バーを縦方向に配置する 方法について説明します 次に 項目の順序や さまざまなコンテナとの 相互作用について解説します その後 縦軸に合わせて ツールバーのコンテンツを最適化する 方法を紹介します 最後に オーバーフローメニューの 管理方法を詳しく取り上げます
でもAnna その話に入る前に 開発中のアプリを 見せてもいいですか？ もちろん すでにサイズ変更に対応する 作業は完了しています ただし バーは 横向きのままです 何か見落としているでしょうか？
任せて、Maria アプリを新しいバーの動作に 対応させるには いくつか手順が必要です まず 最新のSDKを使用して アプリを再ビルドします これで Mariaのアプリは iPhone Duoに対応できます 再ビルド時に他にどのような動作が 有効になるかの詳細は 「Prepare Your App for iPhone Duo」をご覧ください 次に TabViewや NavigationStackなどの ナビゲーションコンテナが 提供するバーを 使用していることを 確認してください SwiftUIでは toolbar修飾子を NavigationStackや NavigationSplitViewなどの コンテナと組み合わせて 使用してください UIKitでは 独自のバーを管理する UINavigationControllerや UITabBarControllerの 使用を推奨します たとえば カスタムUIToolbarを 作成するのではなく ビューコントローラに ツールバー項目を設定し それをナビゲーションコントローラーに 配置してください カスタムバーの構築に使用する場合 UIToolbarや UINavigationBar UITabBarなどの サブコンポーネントの項目は 考慮されません アプリ内でバーを縦向きに 移動させる方法を理解したところで 次は コンテンツの配置について 詳しく見ていきましょう iPhone Duoでは ナビゲーションコントロールや ツールバー タブバーのコントロールが 共有領域内で 共存できます これをイメージするには 90度回転させて 縦方向に積み重ねた状態を考えます レイアウトに応じて これらがさまざまな組み合わせで 含まれる場合があります こちらのアプリでは ツールバーが使用されますが アプリでは レイアウトにタブバーが含まれます また アプリでは ツールバーとタブバーの 両方が使用されています より複雑なレイアウトでは ツールバーの項目は そのコンテナが画面の端に沿って 配置されている場合のみ 垂直方向に移動できます スプリットビューでは 詳細列のみが対象となります
他の列の項目は横方向のままです また 詳細列には すでに縦方向のバーがあるため 混乱を避けるため インスペクタを展開しても 独自のバーは表示されません
外側のディスプレイでは シートにツールバーがある場合 それが縦方向に表示されます 内側のディスプレイでは デフォルトで中央に配置され 項目は横方向のままです preferredPlacement APIで 位置を変更する場合 左側に配置されたシートには 縦方向のバーは追加されず 右側に配置されたシートに バーが表示されます また バーはハードウェアに 連動しているため 右横書き言語の環境でも デバイスの同じ側に表示されます バー自体は固定され コンテンツ側が適合します 要約すると すべての コントロールの軸を変えるのではなく コンテナとの関連性を 常に維持してください 縦向きに表示された項目は 上から下への明確な 階層構造を保ちます まずは既存のツールバー構成を 確認し コントロールが推奨順序に 従っていることを確認します 上部はやなどの 主要ナビゲーション用に確保し 続いてなどの 目立つアクションを配置します
ナビゲーションコントローラを 使用する場合 ボタンは自動的に追加されます カスタムのやを 使用する場合は SwiftUIのcancellationAction 配置を使用します また UIKitでは leadingアイテムを使用し leftItemSupplementsBackButtonを falseに設定します これはデフォルト値です leftItemSupplementsBackButton？ 誰がこんな名前を 付けたのでしょう？ 私ではありません
目立つアクションには SwiftUIの topBarPinnedTrailing配置や UIKitの pinnedTrailingGroupを使用し 配置してください 残りのアイテムは 1つのバーに統合されても 上部と下部の配置を視覚的に分ける 縦のスペーサーによって 元のグループが維持されます
すべてのポーズでバーが縦向きに 配置されるわけではない点に注意します iPhone Duoを使用する際に アクションの配置を 覚え直す必要がないように コントロールの配置を一貫させます 配置場所を理解したところで ツールバーのコンテンツの 準備を確認しましょう 水平にアイテムを配置するバーには 馴染みがあるでしょう iPhone Duoでは それが縦向きに配置されます 高さが固定され幅が可変の 水平バーとは異なり 縦方向のバーでは 高さが柔軟に設定でき 幅が固定されています そのため 縦方向のバーは シンボルのみの表示に適しています シンボルのみの表示に適しています 通常 アプリではツールバーの項目に アイコンとタイトルの2つを 指定します コンテキストやアイテムの 指定内容に応じて システムが表示形式を選択します 既存の上下のバーに アイテムが表示される場合 このボタンのように アイコン表示が優先されます ボタンのように アイコンがない場合は テキストが表示されます アイテムが オーバーフローメニューに入ると タイトルとアイコンの両方が 表示されます
この動作は縦方向のバーでも 変わりません
水平バーと同様に 同じコンテンツを指定し 同じアイテムを配置します 違いは システムがコンテンツに 縦軸と横軸のどちらが適しているかを 判断するようになった点です
やなどの アイコンを持つアイテムは 縦軸に移動します
一方 ボタンのような テキストのみのアイテムは 引き続き水平軸に留まります すでにSwiftUIのLabelや UIBarButtonItemのプロパティで タイトルや画像を設定しているなら 縦方向のバーへの対応準備は ほぼ完了しています 一般的には あらかじめすべての情報を渡し コンテキストに応じてシステムに 最適な表示形式を 選ばせるのが理想的です
つまり コンテンツが画像であっても タイトルを指定することは重要です 水平バーの場合と同様に アイテムがオーバーフローメニューや 展開表示に移る際に システムはこのタイトルを使用します デフォルトでは SwiftUIとUIKitは テキストのみのアイテムか シンボル付きテキストかなど 内容に基づいて配置場所を推測します このデフォルトの動作を 調整する必要がある場合は 新しいAxisBehavior APIが 用意されています いくつかの状況で役立ちます
関連するアイテムは 同じ軸上に配置するべきです 典型的な例は の このボタンのように シンボルとテキストの間で 切り替わるアイテムです このアイテムは理論上 シンボルを縦向きにできますが 縦方向のバーには 配置するべきではありません システムのボタンを使っていれば 特別な設定は不要です 自動的に水平バーに配置されます
シンボルとテキストの間で 切り替わるカスタム項目を作るなら このカスタム選択ボタンのように 水平軸のみの動作を指定してください 一方 ビューが UIKitのカスタムビューや 複雑なビューである場合 システムは水平に維持します 右上のコンパスビューのように カスタムビューが 縦方向の表示に対応している場合は 縦方向優先の動作を設定して 縦方向のバーに配置できるようにします テキストのみの項目や テキストと画像の両方を表示する カスタムビューを最小限に抑え より多くの項目を 縦方向に配置できるようにします ほとんどの場合 これらは シンボル表示への移行に適しています たとえば カウントをインラインで 表示し続ける代わりに 受信トレイでバッジを使うことで テキストとシンボルの両方を表示する アイテムを 縦方向のバーに馴染む シンボルのみの項目に 変換できます iOS 26で追加された バッジAPIをまだ 使用していない場合は すべてのデバイスで システム標準のバッジ外観を得るために ぜひ導入してください カスタムビューにテキストが必要かを 判断する良い方法は そのテキストが単にシンボルを 補強しているだけなのか それとも 独自の情報を伝えているかを 自問することです テキストが単なる補足情報なら シンボルだけでアクションを明確に 伝えることができます しかし カートボタンに金額が 表示されるなど テキストに意味のある 情報が含まれている場合は コントロールを水平バーに 残しておくのが適しています 最後に アクセサリバーは 垂直軸に移動させるのではなく キーボードに 固定されたままにしておきます
カスタムビューを縦方向に 配置できるようにするには 少し準備が必要です アイテムを配置する際は バーの固定幅に収まるか 縦向きに適合したレイアウトであるかを 確認してください 縦方向の表示に合わせて メトリックを調整する 必要があるかを検討してください たとえば このカスタム アクションパネルは 他のコンテンツのスペースを 確保するために 縦表示時にはタイトルを隠し 高さをわずかに抑えています 特にカスタムビューの場合 縦方向のバーが表示されているときに 変更を加えたい場合があります それを知るには toolbarVerticalEdge 環境プロパティまたは トレイトを参照してください これは コンテンツビュー内または アイテムのカスタムビュー内で 読み取ることができます この値は アイテムが 垂直軸上に配置可能な場合に設定され 配置できない場合は nil または未指定となります
水平バーと同様に 垂直バーも デフォルトでは スクロールエッジ効果が適用されません ただし という アクセシビリティ設定が有効な場合は 背景が表示されます いずれの場合でも カスタムビューのコンテンツが 常に読みやすい状態を 保つようにしてください デフォルトでは フレキシブルスペーサーの 垂直軸上のサイズは0です 一方 固定スペーサーは 引き続き最小サイズを維持します
バーが水平か垂直かに関わらず アプリで余分なスペースを 追加しないようにしてください
Maria WWDC25の動画でこのことについて 話していましたね？ ええ、その通りです ご視聴ありがとうございました まだアプリでバーを新しい デザインに更新していない場合や 各アイテムを先頭および末尾に沿って グループ化していない場合は 今が絶好の機会です 最後に オーバーフローの処理について お話ししましょう 横向き表示の外側のディスプレイでは 縦方向のスペースが限られるため アイテムが オーバーフローしやすくなります また キーボードが表示されたり 開いた縦向きで ピクチャ・イン・ピクチャを使うなど 他のUIと競合する場合 ツールバーもオーバーフローする 必要があります まず決定すべきは ツールバー項目と タブバーのどちらを より長く表示し続けるかということです
こののような ナビゲーション中心の画面では ツールバーが最初に 圧縮されるため 主要な移動先への アクセスが維持されます これがデフォルトの動作です このアプリのような タスク指向の画面では 頻繁にアクセスされる アクションを維持するために タブバーが最初に圧縮されます toolbarCompressionBehavior APIを 使用して 各ビューのアプリ優先設定を 構成してください ツールバーについては さらに考慮が必要です 管理すべき項目が増えるにつれ どの項目を表示し続けるか 優先順位を付ける必要があります すでにアプリ独自のオーバーフローが ある場合は そのアクションをシステムが 管理する単一メニューに統合します これには SwiftUIの ToolbarOverflowMenuや UIKitの additionalOverflowItemsを使用します また 既存メニューすべてを オーバーフローにする必要はありません 三点リーダー（…）は iPhoneにおける 標準的なオーバーフローの記号です 他のプラットフォームの記号を 導入するのではなく この目的のために確保し 他のメニューには 別のシンボルを割り当ててください 適切なコンテンツを長く表示し 続けるためには システムに 優先順位を明確に伝えます タブバーを優先している場合や ツールバーの利用可能スペースを 超えている場合 項目はオーバーフローメニューに 移動し始めます ツールバーの表示優先度により どの項目を表示し 続けるかを細かく制御できます
デフォルトでは 項目は 下から上へと折りたたまれますが 各項目に 高 低 または カスタムの優先度を割り当てることで
折りたたまれる順序を 制御することも可能です 項目内では まずグループごとに 優先順位を付けてください 必要に応じて 各グループ内の項目に 優先順位を付けます この優先順位を設定するには SwiftUIとUIKitの visibilityPriority API を使用してください 詳細については WWDC26の 「What's New in SwiftUI」を ご確認ください 表示優先度を割り当てる際は 最も頻繁にアクセスする 項目について検討してください のや のなど 頻繁に使用されるアクションは 最後にオーバーフローに 送るべき項目です 同様に バッジが付いた項目など 重要な状態を伝える コントロールは 一目で状況が 把握できるよう より長く 長く表示されたまま 維持する必要があります Maria バーが縦方向に 配置される理由はわかりましたが どこでも縦方向にするべきですか？
ほとんどのアプリでは この配置が適しています ただし アプリによってはこの 動作を無効にしたい ケースもあります
のように 下部に 要素が集中したレイアウトの シングルページアプリの場合は 水平レイアウトにすることで コンテンツを完全に 展開できるかを検討してください
同様に ボタン1つのみなど シートにコントロールが 1つだけ集中している場合は 利用可能な領域を狭めないよう 垂直バーの無効化を 検討してください これを無効にするには toolbarVerticalBehaviorや preferredVerticalBarBehavior APIを 使用してください すべては 単純な疑問から始まりました バーが必ずしも上部や 下部にある必要はないのではないか？
答えは バーが移動したということです 横へ それほど遠くではありません これにより コントロールへの アクセスを確保しつつ コンテンツのゆとりある 印象を保ちます 馴染み深い操作感を維持しながら まったく新しいiPhoneを実現しました アプリを対応させる第一歩は 最新のSDKを使用して アプリをビルドすることです アプリ内のバーを確認し 新しいデザインに 対応していることを確認してください カスタムアイテムがある場合は 縦方向に配置できるよう更新します また システムが適合できるよう オーバーフローの優先順位を必ず 割り当ててください 他に何かありますか？ オーバーフローメニューにあります またお会いしましょう！
-
-
2:24 - Use system containers for vertical bar in SwiftUI
var body: some View { NavigationStack { ContentView() .toolbar { ToolbarItem(placement: .bottomBar) { ... } } } } -
2:39 - Use navigation containers for vertical bar in UIKit
// Content from a custom bars (UINavigationBar, UITabBar, UIToolbar) // won't be considered. Prefer UINavigationController // and UITabBarController, which manage their own bars. let toolbar = UIToolbar() toolbar.items = [...] -
5:00 - Place a back or close button
// SwiftUI .toolbar { ToolbarItem(placement: .cancellationAction) { ... } } // UIKit navigationItem.leftItemsSupplementBackButton = false navigationItem.leadingItemGroups = [UIBarButtonItemGroup(...)] -
5:24 - Place prominent actions
// SwiftUI .toolbar { ToolbarItem(placement: .topBarPinnedTrailing) { ... } } // UIKit navigationItem.pinnedTrailingGroup = UIBarButtonItemGroup(...) -
8:08 - Set a preferred axis for a custom view
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarItem { ProfileView() } .axisBehavior(.verticalPreferred) } } // UIKit let item = UIBarButtonItem(customView: ProfileView()) item.axisBehavior = .verticalPreferred -
8:36 - Keep an item in the horizontal bar
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarItem { SelectOrDoneButton() } .axisBehavior(.horizontalOnly) } } // UIKit item.axisBehavior = .horizontalOnly -
8:52 - Allow a custom view go in vertical bar
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarItem { CompassView() } .axisBehavior(.verticalPreferred) } } // UIKit let item = UIBarButtonItem(customView: CompassView()) item.axisBehavior = .verticalPreferred -
9:27 - Use badges
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarItem(...) { InboxButton() .badge(7) } } } // UIKit let item = UIBarButtonItem(...) item.badge = .count(7) -
10:36 - Read the vertical bar edge
// SwiftUI struct ContentView: View { @Environment(\.toolbarVerticalEdge) var edge var body: some View { switch edge { ... } } } // UIKit switch traitCollection.verticalBarEdge { ... } -
12:23 - Configure toolbar compression behavior
// SwiftUI var body: some View { TabView { Tab("Recents", systemImage: "clock") { ContentView() .toolbarVerticalCompressionBehavior(.prefersToolbarItems) } } } // UIKit navigationItem.verticalBarCompressionBehavior = .prefersBarItems -
12:43 - Use system overflow menu
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarOverflowMenu { Button("Scan") { ... } Button("Connect") { ... } } } } // UIKit navigationItem.additionalOverflowItems = UIDeferredMenuElement({ provider in provider(self.persistentOverflowItems()) }) -
13:21 - Set item visibility priority
// SwiftUI var body: some View { ContentView() .toolbar { ToolbarItem { Button(...) { ... } } .visibilityPriority(.high) } } // UIKit let item = UIBarButtonItem(...) item.visibilityPriority = .high -
14:47 - Disable the vertical bar
// SwiftUI var body: some View { NavigationStack { ContentView() .toolbarVerticalBehavior(.disabled) } } // UIKit class MyViewController: UIViewController { override var preferredVerticalBarBehavior: UIVerticalBarBehavior { .disabled } }
-
-
- 0:00 - Introduction
Anna from UI Frameworks and Maria, a Human Interface Designer on Apple's design system, introduce how to raise the bar for your app's bars on iPhone Duo.
- 0:28 - Why bars move to the side
iPhone Duo's wider aspect ratio gives apps more horizontal space. Controls that normally sit at the top and bottom move to the side, preserving vertical space for content and putting controls within easier reach. Their position stays consistent on the inner display in landscape, and returns to a familiar horizontal layout in portrait.
- 1:29 - Agenda
An overview of what's ahead: orienting bars to a vertical axis, item ordering and how it interacts with containers, tailoring toolbar content for a vertical axis, and managing the overflow menu.
- 2:00 - Opt in to vertical bars
Rebuild your app against the latest SDKs, then use bars provided by navigation containers. In SwiftUI, pair the toolbar modifier with NavigationStack or NavigationSplitView. In UIKit, prefer UINavigationController and UITabBarController over custom UIToolbar, UINavigationBar, or UITabBar instances, whose content isn't considered.
- 3:09 - Understand the shared bar region
Navigation, toolbar, and tab bar controls coexist in a shared region — imagine rotating them 90 degrees into a vertical stack. In split views, only the detail column participates and inspectors don't get their own bar. Sheets behave differently per display, and because the bar is aligned with the hardware it stays on the same side in right-to-left languages.
- 4:29 - Order items in a vertical bar
Keep controls associated with their container and audit your existing configuration. Reserve the top for primary navigation like back or close, followed by prominent actions such as done. Use the cancellation action placement in SwiftUI, or a leading item with leftItemSupplementsBackButton set to false in UIKit. Place prominent actions with topBarPinnedTrailing or pinnedTrailingGroup.
- 5:56 - Prepare toolbar content
Vertical bars have a fixed width and flexible item height, making them better suited to symbol-only items. You still specify the same icon and title, but the system now also considers whether content suits a vertical or horizontal axis: items with an icon go vertical, while text-only items stay horizontal. Always provide a title, since the system uses it in overflow menus and expanded forms.
- 8:00 - Control the axis of an item
The new AxisBehavior API adjusts the system's default placement. Keep related items on the same axis — an item that transitions between a symbol and text, like a custom select button, should use the horizontal-only behavior. Custom or complex views stay horizontal by default; set the vertical-preferred behavior when your view does support a vertical representation.
- 9:00 - Prefer symbol-only items
Minimize title-only items and custom views showing both text and an image so more content can go vertical. A badge can turn a text-and-symbol item into a symbol-only one — adopt the badge API added in iOS 26. Ask whether the text merely reinforces the symbol or carries standalone information; keep controls like a cart button showing a dollar amount in the horizontal bar.
- 10:07 - Adapt custom views
Custom views need to either fit the bar's fixed width or have a vertically adapted layout, and some metrics may need adjusting. Read the toolbarVerticalEdge environment property or trait to detect a vertical bar. Vertical bars have no scroll edge effect by default but do get a background when reduce transparency is enabled. Flexible spacers are zero size vertically, while fixed spacers respect their minimum.
- 11:40 - Manage the overflow menu
Items overflow more often on the outer display in landscape, or when competing UI like the keyboard appears. Decide whether your toolbar items or tab bar stay visible longer — toolbars compress first by default, suiting navigation-focused experiences, while task-oriented apps may compress the tab bar. Consolidate any custom overflow into the system menu with ToolbarOverflowMenu or additionalOverflowItems, and reserve the ellipsis for overflow only.
- 13:10 - Prioritize item visibility
Items overflow from bottom to top by default, but visibility priority gives fine-grained control. Assign high, low, or custom priorities using the visibilityPriority APIs, starting with groups and then items within them. Frequently used actions like Compose or New Note should be among the last to overflow, and controls conveying status such as badged items should remain visible to preserve glanceability.
- 14:21 - When to opt out
Most apps are good candidates for vertical bars, but a single-page app with a bottom-heavy layout like Calculator may let content expand better horizontally, and a sheet with only one control such as a close button may not warrant the reduced space. Use the toolbarVerticalBehavior and preferredVerticalBar behavior APIs to disable it.
- 14:53 - Next steps
Build your app with the latest SDKs, audit your bars for the new design, update custom items so they're ready to be placed vertically, and assign overflow priorities so the system can adapt.