iPhone Duo: What Your App Needs to Change

Apple now has a foldable iPhone. iPhone Duo has an outer display, used when the phone is closed, and a much larger inner display when you open it. Your customers will switch between the two several times a day, and your app has to keep up.

If you have an iOS app and nobody has worked on it in a few months, it’s most likely not ready. The good news: in many cases it doesn’t need a redesign, just a set of targeted fixes. In this article I explain what happens to an app that isn’t optimized, what needs to change and how to tell how long adapting it will take. I go into some technical detail along the way, so you can have a concrete conversation with whoever maintains your app.

Why it matters for your business

The first people to buy an expensive foldable phone are usually heavy users who use lots of apps and compare them. On the large display, an app that hasn’t been adapted stands out right away: it shows up small and centered, with empty space around it, like an iPhone app opened on an iPad. Nothing breaks, but the product looks abandoned.

Apple actively encourages optimization. Apps that submit iPhone Duo screenshots in App Store Connect get a badge on their product page showing they’re optimized for the new device. You can also submit the app for App Store featuring, noting that it’s optimized for iPhone Duo in every device pose. A competitor who does this first gets a visible edge on the store page.

What happens to your app today

The behavior depends on which iOS SDK the latest version of your app was built with. In short:

• Built with iOS 26 or earlier: the app runs but doesn’t adapt. On the inner display it appears centered with empty space around it. On the outer display it sits to the left of the status bar and camera.
• Built with iOS 27: the app fills most of the inner display but stays clear of the status bar on the right. There’s less empty space.
• Built with iOS 27.1 or later: the app goes edge to edge on both displays. Toolbars and tab bars move to a vertical arrangement along the edge of the display.

Here’s the catch. Simply rebuilding with the new Xcode makes the app stretch across the whole display. If the interface was built on the assumption that the screen is always the same size, the result can look worse than the old version: cropped images, text stretched across the full width, overlapping or hidden buttons. That’s why the update has to come with checking and fixing the interface, not just “let’s rebuild it and ship”.

What’s different about iPhone Duo

Apple’s design guide, Designing for iPhone Duo, describes a few things we haven’t had on iPhone before:

• Two displays with different shapes. The outer display is wider and shorter than on a regular iPhone, and the inner one is large, with a hinge in the middle.
• Several poses. The phone can be held partially folded like a book, set down on a table or stood on its edge. Apple doesn’t ask for a layout per pose, but for one layout that adapts to the space available.
• Navigation bars on the side. On the outer display, and on the inner display in landscape, the tab bar and toolbar move to the side edge to leave more vertical space for content. The exception is the inner display in portrait, where the bars stay at the top and bottom.
• Reserved regions. The outer front camera is always visible in the corner. The inner camera sits behind the display and the interface only moves aside when it’s active. When the phone is partially folded, the hinge area divides the inner display in two, and important content shouldn’t sit right on the fold.
• Two apps on one display. The inner display supports Split View, so your app may get only part of the display, at almost any size.

How your app should behave

The core principle in Apple’s guide is simple: don’t reinvent the app on the large display. Same product, same features, same state, just making better use of the space. In practice that means:

1. Customers lose nothing when they open or close the phone. If they were writing a message, filling in a form or halfway through an order, they continue exactly where they left off.
2. The same features in every pose. Some buttons can move into a menu when space is tight, but no action disappears.
3. One extra level on the large display. Mail is Apple’s example: closed, the phone shows either the list of emails or an email. Open, it shows both side by side. A product list with product details, or a list of appointments with the selected one, can work the same way.
4. No sudden jumps. When the phone folds, elements move only as much as needed to stay visible. A button that jumps to another corner of the screen is hard to find.
5. Images that don’t get cropped. Large photos and full-screen videos can lose exactly the important part on a wider display. Every screen with large images is worth checking.

What needs to change in the code

Apple has also published a preparation checklist for developers. Below are the problems I run into most often in existing apps, and what needs to change. If you’re not a developer, you can send this section to your team as a starting point.

1. Read sizes from the window, not the screen

A lot of older code computes layout from UIScreen.main.bounds, the size of the physical screen. On iPhone Duo, the app doesn’t necessarily fill the whole screen, and the screen itself changes. The right approach is to use the size of the window or view (view.bounds, window.bounds, and in SwiftUI GeometryReader or onGeometryChange) and to read it again every time it changes, not just once at launch. Create the window with UIWindow(windowScene:), not with the screen size.

2. Orientation no longer tells you the shape of the screen

Logic like “if the phone is in landscape, show two columns” stops working. On the inner display, the app can be wide while the phone is held upright, and in Split View it can be narrow while the phone is held sideways. Code that relies on UIDevice.current.orientation or interfaceOrientation should be replaced with a simple comparison of the available width and height.

3. “Regular width” no longer means iPad

Many apps choose a layout based on the device type (userInterfaceIdiom == .phone) or treat a regular width as a sign they’re running on iPad. On iPhone Duo, an iPhone can have any combination of size classes. The same goes for checks like bounds.height == 844 or lists of known iPhone sizes: they need to go. The upside is that if your app already has a good iPad layout, the inner display should look like a natural extension of it.

4. Standard components do much of the work

If the app uses Apple’s standard components for tab bars, toolbars, split views, alerts and sheets, moving bars to the side and avoiding the fold come automatically. The guide also asks that every toolbar button have both a symbol and a title (the title shows up in the overflow menu), that you use the system overflow menu instead of your own, and that you decide which buttons stay visible longest when space runs out. For custom components, Apple provides the ReservedRegion API, which keeps important elements away from the camera and the fold. For screens with two areas, like a list with details or a map with a panel on top, there are the new arrangement views, which lay out both parts automatically based on the available space and the fold.

5. Flutter and React Native apps

Cross-platform apps have the same problems, just in different code. In Flutter, for example, the equivalent of UIScreen.main.bounds is a layout built once from MediaQuery, and the fix is a layout that responds to the space available, with LayoutBuilder and MediaQuery.sizeOf. In Flutter, navigation bars are drawn by the framework rather than being Apple’s native components, so moving them to the side doesn’t happen automatically the way it does in a native app. In React Native, it depends on the navigation libraries you use. Either way, what matters is what support new framework versions add and what has to be adjusted by hand in the app.

How to check whether your app is ready

You don’t need a physical iPhone Duo for a first assessment. Apple provides a few tools:

• The Xcode assistant: you can ask it to “get my app ready for iPhone Duo”, and it looks for the problem patterns above and suggests fixes. The same check can be exported for other coding agents with xcrun agent skills export. Apple is clear that it doesn’t catch everything, so a manual review is still needed.
• The iPhone Duo simulator in Xcode 27.1: the most faithful option, with every device pose.
• The resizable simulator and iPhone Mirroring on macOS 27: the app window can be stretched and squeezed to extreme sizes, which quickly exposes fixed layouts.

A quick test you can do yourself once you get a test build: open every important screen in the app and ask yourself whether you see everything you should, whether the images look right, whether the buttons are where they belong and whether, after you “close” and “open” the phone, you’re still where you left off.

How long does adapting an app take?

It depends more on how the app was built than on how big it is:

• A few days: an app built with standard components and an adaptive layout, that already has a good iPad version. Often it only needs a rebuild, testing and small adjustments.
• One to three weeks: an iPhone-only app with fixed sizes and orientation-based logic in a few places. The screens have to be gone through and fixed one by one.
• Longer: an older app with many custom components, hand-drawn navigation or a framework that has fallen behind. Here, iPhone Duo optimization usually comes bundled with a long-postponed technical update.

The first step is an assessment: run the app in the simulator, go through the main screens and list what breaks. Only then can you estimate properly.

In short

• An app that isn’t optimized runs on iPhone Duo, but looks small and dated on the large display.
• Rebuilding with the new Xcode without checking the interface can make things look worse.
• The goal is the same app, using the space well, keeping its state and not losing features when it folds.
• The App Store badge is a visible advantage for those who move first.

If you want to know how your app looks on iPhone Duo and how long adapting it would take, get in touch. I can run an assessment in the simulator and tell you concretely what needs to change. For apps we already maintain, updates like this are part of the maintenance and development subscription, and I wrote about what else app upkeep involves in the article on maintenance after launch.