iPhone Duo App Design: What to Change in Your iOS App
Updating an iOS app or starting a new one? Explore iPhone Duo layouts, common UI issues, side controls and a practical app review checklist.
Someone opens your travel app, checks a packing item, then unfolds their iPhone. The useful outcome is simple: their trip is still selected, their progress is intact, and the extra room makes the next action easier.
An existing iOS app does not automatically need a complete redesign. Apple says apps can run on iPhone Duo without recompiling, while newer SDKs enable better use of its displays. The first job is finding where your current app assumes the screen will never change. Apple’s preparation guide.
One iOS app. A layout that adapts.
Try the packing list below. Check an item, then switch layouts. The same native iOS app concept keeps its selection and progress while changing how much context is visible.
Trips
Packing list
1 of 3 packed
Tap an item to pack it.
Trips and the selected packing list sit together. Extra space reveals context instead of stretching a single column.
Original iOS app illustration, not Apple UI or a device simulator. Rail placement and the hatched region are schematic; actual behaviour depends on the system and available space.
Apple recommends preserving an app’s hierarchy as its presentation changes. Compact and regular size classes are a better starting point than inventing a separate interface for every pose. For this travel app, that means keeping Trips → Jaipur weekend → Packing list recognisable throughout. Design for iPhone Duo.
Where an existing iOS app can struggle
In Apple’s new bar layout, controls sit along the side on the outer display and the inner display in landscape; the inner display in portrait uses horizontal bars. A custom bottom toolbar therefore deserves a closer look. Decide which actions must stay easy to find as space changes. Apple’s bar design guidance.
These are review scenarios, not confirmed defects in every app. Run them against a flow people already depend on: booking a trip, editing a note, making a purchase or controlling a connected device.
A bigger screen, a stretched interface
A booking form becomes unusually wide, while useful trip details remain a screen away.
Check thisReview fixed widths and device-name checks. Decide which related content deserves the additional space.
The primary action becomes harder to find
Save, Share and other custom controls compete for a narrow bar, especially with the keyboard open.
Check thisPrioritise the task’s main action. Review symbols, labels and what moves into the system overflow menu.
Content sits too close to an obstruction
A custom payment button or map control overlaps a camera region or becomes awkward near the fold.
Check thisInspect safe areas on each side and reserved regions. Keep related interactive elements together.
The layout changes; the task starts over
An unsaved note disappears, a selected booking clears or the app returns to its first screen.
Check thisTreat selection, drafts and progress as app state. Add transition checks to the acceptance criteria.
Apple’s preparation guidance specifically calls out screen assumptions and asymmetric safe areas. Its bar guidance explains that controls share limited space and may overflow when the keyboard appears. The scenarios above apply those concerns to ordinary app tasks. Layout preparation, bar behaviour.
Three useful mobile app patterns
Give additional space a purpose. A travel app might reveal the itinerary beside a booking; a learning app might keep playback controls close to a lesson. These are product choices, not a requirement to add more panels everywhere.
List + detail
Keep the selected booking beside the trip list. In compact space, show its detail with a clear route back.
Content + controls
Keep a lesson and its playback controls in distinct, usable regions when the available space supports it.
A focused overlay
Show a selected place above its map. Resize the panel so the location still provides useful context.
Apple describes split and overlay arrangements for related content, with reserved regions helping layouts respond to the hinge and cameras. Avoid moving every view independently: a control and the content it operates should remain understandable together. Continuous scrolling content, such as an article or feed, does not always need the same displacement. Adaptive layout guidance.
For the iOS team: UIKit and SwiftUI starting points
- Inspect NavigationSplitView or UISplitViewController for list-and-detail navigation. Use the scene’s geometry and size classes instead of relying on UIScreen.main or portrait/landscape assumptions. Preparation reference.
- Prefer bars managed by navigation containers. Standalone custom UIKit bars do not automatically participate in the new vertical bar layout. Keep meaningful titles alongside symbols for alternate presentations. Toolbar reference.
- Apple introduces ArrangementView and UIArrangementViewController for related primary and secondary content in iOS 27.1. An arrangement does not replace a navigation container. Check SDK availability and deployment requirements before implementation. Arrangement reference.
Start with one important flow
For an existing app: record a complete task before changing it. Mark rigid layouts, custom bars, sheets and places where unsaved work could be lost. Prioritise problems that block completion before adding a new expanded presentation.
For a new iOS app: sketch compact and expanded versions of the same journey together. Decide what stays selected, what becomes visible and what remains reachable. Keep the compact journey complete; extra space should help rather than become necessary.
Your app review checklist
0 / 6Use as a working checklist. Selections stay on this page until you leave or reload.
Use this as a review record, not a compatibility certificate. Capture the screen, the task, the observed problem and the expected behaviour for every issue. Once the relevant tools are available, replace assumptions with simulator results and follow up on hardware.
A useful first milestone is modest: one important iOS journey that remains clear and complete as the available space changes. That gives the rest of your app a pattern worth repeating.