How to Adapt Your App for iPhone Duo: A Practical Migration Guide
To adapt an existing app for iPhone Duo, first run the current experience across its displays, replace assumptions about screen size, and verify that the same task survives every transition. This guide gives you an implementation order and a pass condition for each step. Use it alongside Apple’s preparation session; the review workflow and prioritization below are our recommendations.
1. Establish a baseline in the Duo simulator
Apple’s preparation session uses Xcode 27.1 and Device Hub to simulate opening, closing, rotation, and folding. It distinguishes an existing app running in a compatibility layout from an app rebuilt with the newer SDK’s display and control behavior.
Before changing code, record the current build and choose one short workflow: select a saved item, edit it, and return to the list. Capture the outer and inner states using recognizable sample content. Write down each failure separately: clipped layout, missing action, changed selection, or lost draft. This baseline prevents a visual improvement from hiding a broken workflow.
2. Audit screen and orientation assumptions
Look first at the code that decides the root layout, content width, and image scale. Apple recommends size classes and the current view or scene environment; a two-display device makes a global main-screen assumption unreliable.
For each match in the audit below, identify what the value is used for before replacing it. A rendering scale, a container width, and a navigation mode are different decisions. Check the resulting behavior in a narrow window as well as the full inner display.
Apple: size classes, screens, and safe areas ↗
| Inspect | Question to resolve |
|---|---|
| UIScreen.main | Does this belong to the current window scene, or should it use the current display scale? |
| Fixed content widths | Can this region use its container’s available bounds? |
| Portrait / landscape branches | Is the real decision about available space rather than physical orientation? |
| Phone / tablet branches | Can a regular-width iPhone show the appropriate content? |
| Mirrored left and right insets | Does each edge use its own safe-area value? |
3. Adapt navigation before polishing individual screens
Trace the route from the app’s entry point to the selected item. Decide which content is primary and which is supporting context. Fix that relationship at the container level before adding local offsets to every screen.
For a list-and-detail app, our suggested pass condition is simple: the same item is selected when the layout changes, and Back or Close still leads to the expected destination. Check dialogs and overflow menus from that item too. A wide screenshot may look complete even when one of those destinations has become unreachable.
4. Review custom UI around safe areas and reserved regions
Start with manually positioned controls, custom charts, drawing tools, and overlays. Apple’s adaptive-layout session distinguishes a dividing fold region from an obscuring camera region, and shows how their active state affects available space.
Mark the controls people must reach to finish the chosen task. If one conflicts with a reserved region, move or resize the smallest useful group, then repeat the interaction. Keep a before-and-after capture beside the change description. Avoid treating every centered decorative element as a blocker; prioritize unreadable content and unreachable actions.
5. Keep the current task when the device changes
Make an unsaved edit that is easy to recognize, then open, close, rotate, and return. Compare the selected item, draft contents, navigation destination, and active operation after each change. For a player or timer, define the continuation behavior your app promises before evaluating it.
When a failure appears, reproduce it from the same start state and locate where the app recreates or resets the relevant state. Fix that cause, then run the original sequence. Reopening the app into a correct-looking screen is useful for diagnosis but does not prove the transition works.
- The selected object remains recognizable.
- Draft changes survive the transition.
- The primary action remains reachable.
- The app does not unexpectedly restart the workflow.
6. Test the failure-prone combinations
After the main flow passes, try a long translated label, larger text, keyboard presentation, and Split View. Combine one of these with the narrowest state that matters to your app. Prioritize the screens with custom layout or important completion actions.
Keep the result as a small release checklist. “Passed on Duo” is too broad to be useful; name the build, workflow, display state, and sample content. Record any unavailable device or simulator state as untested so the next reviewer knows exactly what remains.
| Scenario | Pass condition |
|---|---|
| Outer → inner → outer | Same selected item and draft |
| Rotation and partial folding | Important content and controls remain usable |
| Split View | Navigation and completion actions stay reachable |
| Long labels and larger text | Commands remain identifiable |
| Keyboard, dialog, or menu | The flow can still finish or cancel |
7. Capture the adapted UI and prepare store assets
Once the flow passes, capture the actual outer and inner interfaces separately. Keep originals with the build and language information. Use the same sample item when the screenshot story compares the displays, then choose a short benefit-led headline for each panel.
Use the size guide to choose the export target and the design guide to compose the set. App Asset Kit can add captions and export exact-size PNGs; it does not change the app layout inside your uploaded capture or certify compatibility. Review the actual files before handing them off.
Frequently asked questions
How do I start adapting an existing app for iPhone Duo?
Run one repeatable workflow across the displays, record failures, audit fixed screen assumptions, then correct navigation, custom layout, and state issues in that order. Keep evidence for each pass condition.
Do I need to redesign every screen for iPhone Duo?
Start with the current app and its layout containers. Change what prevents the task from working or using space well; use the design guide when a content hierarchy needs a wider presentation.
Does exporting Duo screenshot dimensions make my app compatible?
No. Export dimensions validate an image. App adaptation requires testing the real interface, navigation, controls, and state transitions.
Can this checklist be used for Flutter or another framework?
The workflow and pass conditions are useful across frameworks. The SDK and API references in this article describe native iOS; check your framework’s current iOS support before choosing implementation changes.