Your app already runs on iPhone Duo

Every app in the App Store today runs on iPhone Duo on day one. Nothing crashes, nothing gets pulled. What differs is how much of the 7.6-inch inner display the system hands your app, and that depends on the SDK you last built against.

There are three tiers.

Built with an SDK older than iOS 27. The system draws the app inside a safe rectangle on the inner display and fills the rest with black. It works, but it looks like an iPhone app running on a bigger device. This is what your customers see on the screen if you ship nothing before its release.

Built with the iOS 27 SDK. The navigation bar on Duo now sits on a vertical axis along the side of the screen. An app built with the iOS 27 SDK may extend into the space next to it, so the black frame shrinks considerably, but no content sits behind the navigation bar.

Built with the iOS 27.1 SDK. The app takes up the full screen, edge to edge.

The rebuild itself is the easy part. Install Xcode 27.1, build, and the standard navigation components rearrange themselves, because the system owns them and already knows how to lay them out. What the rebuild does not do is tell you whether the result is right. Every screen still has to be reviewed in every pose the device can take: closed, fully open, partially folded, standing on a table, and each of those in every orientation. It is also very common for an app to have screens where the implemented design deviates from the standard navigation components. Each of those is a place where nothing moves on its own. Each one needs to be tested and validated, and where it does not hold up, refactored with extra attention. That is where the actual work on Duo sits.

Size classes finally matter on iPhone

Until now an iPhone app could get away with a shortcut. On an iPhone the size classes were predictable enough that it was tempting to skip them, and to ask the device idiom to tell phone from tablet, or the interface orientation to tell portrait from landscape, instead. Plenty of production code still branches on exactly that: the idiom, the orientation, or a hardcoded check against a screen width.

Duo breaks all three at once. The inner display reports a regular size class in both width and height, in every orientation. It is an iPhone by idiom and an iPad by layout. It also does not honour the supported interface orientations declared in the project, so an app that locked itself to portrait will still be asked to lay out in landscape when the user opens the device that way. The outer display, meanwhile, behaves like any other iPhone: compact width, the familiar shape.

The answer is the one Apple has been giving since iOS 8. Lay out against size classes and the available space, not against the device. A view that shows a sidebar when the horizontal size class is regular and a tab bar when it is compact works on Duo without knowing Duo exists. A view that shows the sidebar because the idiom is pad does not. In SwiftUI that means reading the size class from the environment; in UIKit it means the trait collection. Neither is new. What is new is that the shortcut now fails on a phone. Auditing the codebase for idiom and orientation checks is a mechanical task, and it is the second thing to do after the rebuild.

UIScreen.main is finally gone

Every iOS codebase older than a few years has a utility that reads the bounds or the scale of the main screen. It sits in a layout helper, a chart, an image loader that picks a resolution, a piece of code that positions something before the view has a frame. It was deprecated in iOS 26, and until now ignoring that deprecation cost nothing.

Duo has two physical screens. Apple's own guidance is blunt about what that does to the main screen: on a two-display device the concept is ambiguous. Which screen a piece of code gets back when it asks for the main one is not something you should build a layout on, and the failures this causes are quiet: sizes that are slightly off rather than screens that are obviously broken.

The replacement has been available for years. A view knows the window it is in, the window knows its scene, and the scene knows which screen it is on. Scale comes from the trait collection rather than from the screen. Neither change is difficult, but the call sites are scattered and rarely covered by tests, so this is a search across the whole codebase rather than a fix in one place. It is also a good moment to ask why a piece of code needed the screen in the first place. Most of the time the answer is that it wanted the size of its own container, and that is a question the container can answer directly.

Split View comes to iPhone

Duo is the first iPhone that runs two apps side by side. A user can open Mail next to Safari, keep a video playing next to Messages, or save a pair of apps and bring both back with one swipe. Every one of those scenarios puts your app in a window that is not the full screen, on a device that is not an iPad.

For the app this looks like a resize. The window gets narrower, the horizontal size class can drop from regular back to compact even though the device is wide open, and the safe area stops being symmetric because one edge of the app now borders another app or the fold. Layouts built on the standard containers handle this on their own. Layouts that measured the screen once at launch, or that inset both sides by the same amount, do not.

There is a second consequence that is easy to miss. Split View also lets a user put two windows of the same app side by side, in the way iPad has allowed since iOS 13. That is one app with two scenes, not two copies of the app, and it only works if the app declares support for multiple scenes. The iOS 27 SDK already forces the scene lifecycle on every app, but multiple windows remain a separate opt-in, and a surprising number of iPhone-only apps never turned that on because there was no reason to. On Duo there is. Adopting scenes is not a large change in a well-structured app, but it exposes every place where state was kept as a global because there was only ever one window. That is work worth planning for rather than discovering.

ArrangementView, a layout container that knows about the fold

Most of Duo is handled by components that already existed. A handful of APIs are new, and the one that changes how a screen is built is a layout container. iOS 27.1 introduces ArrangementView in SwiftUI, with UIArrangementViewController as the UIKit counterpart, and it solves a problem no other iPhone has had: what to do with the hinge.

An ArrangementView holds two views, a primary and a secondary, and decides how to place them based on the available space, the aspect ratio and whether the fold is currently in the way. In its default split style it puts the two side by side when the view is wider than it is tall and one above the other when it is taller than wide. When the device is partially folded, the hinge becomes an active division region and the two views land on either side of it. When the device is flat, that region has no width and the arrangement behaves like an ordinary two-pane layout.

This article was written before the SDKs with iPhone Duo support were available. Everything in it is based on Apple's announcement, Tech Talks and developer documentation published at that time. Details may change once the final SDK and the device ship.