iPhone Duo folds. That means one app has to feel right on a short outer screen, a big inner screen, and every angle in between.
Here is what I learned doing this for ForkMesh.
The One Big Idea
You don't design a screen for each pose. You make one app that resizes well, and you let controls move to the side.
On Duo, tabs and toolbars leave the top and bottom and stand in a column under the camera.
The outer screen. The empty column by the camera now holds the controls, and the list gets the height back.
How the Side Column Works
A Live Activity can grow out of the camera and take space. When that happens, less important buttons move into the … menu.
Keep your main action and anything with a badge visible longest.
Use System Bars First
This was my biggest lesson.
I planned to draw this column by hand, then read that iOS moves standard toolbars and tab bars for you. Custom bars stay where they are.
When I put real toolbar items on a screen in ForkMesh, they moved into the column as real Liquid Glass.
If your app has a custom tab bar like mine, try this before you build anything.
The Big Screen Is Not a Stretched Phone
Held upright: The inner screen is the one pose that keeps normal top and bottom bars. There is enough height for them.
Respect the Fold
System sheets, alerts and menus move away from the fold by themselves. For custom views, use ReservedRegion.
Checklist
- Build with the latest Xcode. Otherwise your app won't use the full screen.
- Use size classes, not fixed widths. In my test, the outer screen reported compact width.
- Measure the window, not the screen. A fold can resize your app at any moment.
- Keep state when folding. I found code that closed the open page on fold. Typed text and open pages must survive.
- Keep the same features in every pose. Only the layout should change.
- Give every toolbar item an icon and a title. Items with only text or a custom view won't move to the column.
- Test short screens. The outer screen clipped my onboarding headline behind a button.
- Check Split View. On the left half, controls move to the left edge.
Prompt You Can Use
Paste this into your AI coding tool, inside your project.
iPhone Duo Prompt
You are a senior iOS engineer. Make this app feel native on iPhone Duo, a foldable with a short outer screen and a large inner screen. Own the whole job: audit, test, build, verify and report. Keep going without asking, and stop only for a product decision, a destructive action, or a blocker you cannot solve.
HOW THE DEVICE WORKS
- Outer screen: about 466x678 points, compact width.
- Inner screen: about 669x951 points.
- iOS moves standard tab bars and toolbars into a side column on the camera side when the phone is in those poses. Custom bars do not move.
- Folding resizes the window while the user is mid-task.
THE FIVE RULES
1. Same app: every feature exists in every pose.
2. Same place: controls do not jump between poses.
3. Same work: open page, navigation path, scroll position, typed text, selection and running tasks survive every fold and resize.
4. System first: use system components, and draw custom UI only when the system cannot do it.
5. Size, not device: layout comes from size classes, safe areas and available space. Never branch on the device model.
TARGET LAYOUT
- Outer screen: one pane. Side column order is Back alone, page actions, overflow, a gap, then tabs at the bottom.
- Inner sideways: list and detail together, with the column on the same side as the outer screen.
- Inner upright: normal horizontal bars.
- Half open: the fold divides the panes. No buttons on the fold. Scrolling content may cross it.
PHASE 1: AUDIT, CHANGE NOTHING
Read the project's own instructions and conventions first. Then report, with file:line:
- navigation structure, and every tab bar and toolbar, marked system or custom
- fixed widths and heights, screen-size checks and device-model checks
- code that resets state on size change, scene change or geometry change
- screens at risk on short height: onboarding, paywalls, sheets, keyboard flows
- the iOS deployment target, and how new APIs must be availability-gated
PHASE 2: PROVE IT ON ONE SCREEN
Before building anything, run the smallest experiment. Put real toolbar items and a real TabView on one screen and run it on the iPhone Duo simulator. Screenshot what the system gives you for free. Let that result decide the plan. Do not hand-build a column until you have proved the system one cannot work.
PHASE 3: PLAN
Write a short ordered plan, smallest safe change first. If a custom bar must stay, say why. Look up every new API in the installed SDK or Apple's docs before using it. Never guess an API name or its availability.
PHASE 4: BUILD
- Make one small change per commit if this project uses commits that way. Follow its code style.
- Replace custom bars with TabView, NavigationStack, NavigationSplitView and .toolbar where you can.
- Give each toolbar item an icon and a title. Set visibility priority so the main action and badged items stay visible longest.
- If a custom bar must stay, use toolbarVerticalEdge to find the side and ReservedRegion to avoid the camera and fold.
- Move navigation and draft state to a level that survives layout changes.
- Keep every other iPhone and iPad exactly as it was. Prove it with a before and after screenshot.
- Add tests for any layout or state logic you can test without a device.
PHASE 5: VERIFY, DO NOT ASSUME
Build and run it yourself. For each main screen, check each pose you can reach: outer, inner sideways, inner upright and half open. Check these every time:
- no clipped text and no control under the camera or column
- selected tab, badges and overflow still work
- onboarding, sheets, alerts, keyboard and Split View
- largest Dynamic Type, light mode and dark mode
- state survives a resize: open a page, type text, change pose, come back
If something fails, fix it and check again. Do not call anything done because it compiled.
PHASE 6: REPORT
Give me a table of screen, pose and result, marked verified by screenshot, verified by test, or not tested. List every decision you made, what you could not test, and the exact steps I should try by hand on a real device. Never claim a pose works if you did not see it.