Swiftui Iphone Duo

SwiftUI iPhone Duo

Do not design a separate “Duo version” of the app.

Start with an adaptive SwiftUI interface that works across continuously changing widths and heights. Add Duo-specific behavior only when the fold, hinge, second display, or vertical system bars materially improve the experience.

The target is not “Make this app support iPhone Duo.” The target is:

Make this app excellent at every size, then use Duo's unique hardware where it creates additional value.

Before reviewing or changing layout, read the full rulebook: reference.md.

When to use

• User asks to support iPhone Duo, a foldable iPhone, hinge, fold, or two displays.
• User asks for adaptive SwiftUI layout across compact → wide, including multitasking.
• Code uses UIDevice, UIScreen.main (bounds or scale), idiom, orientation, isDuo, or isFolded for layout.
• Work involves vertical bars, toolbar item ordering/overflow, sheet placement, ArrangementView, reserved regions, onHingeChange / UIHingeInteraction, or CameraCaptureAccessory.
• The project moves to the iOS 27.1 SDK (that build is what turns on full-screen layout and vertical bars).

Related skills

Optimization order

1. Adaptive layout
2. Adaptive navigation
3. Adaptive toolbars and tabs
4. Fold-safe positioning
5. Duo-specific arrangements
6. Hinge-driven interactions
7. Second-display experiences

Progressive API tiers

Classify every change before writing code. Always complete Tier 1 before proposing Tier 2 or Tier 3.

Tier 1 — Universal adaptive improvements (do these first):

NavigationSplitView
adaptive TabView
adaptive grids
ViewThatFits
AnyLayout
size classes
container-relative sizing
system toolbars
safe-area correctness

These benefit all Apple platforms and window sizes.

Tier 2 — Duo-aware layout (only when needed):

reserved regions (reservedRegions(kind:options:))
ArrangementView
vertical bar tuning (axisBehavior, visibilityPriority, compression, toolbarVerticalEdge)
toolbarVerticalBehavior(.disabled), only for the documented exceptions
sheet placement (presentationPlacement)
Duo-specific safe-area handling

Tier 3 — Duo-exclusive experiences (only when the product benefits):

onHingeChange / UIHingeInteraction
hinge angle
CameraCaptureAccessory (scene accessory, camera apps only)
multi-scene workflows (new windows only on the inner display)

Workflow

Copy and track progress:

- [ ] 1. Read reference.md (start with "Platform facts")
- [ ] 2. Check the SDK: full-screen layout and vertical bars need an iOS 27.1 SDK build (Xcode 27.1)
- [ ] 3. Review screens with the decision tree
- [ ] 4. Flag red-flag patterns with file evidence
- [ ] 5. Classify each change as Tier 1 / 2 / 3
- [ ] 6. Implement Tier 1 first
- [ ] 7. Apply Tier 2/3 only when space-based layout is insufficient; gate 27.1 APIs with #available
- [ ] 8. Keep state above adaptive layout; verify continuity across widths and every pose in Device Hub

1) Review existing UI

Walk every SwiftUI screen with the decision tree below. Flag:

• Device identity used as a layout switch (UIDevice, idiom, model, isDuo, isFolded)
• UIScreen.main (bounds, scale, stored screens) or orientation used for ordinary layout
• horizontalSizeClass == .regular treated as "iPad"
• Size read once (at launch or in viewIsAppearing) and never re-read
• Fixed column counts, hardcoded sidebar widths, arbitrary if width > N
• Separate compact vs expanded view hierarchies with duplicated state
• Custom toolbars / tab bars that cannot move to a vertical edge
• Toolbar items with a title but no icon, or a custom "..." menu instead of the system overflow menu
• Critical content that would sit on the fold
• Wide layouts that only stretch instead of exposing hierarchy
• Hinge angle used to decide sidebar, columns, or navigation

2) Implement or refactor

1. Replace device checks with container space: size classes, ViewThatFits, AnyLayout, adaptive grids, containerRelativeFrame / onGeometryChange.
2. Prefer NavigationSplitView for collection → selection → detail. Prefer adaptive TabView over a hand-built sidebar: .tabViewStyle(.sidebarAdaptable) plus .defaultTabBarPlacement(.sidebar) opts into the sidebar on the inner display (on iPhone, .sidebarAdaptable alone shows a tab bar).
3. Prefer system .toolbar / ToolbarItem / ToolbarOverflowMenu inside a NavigationStack / NavigationSplitView so bars can become vertical. Give every item a title and an icon; put Close (.cancellationAction) first and Done (.topBarPinnedTrailing) next; set visibilityPriority.
4. Keep one view hierarchy; hoist navigation, scroll, selection, editor, and playback state above layout.
5. Use extra width for panes, inspectors, columns, and persistent navigation — not longer text lines. Cap readable content (e.g. .frame(maxWidth: 700)).
6. Move fold-sensitive controls locally. Do not rebuild the whole screen because a reserved region appeared.
7. Use ArrangementView only for one two-part experience (player + playlist, editor + inspector). Do not use it as app navigation.
8. Use onHingeChange / hinge angle only for physical interaction. Layout reacts to space. Interaction may react to hinge state. For fold-aware layout, use reserved regions or ArrangementView.
9. Do not target innerDisplay / outerDisplay as independent canvases. The only supported outer-display content is a CameraCaptureAccessory during an active camera capture session.
10. Check every sheet in every pose; choose placement with presentationPlacement(_:).

3) Untestable Duo behavior

Xcode 27.1 includes the iPhone Duo simulator (Device Hub: open, close, rotate, fold). It can't run most app extensions and has no camera, so camera capture accessories need a device.

Until the specific behavior can be checked in the simulator or on a device:

The agent may:

• improve general adaptability
• remove device assumptions
• adopt standard adaptive containers
• prepare code boundaries for Duo-specific APIs
• identify likely fold-sensitive UI

The agent should avoid:

• hardcoding predicted hinge coordinates
• guessing exact Duo dimensions
• adding untested Duo-only layout branches
• restructuring working screens around assumptions

If Duo-specific behavior cannot yet be verified in the simulator or on a device, prefer preparation over speculative implementation.

Agent decision tree

When reviewing a SwiftUI screen, evaluate it in this order.

1. Does the layout work across continuously changing widths?
   If no: fix the general adaptive layout first.

2. Is navigation manually switching between phone and tablet implementations?
   If yes: investigate NavigationSplitView, adaptive TabView, or another system navigation container.

3. Are there fixed widths or screen-size assumptions?
   If yes: replace them with container-relative layout where possible.

4. Does the wide layout simply stretch?
   If yes: look for a sidebar, detail pane, inspector, additional columns, or supplementary content.

5. Could important content intersect the fold?
   If yes: use reserved-region-aware positioning.

6. Are two related views being manually rearranged across layouts?
   If yes: evaluate ArrangementView, ViewThatFits, or AnyLayout.

7. Is there a custom toolbar or tab bar, or toolbar items without an icon?
   If yes: determine whether SwiftUI system bars can replace it and adapt vertically, and give every item a title and an icon.

8. Does the requested behavior genuinely depend on physical hinge position?
   If no: do not use the hinge API.
   If yes: use onHingeChange (UIKit: UIHingeInteraction) and hinge.status / hinge.angle.

9. Would the outer display provide useful supplementary information during camera capture?
   If yes: evaluate a CameraCaptureAccessory. Otherwise, do not try to target the second screen.