How to Prepare an iOS App for iPhone Duo

An existing iPhone app can run on Apple's new iPhone Duo without being rewritten, but simply running is not the same as using its foldable display well. Apple's developer guidance now points developers toward adaptive layouts, size classes, scene-based APIs, and fewer assumptions about a single screen. This tutorial shows how to audit an existing app in Xcode 27 and make the changes that matter before testing it on iPhone Duo.

Start by moving the project to Xcode 27

Apple released the Xcode 27 Release Candidate on September 9, 2026, alongside release candidates for its new operating systems, and App Store Connect now accepts builds made with the iOS 27 SDK. Start by opening your project in Xcode 27 and allowing Xcode to identify project settings or source code that need attention. Before changing application code, create a clean build and run the existing app on a current iPhone simulator or physical device so you have a working baseline.

For a UIKit project, also check whether the application already uses the scene-based lifecycle. Apple's current UIKit documentation says that apps built with the latest SDK must use the scene-based lifecycle starting with iOS 27 or they will fail to launch. This is a migration issue rather than an iPhone Duo-specific layout issue, so fix it before investigating visual problems on the new device.

Check the app for fixed screen assumptions

The first useful audit is a search through the project for code that assumes one particular screen size or orientation. Look for direct use of UIScreen.main, hard-coded width and height values, calculations based on a specific iPhone model, and logic that chooses a layout solely from portrait or landscape orientation. These patterns often worked because traditional iPhones presented developers with a relatively predictable display shape.

iPhone Duo changes that assumption because its inner display provides a different available space and can change how the application should arrange content. Apple's guidance specifically recommends using the current environment, trait collection, or scene bounds instead of treating a single global screen as the source of truth. The goal is to ask the interface how much space it currently has rather than guessing which device is being used.

Replace screen-based layout code with scene-aware measurements

Suppose an older UIKit application contains code like UIScreen.main.bounds.width to decide how many columns to display. That approach ties the decision to a global screen rather than the actual window containing the interface. A safer pattern is to use the view or window scene that owns the current interface and make the layout decision from its available bounds.

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()

```
let availableWidth = view.bounds.width

if availableWidth >= 700 {
    showExpandedLayout()
} else {
    showCompactLayout()
}
```

}

The exact breakpoint should come from the application's design rather than from the example number above. The important change is architectural: the view is responding to the space actually available to it. That makes the same code more resilient when the device changes size, folds, rotates, or presents the application in another supported configuration.

Use size classes instead of orientation for layout decisions

Size classes describe the amount of horizontal and vertical space available to an interface. In UIKit, they are exposed through the trait collection; in SwiftUI, the environment provides the corresponding adaptive information. Apple's iPhone Duo guidance specifically recommends size classes rather than interface orientation for deciding how the inner display should lay out content.

This matters because a physical orientation does not tell you enough about the usable space. Two interfaces can both be considered portrait while having very different widths and heights available to their content. A layout that switches only when the phone rotates can therefore make the wrong decision on a foldable display.

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
super.traitCollectionDidChange(previousTraitCollection)

```
let horizontalSizeClass = traitCollection.horizontalSizeClass

if horizontalSizeClass == .regular {
    showExpandedLayout()
} else {
    showCompactLayout()
}
```

}

For new SwiftUI interfaces, the same principle can be expressed through the environment instead of querying a physical screen. This lets the view react to the container in which it is displayed and keeps layout rules independent from individual device models.

Build layouts that can actually resize

A flexible layout should be able to absorb extra width without simply stretching every control. Review navigation, lists, forms, toolbars, and content columns separately. If the application has a sidebar, consider whether it should remain visible when there is enough space and collapse when space becomes constrained. If a form contains several controls on one row, make sure those controls can wrap or reorganize rather than producing clipped or overlapping content.

Standard UIKit navigation and layout components are useful here because they already participate in Apple's adaptive layout system. SwiftUI developers should similarly prefer stacks, grids, and adaptive containers over manually positioned elements. The test is simple: resize the available area aggressively and watch for text truncation, overlapping controls, unexpected scrolling, and actions that become unreachable.

Handle iPhone Duo's inner display as a different layout environment

Apple's developer guidance describes the outer display as behaving more like a conventional iPhone while the inner display provides substantially more regular space in both dimensions. That additional area can make sidebars and two-column layouts useful, but it also exposes applications that were designed around a single narrow column.

Do not solve this by creating a special layout that only activates when the device name says iPhone Duo. A better design is to define what the application should do when enough space is available. iPhone Duo then becomes one device that happens to satisfy that layout condition, while future devices and other supported configurations can benefit from the same code.

Respect safe areas and reserved regions

Foldable hardware introduces physical areas that can affect where content should appear. Apple's preparation guidance specifically calls out asymmetric safe areas and reserved regions. Content that looks correctly centered on a conventional display can become visually awkward when a device has a hinge or another area that should not contain important controls.

Use the system-provided safe-area information instead of manually subtracting a guessed amount from the screen dimensions. Keep primary buttons, text, and interactive controls away from regions where the system indicates that content should not be placed. This also protects the app from future hardware changes because the application consumes layout information supplied by the operating system instead of encoding the current hardware into its source code.

Test every pose instead of testing only portrait and landscape

Xcode's Device Hub provides an iPhone Duo simulation environment that lets developers change the device state and test different poses. Run the application through the states that users can encounter instead of stopping after the first successful launch. Watch navigation transitions, keyboard presentation, scrolling, modal screens, media, camera interfaces, and any custom view that calculates its own dimensions.

Pay particular attention to transitions. A layout can look correct immediately after launch and still fail when the available space changes. If constraints are calculated only once, cached dimensions are retained too long, or a view assumes that its original bounds remain unchanged, folding or resizing can expose the problem. The desired result is not merely a screenshot that looks correct; the interface should continuously adapt as its environment changes.

Update screenshots and App Store assets separately

Code compatibility and App Store presentation are separate tasks. Apple has already published iPhone Duo screenshot specifications, including different dimensions for its outer and inner displays, while support for uploading iPhone Duo assets to App Store Connect is scheduled to become available later in 2026. This means developers can prepare the application experience now without assuming that every store-management workflow is already available.

Do not generate store screenshots simply by stretching existing iPhone images. Once the relevant App Store Connect asset support is available, capture the application in the appropriate display configuration and make sure important interface elements remain visible in the required dimensions. Store assets should demonstrate the real application rather than an artificial mockup of how the foldable experience might look.

Use this audit before submitting the updated build

1. Open and build the project with Xcode 27 and the iOS 27 SDK.
2. Resolve scene-lifecycle issues reported by Xcode.
3. Search for direct global-screen measurements and hard-coded display sizes.
4. Move layout decisions to view bounds, scene information, traits, or SwiftUI environment values.
5. Replace orientation-only layout decisions with size-class or available-space logic.
6. Review navigation, forms, lists, grids, toolbars, and custom controls at wider sizes.
7. Respect safe areas and system-provided reserved regions.
8. Run the app in the iPhone Duo simulator and test multiple poses.
9. Check every screen after resizing, folding, rotating, keyboard presentation, and navigation.
10. Run the final build through TestFlight before submitting it to the App Store.

The key change is not adding an iPhone Duo condition to an otherwise rigid application. It is removing the assumptions that made the application depend on one screen shape in the first place. If the code responds to its actual environment, uses adaptive layout primitives, and survives changes in available space, the same work improves the app on existing iPhones and prepares it for Apple's next device layouts as well.