Foldable iPhone app development: what actually changes

Apple announced iPhone Duo, its first foldable, with pre-orders on 16 October 2026 and availability on 23 October. The outer display is 5.4 inches, the inner 7.6.

Foldable iPhone app development is not a screen-size problem. It is a problem of the screen changing size while your app is running, which is a thing iOS apps have never had to survive. Android solved this years ago. iOS teams have about a month.

The four assumptions that break

Apple's Tech Talk on preparing apps for iPhone Duo is specific about what stops being true. Four things, in rough order of how much code they touch.

Interface orientation no longer decides layout

The inner display is regular in both dimensions — the trait combination iPad apps use for sidebars, now on a phone. More consequentially, the inner display does not honour supported interface orientations for normally resizable apps.

Any layout branch keyed on orientation is therefore making a decision from an input that no longer describes the situation. The replacement is size classes: @Environment(\.horizontalSizeClass) in SwiftUI, traitCollection.horizontalSizeClass in UIKit.

UIScreen.main is ambiguous and going away

On a two-display device, "the main screen" does not identify anything. Apple's guidance is direct: stop referencing it, and expect deprecation.

// Avoid
let screenScale = UIScreen.main.scale

// Instead
let screenScale = traitCollection.displayScale
let screen = window?.windowScene?.screen

This one is worth grepping for immediately, because it tends to be buried in image-scaling helpers and analytics code written years ago that nobody has opened since.

Safe areas are no longer symmetric

The common shorthand of doubling one inset assumes the opposite side matches. On this device it does not.

// Wrong — assumes left and right are equal
let width = view.bounds.width - view.safeAreaInsets.left * 2

// Correct — each side independently
let width = view.bounds.inset(by: view.safeAreaInsets).width

Keep interactive content inside the safe area and let background artwork run past it with ignoresSafeArea(). The failure mode of getting this wrong is a control that sits under the hinge or the camera on exactly one pose, which is the kind of bug that reaches production because nobody tested that pose.

The screen has regions you must route around

iOS 27.1 introduces reserved regions, queried through reservedRegion on a GeometryProxy or a UIView. Two kinds: division regions describe the fold itself, occlusion regions describe obstructions such as the active inner camera.

This is the genuinely new concept. Previously the usable area was a rectangle minus insets. Now it is a rectangle with a seam through it and possibly a hole, and custom layouts that want maximum space have to ask where those are rather than assume.

One consequence of reserved regions is worth stating separately: content is no longer safe simply because it is inside the safe area. A control can sit within the insets and still land on the crease. Anything the user needs to hit precisely — a slider, a signature field, a small close button — should be positioned against the reserved regions rather than against the bounds.

What Apple recommends instead of custom layout

The consistent advice is to adopt the adaptive containers rather than reimplement them, because they already handle every pose.

• NavigationSplitView and UISplitViewController for hierarchy — they collapse and expand across the fold without intervention.
• TabView and UITabBarController, with .defaultTabBarPlacement(.sidebar) so tabs become a sidebar where there is room.
• Concentricity APIs such as ConcentricRectangle so corner radii match the display rather than approximating it.

Apple's own Mail is cited as adapting across six layouts including closed, open, landscape, portrait and partially folded. Six is the number worth internalising when someone asks how much QA this needs.

The pose nobody tests

Six poses sounds like six test cases. It is not, because the interesting one is the transition rather than any of the endpoints.

An app opened while folded, then unfolded, is a different code path from an app launched already unfolded. The first goes through a live trait change with a populated view hierarchy; the second builds everything once against the final size. Almost every bug in this category lives in the first path, and almost every manual test exercises the second, because launching the simulator in a pose is easier than changing pose while watching.

Partially folded deserves its own mention. It is a real state the device reports, not a transient animation frame, and layouts that assume a fully open or fully closed geometry will position content across a crease that is currently at an angle.

The part that is not in the API

Every item above is mechanical. The hard part is state, and it is not something Apple can hand you an API for.

A user unfolds the device mid-task. Your app receives a size class change and a bounds change. What should happen to the text they were halfway through typing, the scroll position they had found, the sheet that was presented, the video playing, the form with three fields filled in?

Nothing forces you to answer these. The app will not crash if you get them wrong — it will just quietly discard what the user was doing, and they will describe that as the app being broken. A view hierarchy rebuilt on a trait change is the default behaviour in a lot of code, and on every previous iPhone it only happened on rotation, which users initiate deliberately and rarely mid-sentence.

The practical test: open your app, start something that takes attention, fold or unfold, and see whether you can carry on. Then do it on all six poses.

What you can do before the hardware exists

All of it, as it happens. Xcode 27.1 ships an iPhone Duo simulator, and its Device Hub simulates the poses — opening, closing, rotating, partially folding. The App Resizability skill covers SwiftUI and Duo.

Existing apps do run unmodified. Rebuilding against the iOS 27.1 SDK is what enables edge-to-edge content and vertical bars, so "it works already" and "it looks like it belongs" are two different states, and only one of them is a decision you have made.

A reasonable order of work for a team with an app in the store and four weeks:

• Grep for UIScreen.main, interface-orientation branches and doubled safe-area insets. Fix them. This is most of the mechanical risk and it is a day.
• Run the app in the simulator across all six poses and write down what breaks. Do not fix yet — the list tells you whether this is a week or a quarter.
• Fix state preservation on the flows that matter commercially. Checkout, sign-up, anything with a form.
• Only then consider adopting sidebar placements and reserved regions to use the extra space well.

Teams that invert the last two build a beautiful sidebar for a screen that loses the user's basket when they unfold it.

What this costs, roughly

For a single-screen utility with no forms, the defensive pass is a day and there is nothing else to do. For a typical commerce or content app with authentication, a cart or a feed, expect a week to get through the mechanical fixes and the pose sweep, and a second week if state preservation turns out to be broken on more than one flow.

The number that actually varies is how much of your layout was written against orientation. Codebases that adopted size classes when iPad multitasking arrived will find this nearly free. Codebases that branched on isLandscape because the app was iPhone-only and always would be will find the work is proportional to how many screens they have.

Whether this matters to you yet

Honestly: for most apps, not much, and not immediately. First-generation foldable volumes will be small, and the first two items on that list are defensive work that costs a day.

It matters more if you are shipping something where sessions are long and interruption is expensive — anything with a form, a cart, a media player, or a document. It matters most if your app is the thing someone would unfold for, which is the same argument as tablet support and has the same answer.

If you build cross-platform, this is also the moment the framework choice shows its hand: adaptive behaviour on a new form factor depends on how quickly your framework surfaces the new APIs, and that varies.

We build iOS and cross-platform apps, and we are treating the grep-and-fix pass as standard maintenance for every app we maintain rather than a project anyone needs to approve. The state-preservation work is the part worth scoping deliberately. If you want a read on which of your flows would actually break, that is a short conversation.