Frequently asked questions

No. Apps built without the iOS 27 SDK run on iPhone Duo at a familiar size and aspect ratio. Your app will launch and function.

What it will not do is use the display. Apple defined three tiers: without the iOS 27 SDK you get the familiar size; with the iOS 27 SDK your app extends left of the status bar area; only with the iOS 27.1 SDK does it reach the screen edge with vertically laid out bar buttons.

So this is a competitive problem rather than a functional one — your app will look dated beside one that fills the 7.6-inch display.

Apple publishes pixel dimensions. The inner folding display is 7.6 inches at 1878 × 2670 pixels and 430 ppi. The outer cover display is 5.4 inches at 1398 × 2034 pixels and 460 ppi.

At a @3x scale factor that works out to 626 × 890 points for the inner display and 466 × 678 points for the outer. Note that the point figures are derived by dividing the published pixel dimensions by three, not published by Apple directly.

The inner display’s aspect ratio is roughly 1.42, against about 2.17 for iPhone 18 Pro — a substantially squarer screen, which is why fixed-aspect content letterboxes.

Four changes account for most of the visible improvement, and none of them require the new APIs:

1. Remove hard-coded screen widths and fixed frame sizes.
2. Stop relying on supported interface orientations — the inner display ignores them. Use size classes instead.
3. Handle safe area insets as asymmetric; never double one side to account for the other.
4. Remove layout branches gated on user interface idiom, which reports phone on a regular-width display.

Rebuild against the iOS 27.1 SDK, then work through those. Adopting ArrangementView and reserved regions is worthwhile afterwards, but it is upside rather than the baseline.

Neither vendor has shipped iPhone Duo support or published guidance, as of 9 September 2026.

Both will still work. React Native’s flexbox layout and Flutter’s constraint-based layout both adapt when the native view is resized, so an app built without fixed pixel values reflows correctly.

What neither can reach today is the fold-aware API surface — reserved regions, arrangements, hinge angle, scene accessories and the vertical bar APIs have no JavaScript or Dart bindings. Getting at them requires a native module or platform channel.

Flutter is closest to ready in principle, because MediaQuery.displayFeatures already models hinges and cutouts for Android foldables. Whether the iOS embedder populates it for iPhone Duo is unconfirmed — assume it is empty and verify on a real build.

Xcode 27.1 or later. It includes the iPhone Duo simulator, accessible through Device Hub with on-screen controls to open, close, rotate and fold the device, and the SDK that lets your app reach the screen edge.

Xcode 27.1 also extends the app modernization skill — previously “Modernize your UIKit app” — to cover SwiftUI and iPhone Duo under the name App Resizability.

Note that on 9 September 2026 Apple listed Xcode 27.1 as beta and “coming later this month”, alongside the written documentation and the Human Interface Guidelines page. Until those ship, the six Tech Talk videos are the authoritative source.

Yes, when the device is partially folded. The hinge divides the inner display into separate usable regions, and content across that division is physically bent away from the viewer.

The API for this is ReservedRegion in SwiftUI and UIViewReservedRegion in UIKit, querying kind: .division. The important behaviour is that a division region is active only while the device is folded and has zero width when flat, so your layout must handle regions appearing and disappearing rather than simply moving.

For most main-and-secondary layouts you do not need to query regions directly. ArrangementView already takes active division regions as an input and places your views accordingly.

It depends almost entirely on how much your layout code assumes a fixed screen size.

An app already built with adaptive layout and an iPad target is often a few days of audit and refinement — the inner display is regular-width in both dimensions, which is the environment an iPad layout already targets.

An iPhone-only app with hard-coded dimensions, orientation locks and custom navigation containers is a larger piece of work, because the fixes touch layout code throughout rather than in one place.

Games and apps with custom-drawn full-bleed surfaces sit at the harder end, since resolution changes mid-session and the fold has to be handled explicitly.

We have seen third-party reports that iPhone Duo uses Touch ID rather than Face ID, which would mean LAContext.biometryType returns a different value than your app may expect, and any UI hard-coding a Face ID icon or the phrase “Face ID” would be wrong.

We have not been able to confirm this from Apple’s own developer material, so treat it as unverified and check biometryType at runtime rather than assuming either one. That is good practice regardless — it is the reason the API exists.