Designing for iPhone Duo: five rules from Apple’s HIG, plus a ten-point checklist

On September 9, 2026, Apple published Designing for iPhone Duo, the only official guidance on the form factor so far. There is no size table and no breakpoint list; the core claim is one sentence: if you use standard system components and lay out with size classes, your app adapts to every pose on its own.

It is worth reading in full, but the amount you actually have to build is small. Below it is broken into five rules, three areas where things usually go wrong, and a checklist.

1. What the device is

iPhone Duo has two displays: the outer display when folded, the inner display when open, each with a front camera.

• The outer display is wider and shorter than other iPhone screens. Its camera sits in a corner, always visible, and extends upward into the area occupied by the Dynamic Island. The system moves toolbars and tab bars to the side, keeping vertical space for content.
• The inner display camera is under the screen and only appears when the camera is in use, with the interface moving aside to make room for it.
• The hinge allows partial folding, lying flat, and standing on an edge. In landscape when open, controls stay on the side so their position is unchanged across displays.

One thing to keep in mind: you are still designing for iPhone, so iOS patterns and best practices still apply.

2. The five best practices

1. Build a resizable app. Use size classes, layout margins and safe-area insets; avoid fixed widths and avoid depending on one specific display.
2. Keep the experience consistent across displays. Function and element state should carry over; the hierarchy may go one level deeper, but it should not become a second design. Apple's example is Mail: folded it shows either the list or a single message, unfolded it shows both side by side.
3. Keep the same functionality in every pose. Controls may overflow and content may move as the interface adapts, but the same controls and content have to remain reachable.
4. Follow the system's vertical control layout. Toolbars, tab bars and navigation controls sit on the side, not at the top or bottom — including landscape on the inner display.
5. Make the game playable in every pose. You may lock portrait or landscape, but fill the screen when the pose changes.

Of the five, rules 1 and 4 come largely for free with standard components; rules 2 and 3 are yours to guarantee.

3. Dynamic layouts: do not design per pose

The guidance is explicit: supporting pose changes does not mean designing a custom layout for each one. Use size classes — compact width on the outer display, regular width on the inner display — and let the existing layout expand into the available space.

What needs extra work is reserved regions:

Reserved region	What it means
Outer camera (always)	Always visible and extending into the Dynamic Island area; the system lays out side controls around it
Inner camera (in use)	The interface moves up to reveal the camera
Fold region (depends on pose)	Partially unfolded, it divides the inner display into usable areas, excluding the centre band

Most system components adapt automatically: alerts, context menus and sheets move with the fold state, and larger components such as split views adjust column widths and margins to the symmetry of the inner display. Custom components need ReservedRegion (SwiftUI) or UIView.ReservedRegion (UIKit) to move content clear.

Three practical rules:

• Adjust on fold rather than rearrange. Move only what has to move and keep it visible and tappable; controls that vanish or jump are hard to track.
• Use an even number of grid columns so a fold divides the content cleanly.
• Prefer containers that adapt themselves. Notes, for example, resizes both split-view panes when the device folds.

4. Split views and arrangement views

A split view expands on the inner display and collapses to a single pane on the outer display, the same way it moves between regular and compact environments on other iPhones. Built with standard components, its widths and margins follow the fold automatically.

Arrangement views are the newer idea in the guide: a container holding a primary and a secondary view, laid out dynamically by size, orientation and reserved regions. There are two kinds:

• Split arrangement: divides horizontally when width exceeds height, vertically otherwise;
• Stacked arrangement: separates the two views to either side when partially folded, and otherwise stacks the primary view over the secondary one.

Existing layouts map onto them: HStack / VStack structures translate to a split arrangement, ZStack structures to a stacked one. Note that an arrangement view arranges content but does not handle navigation — navigation containers such as navigation split views and tab views belong outside it.

5. Vertical controls: the easiest part to get wrong

Because the outer display is wider and shorter, the system places toolbars and tab bars vertically along the side. This is the defining interaction of iPhone Duo and the easiest thing to make feel non-native. The guidance here is the densest, so the highlights:

• Reserve the top of the axis for primary navigation (back, close), then prominent actions (done); keep the remaining items in their existing groups.
• Items stack from bottom to top by default. Adjust with visibility priority: whole groups first, then individual items. Keep frequent actions (Compose in Mail, New Note in Notes) visible.
• Do not override the default bar position. Side controls are a platform convention; moving them makes users relearn your app.
• Interfaces that need no bar can use the full width, like Calculator — or let a background image or title run edge to edge while content stays inset — as long as nothing collides with the Dynamic Island or status bar.
• Group related items with ToolbarItemGroup instead of adding fixed spacing by hand.
• Put controls next to the content they affect. A control that acts on the mailbox stays above the list pane rather than moving to the side.
• Give every non-text item both a title and a symbol (Label), because overflow menus and expanded states use the title.
• When space runs short, keep one bar. In navigation-led experiences, move toolbar items into the overflow menu and keep the tab bar; in task-led experiences, minimise the tab bar and keep the toolbar actions that matter.
• Use the system overflow menu, and reserve the ellipsis for it; other menus need a different symbol.

6. Games: fill the screen, skip the bars

Games get a rule of their own, and it is specific:

• You may lock portrait or landscape, but fill the whole screen when the pose changes;
• Keep text and control sizes consistent as the app resizes;
• Change the aspect ratio rather than using letterboxing or pillarboxing; if one is unavoidable, add artwork in the margin so the experience still reads as full screen.

93.9% of the 214 games in this directory ship as universal iPhone/iPad apps, so they already have a tablet layout. But having a layout and filling the screen are different things — a universal build can still letterbox on a larger canvas, which is exactly where a check shows the difference.

7. What the system handles, and what you handle

Guidance	System?	Check looks at
Size classes and layout	Mostly, with standard components	Whether main screens hold up folded and unfolded
Reserved regions	Yes for standard components; custom ones need the API	Whether content is covered by a camera or the fold
Vertical controls	Yes for standard toolbars and tab bars	Whether side controls stay in place and overflow works
State across displays	No	Whether unfolding or folding loses state or reloads
Full functionality in every pose	No	Whether controls survive a partial fold and stay tappable
Games filling the screen	No	Whether there are bars, and whether touch targets drift

The three criteria behind this directory's “adapted” status — main layouts, the fold transition, and core actions — overlap almost exactly with this guidance. So the records can be read as an executable version of the HIG, and the HIG can be used as a regression checklist for the records.

8. A ten-point checklist

1. No hard-coded widths; everything derives from layout margins and safe areas
2. Compact width on the outer display, regular width on the inner display — not two separate layouts
3. The outer camera, inner camera and fold region never cover content
4. A partial fold moves only what it must; nothing disappears
5. Grids use an even number of columns and divide cleanly
6. Unfolding and folding keep state and do not reload
7. Side toolbar order is right: back/close at the top, done prominent
8. Every toolbar item has a title and a symbol (Label)
9. The compression strategy is explicit: keep the tab bar, or keep the toolbar
10. Games fill the screen in every pose, changing aspect ratio rather than adding bars

9. References

• Designing for iPhone Duo (Apple HIG, published September 9, 2026)
• Preparing your app for iPhone Duo
• Layout, Split views, Toolbars, Designing for games
• APIs: ReservedRegion, ArrangementView, ToolbarItemVisibilityPriority

This article follows the September 9, 2026 version of the page; if Apple updates it, the original wins. If your own app behaves differently from what the guide describes, the feedback form in the footer is the place to tell us.