On 9 September Apple added Designing for iPhone Duo to its Human Interface Guidelines, alongside the Tech Talks. It is the first written design guidance for the device. This is what it asks for, in our words, with links to the changes each point implies for your app.
The short version
- Build to resize, not per pose. Size classes, layout margins and safe areas carry a layout through every pose.
- Controls move to the side. Toolbars, tab bars and navigation sit in a side column on the outer display and on the inner display in landscape. Only the inner display in portrait keeps horizontal bars.
- Give every toolbar item a title and a symbol, and decide which items survive when the column runs out of room.
- Plan for three reserved regions: the outer camera, the inner camera while it is active, and the fold.
- Keep content off the fold with small adjustments, not wholesale rearrangement.
- Games may lock orientation, but must still fill the screen in every pose.
Poses are a size problem
People hold iPhone Duo partly folded like a book, lay it flat, or stand it on its edge. Apple is clear that supporting those poses does not mean designing a layout for each. Between two displays, the poses and Split View, your app will appear at many sizes, and size classes are what let one layout adapt to all of them. Fixed widths and code that assumes a particular display are what break.
That is the same advice as driving layout from size classes, and it is why the inner display’s regular width matters more than its pose.
One experience across both displays
Opening or closing the device should never change what the app can do or lose the user’s place. Functionality and the state of every element stay the same across displays. The larger inner display may show one more level of hierarchy, and that is the only difference.
Apple’s example is Mail. Closed, it shows either the message list or a message. Open, it shows both side by side. Nothing is gained or lost, only arranged differently.
Where the controls go
This is the most visible design change, and the easiest to underestimate. On iPhone Duo, the controls usually found at the top and bottom of the screen move into a column at the side:
| Display and orientation | Controls |
|---|---|
| Outer display (closed) | Side column on the right, within reach of the right thumb — the outer display is wider and shorter than other iPhones |
| Inner display, landscape | Side column — kept so controls stay where they were when closed |
| Inner display, portrait | Horizontal bars — there is enough height for them |
| Split View on the inner display | Each app puts its controls along its own outer edge |
The column holds the Dynamic Island and the status bar as well as the toolbar and tab bar. Apple’s Design Tech Talk adds how existing controls map across: toolbar buttons from the top of the screen go to the top of the column, buttons from the bottom go to the bottom, and a tab bar stays bottom-aligned. Items too wide for the column, such as a text button or a segmented control, stay in the navigation bar. Because it is aligned with the hardware, it stays on the same edge next to the camera, including in right-to-left languages. Standard system bars get this placement automatically. Apple asks you not to override it: controls in a familiar position are part of what makes an app feel native on the device.
Two exceptions are worth knowing. Immersive layouts that do not scroll, such as Calculator, can use the full width, as long as nothing collides with the Dynamic Island or the status bar. And controls that belong to one content area, like the list controls above Mail’s message list, stay with that area rather than moving into the column.
At the top of the column go primary navigation controls such as Back and Close, followed by prominent actions such as Done. See preparing toolbars for vertical layout for the APIs.
When the column runs out of room
A column holds fewer items than a row, so overflow becomes a design decision rather than an accident:
- Items overflow from the bottom up by default. Change the order with visibility priorities, set on whole groups first and individual items second.
- Keep your most-used actions visible longest, along with anything showing a badge.
- Give every item a title and a symbol. The system picks the right one for the context and uses the title in overflow menus. Items labelled only with text stay in horizontal bars, so prefer symbols.
- Group related items with toolbar item groups instead of spacing them by hand.
- Use the system overflow menu. Move any overflow menu of your own into it, and keep the ellipsis for overflow alone.
- Decide what survives. In a navigation-focused app, toolbar items overflow so the tab bar stays reachable. In a task-oriented app, the tab bar minimises so the task’s actions stay.
The API details are in setting overflow priorities.
Three reserved regions
| Region | Present | Behaviour |
|---|---|---|
| Outer front-facing camera | Always | Expands into the Dynamic Island for Live Activities |
| Inner front-facing camera | Only while the camera is on | Hidden when off; the UI moves aside when it activates |
| Folding region | Only while partly folded | Divides the inner display into separate areas |
The inner camera is the easy one to miss, because it is invisible in every screenshot you take with the camera off. See occlusion regions.
Handling the fold
When the device is partly open, the fold splits the inner display and the centre becomes unusable. Apple’s guidance has three parts:
- Prefer containers that adapt on their own. The split view in Notes narrows each pane so both stay clearly visible as the device folds.
- Use an even number of grid columns, so the fold lands between columns rather than through one.
- Move only what you must. Controls that disappear or jump across the screen are hard to find again. Nudge them clear of the fold rather than rearranging the screen.
For custom layouts, the reserved-region APIs report where the fold falls. See keeping content off the fold.
Split views and arrangements
Split views need no special handling. They expand on the inner display, collapse to one pane on the outer display, and adjust their widths and margins around the fold on their own, just as they adapt between regular and compact widths on other iPhones.
For two related views that are not a navigation hierarchy, Apple offers arrangement views, in two styles:
- A split arrangement divides the space, side by side when wide and stacked when tall. If your layout is an
HStackorVStackof two related views, it is already one. - An overlay arrangement layers one view over the other, and moves them to either side of the fold when the device is partly folded. A
ZStackwith a clear foreground and background translates to one.
Keep navigation containers such as split views and tab views outside an arrangement, never inside it. Start with adopting ArrangementView.
Games
The guidelines give games explicit room: a game may lock to portrait or to landscape, but it must still fill the screen as the pose changes. For apps, Apple’s position is that the inner display does not honour supported orientations at all. While resizing, keep text and control sizes as consistent as possible, and prefer changing the aspect ratio to letterboxing. Where bars cannot be avoided, fill them with artwork so the game still feels full screen. More in Unity on iPhone Duo.
What to change first
- Rebuild against the iOS 27.1 SDK, which turns on the side controls and full-screen layout.
- Audit every screen’s bar on the closed outer display, which uses a side column in both orientations, then in inner landscape.
- Give toolbar items titles, symbols and priorities.
- Replace any hand-built split or stacked pair with a split view or an arrangement.
- Fold the device partway on each key screen and move whatever lands on the fold.
The full checklist puts these in order of how visible each problem is to users.