Designing for iPhone Duo

Apple’s first folding iPhone asks teams to keep one adaptive app across poses and two displays, not invent a separate “foldable mode” per hardware state. Size, aspect ratio, and which face is active will keep changing. The design brief is coherence.

Start with Apple’s own material: iPhone Duo for developers, HIG: Designing for iPhone Duo, and the tech talks Design for iPhone Duo, Raise the bar, and Multiple displays and scenes.

Layout and HIG principles

Treat Duo as many poses of the same product. Prefer system size classes (compact and regular), layout margins, and safe area insets over a custom layout per pose. If you special-case one pose, keep hierarchy and navigation language aligned with the rest so the app still feels like one thing.

Controls move to the outer edge to protect vertical content height. When the device is folded, content should leave the center rather than sit under the crease. Apps that already behave well in Split View and Picture in Picture are closer to ready: they already tolerate resizability and shifting aspect ratios.

Outer display. Safe areas offset content that would otherwise sit behind vertical controls. Immersive, non-scrolling UI may center on the full display. You can mix a full-width background with inset text or chrome: background edge-to-edge, interactive content inset.

Inner display. Use the width: split views and two-column hierarchy fit the larger canvas. Do not squeeze a phone-narrow stack into the middle of a wide inner face by default.

Sheets. On the outer display, sheets pick up vertical controls; on the inner display, horizontal bars remain familiar. When folded, sheets slide so they do not rest in the fold.

Fold avoidance. The system nudges interactive elements off center when the device is partially folded. Keep interactive chrome off the hinge. Scrollable content is the practical exception: people can scroll past the crease; fixed controls cannot.

Goal in one line: one experience that adapts across sizes and poses, not parallel UIs.

Vertical bars as a design-system change

Wider aspects push top and bottom bars toward the side: imagine rotating familiar chrome 90° into a shared vertical bar region. Reach improves on tall outer landscape; inner landscape stays consistent; portrait keeps the horizontal pattern people already know.

This is an opt-in platform behavior when you rebuild on current SDKs and use system navigation containers:

• SwiftUI: NavigationStack / NavigationSplitView plus toolbar APIs
• UIKit: UINavigationController / UITabBarController

Custom UIToolbar, UINavigationBar, or UITabBar content is not included in that automatic move. For a design system, that means: stop treating top and bottom bars as fixed horizontal primitives. Model bar items, overflow, and priority so the same configuration can render horizontally or vertically.

In the shared region, navigation, toolbar, and tab chrome coexist. In split views, only the detail column participates; inspectors do not get their own side bar. Hardware alignment wins even in RTL: the bar stays tied to device edges, not mirrored into a confusing second vertical stack.

Ordering and content rules that matter in Figma and code:

• Top of the vertical stack for back / close
• Prominent actions pinned trailing (same mental slot as before, new axis)
• Prefer symbol-only items; always provide titles for overflow and expanded states
• Badges for counts still apply
• Custom views: AxisBehavior with verticalPreferred vs horizontalOnly when a control cannot compress into a vertical stack

Overflow becomes more common on outer landscape and with the keyboard. Use visibility priority, overflow menus, and (where needed) extra overflow items. Decide deliberately whether toolbar or tab chrome compresses first. Opting out should be rare. Examples Apple cites include bottom-heavy Calculator-like UIs, or a sheet that only needs a close control.

For system designers: audit every screen’s bar configuration as a shared vertical budget shared with Live Activities and the status bar, not as infinite horizontal chrome.

Hinge APIs are not layout APIs

Hinge status and angle APIs are for interactions and effects: parallax, subtle response, pose-aware motion. Layout should follow arrangement and reserved-region APIs (hinge division, camera occlusion, displacement) instead of driving Auto Layout from hinge angle.

Multitasking includes Split View. Multi-window behavior resembles iPad, with an important limit: new windows are not created on the outer display. Scene accessories (including patterns like companion UI on the outer face while the main task runs on the inner, teleprompter-style) are dual-display composition patterns. Treat them as scene roles, not as a reason to redesign the whole app around camera hardware.

What to change in your system first

1. Resizable foundations: columns, stacks, and sheets that already respect size classes and safe areas
2. Bar inventory: migrate to system containers; document which items are required, trailing-prominent, or overflow-first
3. Fold-safe chrome: no primary actions parked on the hinge; fixed UI inset; scrolling content may cross the fold
4. Dual-display roles: only where a second face truly holds a companion task; keep the primary hierarchy on one continuous adaptive layout

Do not start by mocking “folded” and “unfolded” as two brands. Start from compact/regular, safe areas, and a bar item list that survives vertical layout. Pose sketches come after the system rules are clear.