iPhone Duo: is your app ready for Apple's foldable?

Apple took its time with folding phones, long enough for Android makers to launch several generations of them, and then did what Apple does: arrived late, gave it a nice name and brought a folio case. iPhone Duo was unveiled on 9 September, pre-orders open on 16 October and it reaches stores on 23 October, France included in the first wave, from $1,999 in the US. Very few of your users will buy one on day one at that price, but the ones who do tend to be the loud, enthusiastic kind who post screenshots, so it is worth knowing what they are about to see when they open your app.

One app, a surprising number of shapes

Closed, iPhone Duo is a phone with a 5.4-inch outer display that is wider and shorter than any other iPhone. Open, it becomes a 7.6-inch inner display with a hinge in the middle, and people will hold it half folded like a book, stand it on a table, rotate it in every direction and, for the first time on an iPhone, run two apps side by side in Split View. Your app therefore stops having "the iPhone size" and starts having any size at all, which is the main message of Apple's developer guide: resizing is the feature.

The good news is that if your app already behaves on iPad and Mac, or resizes properly in iPhone Mirroring, Apple says you are well on your way. The less good news is for the app that was laid out for one screen width in 2019 and never looked back. Apple's advice reads like a list of old sins: size views relative to their container rather than to fixed iPhone dimensions, base layout on the scene or the view's bounds rather than the screen, rely on size classes, and stop using the device idiom or the interface orientation to decide your layout. If your code still has a UIScreen.main.bounds.width somewhere deciding how wide a card should be, this is the week it gets found out.

Your tab bar has moved to the side

This is the change that will surprise the most people. On the outer display, and on the inner one in landscape, the system puts the status bar, navigation bar, toolbar and tab bar vertically along one edge to save vertical space for content. Only the inner display in portrait keeps the familiar horizontal bars.

If you use the standard containers (a NavigationStack with .toolbar in SwiftUI, items set on a view controller inside a navigation controller in UIKit), you get this for free. If your team built its own bar out of a UIToolbar or, worse, a row of buttons in an HStack, the system cannot move it, and your app will look like the one guest who did not get the memo about the dress code. There is one more detail that catches people: an item with a title but no icon, or a custom view, is not shown vertically at all. Give every toolbar item both a title and a symbol, and let the system decide which one fits:

import SwiftUI

struct InvoiceScreen: View {
    var body: some View {
        NavigationStack {
            Text("Invoice #1024")
                .navigationTitle("Invoice")
                .toolbar {
                    ToolbarItem(placement: .cancellationAction) {
                        Button("Close", systemImage: "xmark") {}
                    }
                    ToolbarItem(placement: .primaryAction) {
                        Button("Share", systemImage: "square.and.arrow.up") {}
                    }
                }
        }
    }
}

When space runs out, items overflow into the system menu from the bottom up, and a visibility priority on each item decides which ones stay longest. Apple's example is Compose in Mail: the action people use all day should be the last to disappear.

Nothing important in the crease

The diagram walks through the four situations your app meets. Closed, it runs on the small outer display with its bars on the side. Open, the same app gets the large inner display, and a split view shows the list and the detail together, the way Mail does. Half folded like a book, the middle of the screen becomes a reserved region that content should avoid. And in Split View, your app shares the inner display with another app and keeps its controls on its own outer edge.

That half-folded pose is the new one. iOS calls the fold, and the two front cameras, reserved regions: the outer camera always covers a corner, the inner camera only when it is in use, and the fold only matters while the phone is partly open. Alerts, sheets, context menus and split views step around them on their own. Your custom views do not, so a big "Pay" button centred on the screen may end up sitting right in the crease, which is not where anyone wants to tap. For those, SwiftUI and UIKit get a ReservedRegion API to find the fold and move things aside, and a new arrangement view that places a primary and a secondary view on either side of it. This example comes straight from Apple's guide:

ArrangementView {
    PrimaryView()
} secondary: {
    SecondaryView()
}
.arrangementViewStyle(.split.axes(.horizontal))

Built with Xcode 26? You get a frame

Here is the part that affects every app, updated or not. According to Apple, an app built with Xcode 26 or earlier does not extend under the status bar and the camera on iPhone Duo, so it runs with a visible margin, a bit like a painting that was framed in a hurry. To use the whole screen, you build with the latest Xcode; the Xcode 27.1 beta released on 18 September is the one with the iPhone Duo SDK and simulator, and Apple has announced iPhone Duo support in Xcode's Device Hub for previewing each pose. If you went through the Xcode 26 upgrade this year, the drill will feel familiar.

Two smaller notes. The App Store will want iPhone Duo screenshots in two new sizes, one per display, although App Store Connect only accepts them "later this year". And if your app takes photos or video, the camera you are using may suddenly face the other way when the phone is opened or closed, which is funny exactly once.

So what would I actually do?

I would install the Xcode 27.1 beta, run the app in the iPhone Duo simulator, and walk through every screen closed, open, half folded and rotated, sheets and popovers included, with a notepad. The list writes itself: custom bars that stay stuck at the bottom, buttons with no icon, layouts measured against the screen, anything sitting in the middle of the inner display. Most fixes are small once you know where they are, and the ones that are not small are usually the same fixed-width layouts that already looked odd on iPad. Then I would ship the fixes with the next regular release rather than rushing a special build, because the phone does not reach anyone's pocket before 23 October anyway.

If you want help

Checking how an app holds up on new devices and new OS versions is part of the five-day mobile app health check, and the audit checklist article shows what else it covers.

Sources: Apple Newsroom, Apple unveils iPhone Duo, Preparing your app for iPhone Duo, Human Interface Guidelines, Designing for iPhone Duo, iPhone Duo developer page, Build for iPhone Duo with new resources, Screenshot specifications.