iPhone Duo App Compatibility Checklist
A practical, interactive checklist to confirm your app is ready for iPhone Duo — size classes, safe areas, Split View, fold handling, and every pose.
Last updated
Quick answer
A Duo-ready app avoids hardcoded screen widths and UIScreen.main, supports both Compact and Regular size classes, keeps controls clear of the fold, and has been tested in Split View across every pose. Use the 16-item checklist below to verify your own app, then use the Duo Simulator in Xcode's Device Hub to test each item.
Check off each item as you verify it in your own app. Progress is saved to your browser's local storage — no account needed, and nothing is sent to a server.
0 of 16 complete
Why it matters
iPhone Duo introduces new width classes, an asymmetric safe area around the fold, and a Split View posture that most existing apps have never been tested against. Apps that assume a single fixed screen size, or that read UIScreen.main directly, are the most likely to break — content can be clipped, controls can land under the fold, or layouts can simply refuse to resize. Swap those screen reads using Replace UIScreen.main. Keep custom chrome off the hinge with ReservedRegion. If you have two related regions across the fold, use ArrangementView; it is not required for a single adaptive column.
How to test
- Work through the 16-item checklist: Check off each item as you verify it in your own app.
- Confirm progress stays on this device: Progress is saved to your browser's local storage — no account needed, and nothing is sent to a server.
- Set up the Duo Simulator: Follow the Xcode Device Hub setup to run the Duo Simulator.
- Remove hardcoded screen reads: Replace UIScreen.main and hardcoded screen widths with the window scene and layout geometry.
- Test Compact and Regular widths: Confirm your layout supports Compact width and Regular width, and responds to horizontalSizeClass and verticalSizeClass.
- Resize in Split View: Resize the app window in Split View and confirm your layout updates while the app is running.
- Keep controls off the fold: Keep custom chrome off the hinge with ReservedRegion, and test the asymmetric safe area around the fold.
- Exercise every pose and display: Exercise every pose: closed, half-open, fully open, and rotated in each orientation, including the outer display and the inner display.
Frequently asked questions
What is the single most common cause of Duo compatibility bugs?
Reading UIScreen.main or otherwise hardcoding screen width. Both assume a single fixed screen size, which breaks when the device folds, unfolds, or is resized in Split View. Replace those reads with the window scene and layout geometry; see /uiscreen-main.
Is my progress on this checklist saved anywhere?
Yes, but only in your browser's local storage — there's no account and nothing is sent to a server. Progress will not carry over to a different browser or device.
How do I test every item without physical hardware?
Use the Duo Simulator in Xcode's Device Hub to exercise every pose — closed, half-open, fully open, and rotated in each orientation — and resize the app window to simulate Split View. Setup steps: /xcode.
What does "No UIScreen.main" mean, and what do I replace it with?
It means do not use UIScreen.main (or UIScreen.main.bounds) as the size of your UI. On Duo the window can be a Split View pane, the outer display, or the inner display with a fold through it — none of those match the hardware screen. Read the window scene, safeAreaInsets, and size classes instead. Concrete replacements: /uiscreen-main.
How do I keep controls off the fold?
Do not park buttons, tab bars, or floating chrome on the hinge line. Use SwiftUI ReservedRegion (UIViewReservedRegion in UIKit) so custom UI claims space while avoiding system-reserved areas, instead of a hardcoded inset. See /reservedregion.
Do I need ArrangementView to pass the checklist?
No. ArrangementView is for layouts that place two related regions across the fold (split or overlay). A single adaptive column that already respects size classes and the fold does not need it. Reach for it only when you have two coordinated surfaces; details: /arrangementview.
Does Split View testing count as a different size class?
Split View changes the width you are given, so it often switches horizontalSizeClass, but it is not a substitute for Compact and Regular as layout targets. A pane can be Compact on the inner display; unfolding without Split View can be Regular. Test both size classes as layouts, then resize the window live so those layouts update while the app is running.
What fails if I skip pose testing?
Closed pose uses the outer display and a different aspect; half-open changes geometry and is often used hands-free; fully open puts the fold through the content. Skipping poses misses clipped outer-display UI, controls sitting on the hinge, and layouts that only work at the size you launched with.