Designing for the iPhone Duo: what actually needs to change in your app

Apple unveiled the iPhone Duo yesterday. It is a book-style foldable: an outer display you use with the device closed, opening into a larger inner display, with a hinge down the middle. Not a clamshell flip, which matters, because the design problems are different.

The advice you are about to read everywhere is that you need a foldable strategy. You do not. Here is the more useful version.

Almost none of your users have one

It is a brand new form factor at the top of Apple's price list, and it does not ship for a while yet. For most products, the number of people opening your app on one this year will round to nothing. Reprioritising a quarter around that is a bad trade, and any agency telling you otherwise is selling you a quarter.

So the honest starting position is that this changes nothing urgent about your roadmap. What follows is worth doing anyway, for reasons that have very little to do with how many people own the device.

If it is hard, your design system is the problem

Read Apple's guidance and the striking thing is how little of it is about foldables. Build your app to resize. Use size classes, layout margins and safe area insets. Avoid fixed widths and anything tied to a specific display. Their own line is worth quoting: do not reinvent your app when it resizes, allow the existing layout to expand based on the available space instead.

That is not foldable guidance. That is responsive design, and it has been the job for years. Your design system should already handle a range of widths, because it already has to survive iPad, landscape, split screen, larger text sizes and whatever Apple ships next September.

Which makes the Duo a useful test rather than a project. If your app adapts with a day of work, your system is doing its job. If supporting it would mean a rebuild, the Duo did not create that problem, it revealed one you are already paying for on every device that is not the one your designer had open.

Why it is still worth doing

There is a genuine window here, and it is short. In the first weeks of any new form factor, almost nothing looks right on it. Being one of the few apps that does is cheap attention: it gets written about, it makes a good App Store screenshot, and it gets shared by the sort of people who notice craft and tell other people about it.

The discipline is in where you book the cost. This is marketing spend, not product spend. If you would pay for a campaign to get the same attention, spend that much here and stop at that number. What it must not do is push out work that moves activation, retention or revenue. The window is real and it is worth days of effort. It is not worth a quarter, and the moment it starts costing like a quarter, you are no longer buying attention, you are funding a rebuild you chose not to schedule.

What Apple actually asks for

Apple put its Human Interface Guidelines page and a series of developer talks out on launch day, and they are worth reading properly. The short version:

• Two size classes, not a layout for every pose. Compact width for the outer display, regular width for the inner one. That covers every way someone holds the device.
• Build to resize. Size classes, layout margins and safe area insets, no fixed widths, nothing that depends on a particular display.
• Keep functionality and state consistent across both displays. Show an extra level of hierarchy on the inner display where the content earns it: Mail shows either the list or the message when closed, and both side by side when open.
• Let the system place your toolbars and tab bars. The outer display is wider and shorter than a normal iPhone, so iOS moves controls to the side to protect vertical space, and keeps them there in landscape so the experience does not jump as the device opens.

If you are using standard components, most of that arrives for free. That is the whole design of it.

Reserved regions and the fold

This is the one idea with no equivalent on a normal iPhone, and it is where your bugs will be. Three areas your content has to work around:

• The outer front-facing camera. Always there, in the corner, expanding into the Dynamic Island for Live Activities.
• The inner front-facing camera. Hidden behind the display until it is in use, at which point the interface moves aside for it.
• The folding region. When the device is partly open, the middle of the inner display stops being usable and the screen becomes two regions with a gap down the middle.

System components handle this already. Alerts, context menus and sheets move out of the way, and split views rebalance their columns. Your custom components will not, unless you use the reserved region APIs Apple provides for exactly this.

Two specifics worth more than the rest of the documentation. In a grid, use an even number of columns, so content divides cleanly either side of the fold. And keep movement small as someone folds the device: Apple's instruction is to move only what is necessary, because controls that leap across the screen are harder to find than controls that stay where they were.

The half-day version

If you do nothing else, do this:

• Run your app at the outer and inner display sizes and write down what breaks. That list is your responsive debt, and it is useful whether or not you care about foldables.
• Delete fixed widths.
• Check every custom overlay, sheet and floating control against the centre of the screen.
• Where you already have a list and a detail view, show both on the inner display. This is the single change that makes an app look designed for the device instead of stretched onto it.
• Confirm state survives the fold: scroll position, half-filled forms, playback, anything mid-flow.
• Use even column counts in grids.
• Then screenshot it, put it in your App Store assets, and tell people. The work is only worth what the attention is worth, and attention needs pointing at.

For most teams with a design system in reasonable shape, that is a day. If it turns into three weeks, stop and fix the system instead. You will get that time back on every device you ship to.

What Android teams already know

None of this is new to anyone who has shipped on Samsung's foldables since 2019. Continuity as the device opens, layouts that resize instead of switching, and refusing to treat each pose as its own design have been the rules on that side for years. If you have an Android team, ask them before you hire anyone to solve this. If you ship on both, solve it once.

What not to do

• Do not design a bespoke layout for each pose. Apple tells you not to, and it is a maintenance burden that grows with every future device.
• Do not ship a separate tablet-style app for the inner display.
• Do not let this jump the queue. It is a marketing line item and it should have a marketing-sized budget and a marketing-sized deadline.
• Do not hardcode display dimensions. They will change with the next model, and not having to care is the entire point.