Designing for iPhone Duo

iPhone Duo is still one iPhone. Closed, it is a compact phone. Open, it is a wide canvas with a hinge down the middle. People will flip between those all day, often in the middle of a task. The design job is to make that flip feel like the same app getting more room, not like a second product.

Apple’s design session asks you not to draw a custom layout for every pose. Two widths cover most of the work. The rest of this page is where that advice meets apps people have already tried in the simulator. The APIs live in the vertical bar and fold guides. The pass to run before you ship is the simulator checklist.

Design for two size classes

Apple describes four ways people hold the phone:

• Closed, on the outer display.
• Open, on the inner display.
• Partly folded, like a book in the hand or a laptop on a table.
• Standing, resting on its edges.

Each of those comes upright or sideways, so a full sketch set is six artboards: closed, open and partly folded, each in portrait and landscape. One of the six is new to iPhone: the closed phone turned sideways, which the simulator reports as compact in both width and height.

You design for the space you are given. The outer display is a compact width, in the same family as any other iPhone. The inner display is regular in both width and height, closer to a small iPad. Apple says Duo respects the orientations you support, but your app still scales to fill the inner display, so a portrait-only app shows up wide once the phone is open. Read horizontalSizeClass and verticalSizeClass, and stop branching on userInterfaceIdiom. Duo reports itself as an iPhone even when the inner display is regular width.

Size class is a coarse signal, not a ruler. fatbobman makes this distinction for resizable iPhone windows, and it applies here too: the class tells you which system containers are appropriate. When you need the real width of a column, measure the view.

In a group lab that Anton Gubarenko wrote up, Apple’s engineers described the same idea with the TV app. Opening the phone stretches the window. You see more of the thing you were already looking at, plus room for detail. They also used Find My as the test for controls that belong together: the tabs stay with the sheet, because each tab chooses what the sheet shows. Pulling them apart would split one control in two. Anton warns that the notes can miss a nuance, so treat the lab as the engineers’ direction and check it in the simulator.

Start with the phone closed

Vidit Bhargava built Duo-Man, a tape player, in a few hours at a Bitrig hackathon. Talking to Sean Allen about it, as Kyle Macomber quoted, Vidit’s advice was to start from the closed phone. Shrinking a large layout onto a small display is harder than growing a small layout into a large one. In Duo-Man, you can still eject the tape from the outer display. It is less fun than the open version, but it is the same feature.

That is also how Avionics Buddy is built. Sharif El Fatatry says there is no separate set of Duo screens. The same SwiftUI layout reflows when you fold, rotate, or turn the device.

If a feature only exists when the phone is open, someone who never unfolds it cannot reach it, and someone who folds the phone halfway through will lose it. A hands-free tabletop layout, with the picture on top and the controls below, is a good extra. It is not a replacement for the compact layout.

Use the width, or leave a hole

Bunny Lau, exploring a Duo version of the Tweed browser, put it plainly: an unfolded layout that still behaves like a tall phone is an ocean of wasted pixels. On the full inner display, Tweed leans into the horizontal canvas. In Split View and on the outer display, it switches to a vertical sidebar so the column stays tight.

The SwiftUI note in that post, turning the vertical bar off based on posture, is only half of the layout. Kashif Mehmood’s reply is the other half: posture tells you the mode, not where the hinge falls. A sidebar divider or a centered control can still land on the crease. System containers already route around it, so a stretched phone layout is a size-class problem. The crease only bites controls you placed yourself, and for those you read the division region, as the fold guide shows.

Opting out of the side column is a real choice, and it should be about the content. Weng Tianxin, designing Camarts 3.0, kept a traditional symmetric layout and left out the side control column. Most of the photos in Camarts are landscape, so the width goes to the picture. Weng calls the simulator version good enough for now, with the rest to be tuned on a real device.

If you do turn the side column off, do it for the whole screen and leave it there. Switching bar direction as someone navigates makes the chrome jump. The vertical bar guide covers when that opt-out is worth it.

Let the system move its own bars

Rebuild with the iOS 27.1 SDK and keep navigation, toolbars, and tabs in system containers: NavigationStack, NavigationSplitView, TabView, or the UIKit controllers that own their bars. Those bars move to the side when the display is wide and short, and they return to the top and bottom on the inner display in portrait. A bar you drew yourself stays where you pinned it. A floating button is in that second group.

Sahil AK found this while adapting TimeWave. The native toolbar APIs did most of the work. The floating plus button is the piece still to place.

Harshil and Rob Swift hit the same split in their own apps: the system bars moved, and a floating share button, a custom bell and a floating action button did not. That is all custom chrome, and the vertical bar guide is where to fix it.

Keep one hierarchy

People open and close the phone constantly. The structure of the app should survive that. A list can become a sidebar. An article can get a wider measure. The person should not have to find their place again, and they should not land on a different home screen because the hinge moved.

Scrollable content can run across the fold. Feeds, articles, and lists already adapt by scrolling. Controls someone has to hit, such as a send button, a playback cluster, or a floating action, should stay off the crease and inside the safe area. Background art can run to the edges.

Safe areas on Duo are often uneven from side to side, and they change when the bars move. The checklist has the measurement and the bug that shows up if you double the left inset. The sizes guide has the panels themselves.

Corners follow the glass. Apple’s prepare session points at the Concentricity APIs from iOS 26, updated for Duo’s corner shapes: ConcentricRectangle in SwiftUI, UICornerConfiguration in UIKit. Use those instead of a hardcoded corner radius when a shape has to meet the screen.

Five questions before handoff

Ask these of every screen in the design, before anyone opens Xcode:

1. Does this feature exist on the closed phone, or only once it is open?
2. Which system container owns each bar? List the ones you are drawing yourself, because those will not move.
3. Where does each tappable control sit when the phone is half folded? Scrolling content can cross the crease. Buttons cannot.
4. What does the open layout do with the extra width: show more, or show the same thing bigger?
5. When the hinge moves in the middle of a task, where does the person land?

Next, read how the vertical bar decides what moves, then how to lay out around the fold without reading the hinge angle.