/iphone-duo-design-review

name: iphone-duo-design-review
description: Review or design an iOS interface for iPhone Duo's poses — closed, open, book-folded, tabletop and tent — covering side-mounted controls, asymmetric layouts, fold avoidance, sheets, and how to use the inner display well. Use for design critique, mockup review, or deciding what a screen should look like on a foldable iPhone rather than how to code it.

Designing for iPhone Duo

A design skill, not an implementation one. For APIs, see the sibling skills.

Closed, iPhone Duo is compact, familiar and pocketable. Open, it is the largest canvas ever on an iPhone. It gets held and set down in many ways: partially folded like a book, seated on a table like a laptop with the inner display facing the user, or standing on its edges.

The governing principle

**One app that adapts — not several designs stitched together.**

Users open and close this device constantly, often mid-task. If the hierarchy or the available functions change between inside and outside, they have to re-orient every time. So:

• Never tie functionality to a pose. Everything reachable in one pose is

reachable in all of them.

• Keep the hierarchy identical across displays.
• If you do build a pose-specific layout, it keeps the same controls and the same

general hierarchy as the others.

Design to two size classes, not to poses

The temptation is a custom layout per pose. Resist it. Design to:

• **Compact width** — the outer display
• **Regular width** — the inner display

Avoid fixed widths, breakpoints, or any metric tied to a specific screen. Build with layout margins and horizontal safe area insets and the adaptation mostly happens on its own. The honest summary: **design the app to be freely resizable** and iPhone Duo is largely handled.

The one optional layout worth considering is the **tabletop pose** — media up top, tappable controls on the stable base below. It suits hands-free use. It is optional, and it still owes users the same controls as every other pose.

Controls on the side

Closed, the display is wider and shorter than a traditional iPhone. Controls that would sit at the top and bottom move to the **right side**, freeing vertical space and landing within easy reach of the thumb. To their left is an uninterrupted content area comparable to a conventional iPhone screen.

That side region is shared. It holds the tab bar, app toolbars, navigation controls like back, the redesigned status bar, and the Dynamic Island — which now expands *vertically* as Live Activities arrive. When room runs short, app controls collapse into an overflow menu automatically.

Mapping an existing iPhone app across is mostly mechanical:

• Toolbar buttons from the top → top of the vertical region
• Toolbar buttons from the bottom → bottom of the vertical region
• Tab bar → stays bottom-aligned

**Exception:** items too wide for that side region — a text button, a segmented control — should stay in the navigation bar. Don't force them.

**The one pose that keeps horizontal bars is the inner display in portrait**, where vertical space is plentiful.

In **Split View**, controls sit along the *outer* edge: an app on the left gets its controls on the left edge, keeping them thumb-reachable and away from the center.

Asymmetry

Side-mounted controls make most layouts asymmetric. Three approaches, chosen by content type:

**Offset content.** The default. Most content needs offsetting so it isn't hidden behind the controls — and if the design aligns to horizontal safe area insets, this happens automatically.

**Center on the full display.** No offset. Right for immersive, highly visual, non-scrolling interfaces — but only when you are certain no interactive element lands under the controls.

**Mix them.** A full-width background image or header behind inset, scrollable foreground content. The rule that makes this safe: **every interactive element lives inside the scrollable inset area**, so nothing tappable can be covered.

The fold

Partially folded, the inner display curves through the center. Content automatically moves away from that region — text and images shift aside to stay readable, and interactive elements move to the sides where they're easier to hit. The curve becomes a natural divider for the layout.

In portrait, folded, interactive elements move to the **bottom half**, easier to reach while the device rests on a surface.

**Buttons are genuinely hard to tap in the fold.** The system nudges interactive elements aside whenever the device is partially folded, and this behavior is built into sheets, alerts, menus, toolbar buttons and more. Use system components and you inherit it.

**Scrollable content is exempt.** It does not need to avoid the fold region.

The design goal is simple: keep interactive elements out of the curve as much as possible.

Two refinements when you do adapt to the fold:

**Prefer containers that adapt themselves.** A split view that rebalances its pane widths handles the fold better than anything you position by hand. In grids, prefer an **even number of columns** so content divides cleanly either side of the centre.

**Move as little as possible.** Controls that vanish or jump across the screen as someone bends the device are hard to find and harder to track. Favour small adjustments that keep things visible and tappable over rearranging the layout.

Using the inner display well

A stretched-out iPhone app is the failure mode. Three approaches that work:

**Split views.** Surface multiple levels of hierarchy at once. The nuance worth getting right: your information hierarchy must stay the same across displays, but you may reveal *one more level of it* on the larger display. A mail app showing either the message list or a single message when closed, and both side by side when open, is the same hierarchy with more of it visible — not a different app. That is the distinction between adapting and reinventing.

Standard split views also a