How to adapt your iOS app to iPhone Duo

Your iPhone app stays an iPhone app on iPhone Duo. Apple's guidance in "Prepare your app for iPhone Duo" is direct about it: avoid making assumptions about display sizes or device capabilities based on user interface idioms. Apple hasn't published what userInterfaceIdiom returns on the device, and the talks say only that it's still an iPhone app, so don't branch on it. There's no iPad code path to revive and no separate target to build.

What you get instead is a second display with a different shape, a hinge that can divide it, and bars that move to the side. The inner display reports regular size classes in both dimensions. The outer display reports compact width. Two layout branches cover the device.

Most of what follows is work you can start today, on the Xcode you already have. The SDK-level items need Xcode 27, which shipped on September 14.

Do you need a new layout for iPhone Duo?

You need two layout branches, and size classes tell you which one you're in.

Apple hasn't published size classes for a 50/50 Split View on the inner display. Our expectation is compact width, and we'd treat that as an assumption until the beta confirms it.

Orientation deserves care, because Apple says two things that sound opposed. In one place, the inner display doesn't honor your supported interface orientations. In another, iPhone Duo respects your supported interface orientations while your app scales on the inner display, including in Split View multitasking. The practical reading: an app with fixed orientations gets scaled rather than rotated, and your layout decisions should come from size classes either way.

The screen proportions are the part that catches vertical layouts. Calculated from the published specs, the inner display works out to roughly 1.42 (2670/1878) and the outer to roughly 1.45 (2034/1398), which sits between iPad at 1.33 and iPhone at 2.17, closer to 3:2. Apple's newsroom describes the two displays as sharing the same aspect ratio. Either way, both sit far from 19.5:9, so a layout built for 2.17 fills neither. A 16:9 video gets letterboxed. A vertical stack built for 19.5:9 gets either emptiness or a crop.

One more thing to grep for. iPhone Duo has Touch ID in the side button, and Apple's specs and newsroom post don't mention Face ID. If your app hardcodes the string "Face ID" anywhere, read LAContext.biometryType after canEvaluatePolicy instead.

How much can you fix before the beta ships?

Most of it, because the bulk of this work is resizability debt that predates iPhone Duo.

Start with a grep audit: UIScreen.main, userInterfaceIdiom, interfaceOrientation and UIDevice.current.orientation, UIRequiresFullScreen, supportedInterfaceOrientations, your own UIToolbar, UITabBar and UINavigationBar instances, safeAreaInsets.left * 2, hardcoded widths, and any screen size cached in a singleton.

// Screen to window/scene
let screenBounds = UIScreen.main.bounds   // ❌ deprecated since iOS 26
let scene = view.window?.windowScene
let windowBounds = scene?.effectiveGeometry.coordinateSpace.bounds ?? .zero   // ✅ scene, iOS 26+
// before iOS 26: wrap in if #available(iOS 26, *) and fall back to scene?.coordinateSpace.bounds
let scale = traitCollection.displayScale   // ✅

// Idiom and orientation to size class
if UIDevice.current.userInterfaceIdiom == .pad { applyWideLayout() }   // ❌ don't branch on idiom
@Environment(\.horizontalSizeClass) var hSize                // ✅ SwiftUI
registerForTraitChanges([UITraitHorizontalSizeClass.self]) { (self: Self, _) in   // ✅ UIKit, iOS 17+
    self.relayout(wide: self.traitCollection.horizontalSizeClass == .regular)
}

// Safe area is asymmetric: the vertical bar also appears on the left
let usableWrong = view.bounds.width - view.safeAreaInsets.left * 2   // ❌ assumes symmetry
let usable = view.bounds.inset(by: view.safeAreaInsets).width        // ✅

// Multi-window: new scenes only on the inner display, so refusal is normal
// Prefer UIWindowScene.ActivationAction (iOS 15): it hides itself when windows aren't available.
// The request below is the manual fallback.
let request = UISceneSessionActivationRequest(role: .windowApplication)   // iOS 17+
UIApplication.shared.activateSceneSession(for: request) { _ in presentInlineFallback() }

Replace fixed widths and device-model breakpoints with size classes, maxWidth, and layout margins. Apple's design session puts it plainly: avoid fixed widths, breakpoints, or any metrics tied to a specific screen. In xib and storyboard files, turn on Use Safe Area Layout Guides and constrain to the safe area.

One requirement and one deprecation to plan around. UIKit apps built against the iOS 27 SDK need the UIScene lifecycle, which WWDC25 described as required when building with the latest SDK from the release after iOS 26. Builds on older SDKs aren't affected. Separately, UIRequiresFullScreen is deprecated and will be ignored in a future release. iPhone Duo continues to honor it, and your window still resizes regardless, so don't lean on it.

Drop the orientation lock if it's only there because one or two of your screens don't lay out correctly when rotated, and fix those screens instead. Games are the exception: the HIG allows the lock, asks you to fill the display in every pose, and treats letterboxing as a last resort with artwork in the margins.

What do you get from rebuilding?

Your build target decides how much of the screen your app can use, and there are three tiers.

System containers carry most of the pose handling once you rebuild.

For regular width, Apple's design session offers three approaches: a split view exposing more hierarchy at once, reflowing a vertical stack into two columns as Music does, and a tab bar as a sidebar for dense apps as Health does. Your hierarchy stays the same across both displays.

Some of this is already available on the iOS 27 SDK. If you built your own overflow menu, move those actions into ToolbarOverflowMenu in SwiftUI (new in iOS 27) or UINavigationItem.additionalOverflowItems in UIKit, available since iOS 16. Item priorities come from ToolbarItemVisibilityPriority and UIBarButtonItem.visibilityPriority, both new in iOS 27.

Where do your bars go?

Into a vertical strip along the side, on the outer display and on the inner display in landscape.

Navigation buttons, toolbar items, tab bar, status bar, and Dynamic Island share that strip. In right-to-left layouts the bar stays on the same physical side. Inner display portrait keeps ordinary horizontal bars. This starts working after you rebuild against the iOS 27.1 SDK, and only for bars owned by system containers pinned to the display edge. In a NavigationSplitView or UISplitViewController, only the detail column participates. Content from a hand-built UIToolbar or UITabBar won't be considered.

Symbol-only items are what the vertical bar is built for, since its width is fixed and its item height is flexible. Text-only items stay horizontal. Give every item a title even when it shows only a symbol, because the system uses that title in the overflow menu. Where text duplicates the icon, drop it and use a symbol with the badge API added in iOS 26. Where text carries data, such as a cart total, keep the item horizontal.

Order runs top to bottom: the back button, which a navigation controller adds for you, or a custom close button in the cancellation action slot, then the prominent action such as Done, then remaining groups in their original order.

Custom views stay horizontal by default and opt in through AxisBehavior. Read toolbarVerticalEdge to find out whether a vertical bar is present at all: it's populated when items can go on the vertical axis and unspecified when they can't. Don't add your own spacers.

Overflow happens more often here, in outer display landscape, with the keyboard up, and with Picture in Picture parked at the top. toolbarCompressionBehavior decides whether the toolbar or the tab bar compresses first. AxisBehavior, toolbarVerticalEdge, toolbarCompressionBehavior, toolbarVerticalBehavior and preferredVerticalBarBehavior are names from the Tech Talk and aren't in any shipped SDK yet. The overflow menu and visibility priorities already ship in iOS 27.

Leave the default placement alone, as the HIG asks. Apple suggests considering the opt-out, toolbarVerticalBehavior or preferredVerticalBarBehavior, for single-page apps with a bottom-heavy layout and for sheets whose only control is a close button.

How do you handle the fold?

Treat the fold as an obstacle inside your layout rather than an edge of it, which is what reserved regions describe.

A reserved region is an area claimed by hardware inside a larger usable area, and it isn't part of the safe area. The division kind is the fold: active only while the device is partially folded, and zero width when the screen is flat. The occlusion kind is the inner FaceTime camera, active only while the camera is active. The outer camera is a permanent reserved region, and the system accounts for it on its own when your controls are in the side strip.

// Pre-release, iOS 27.1 SDK. Do not treat as copy-paste.
// Method names as spoken in the Tech Talk; signatures unverified.
GeometryReader { proxy in
    let foldRegions = proxy.reservedRegion(kind: .division)   // each region has a frame
    MyLayout(avoiding: foldRegions)   // your layout
}

Apple calls the pattern of moving elements clear of these regions displacement, and the rules are consistent across the layout, design, and HIG guidance. Move interactive elements out of the fold: toward the trailing side in the book pose, downward in the tabletop pose with viewing content going up. Leave scrolling content alone. Move related elements together, and not far. In a grid, prefer an even number of columns, which the includeInactive option supports by reporting the region even on a flat screen. Favor small adjustments over rearrangement. Sheets, alerts, menus, popovers, and split views are displaced by the system.

When should you reach for ArrangementView?

When you're hand-coding a two-view layout that should change with the geometry.

ArrangementView and UIArrangementViewController take a primary and a secondary view. The split style divides the area, horizontally when the area is wider than it is tall and vertically when it's taller. The overlay style stacks the views and moves them side by side once the device folds.

// Pre-release, iOS 27.1 SDK. Do not treat as copy-paste.
NavigationStack {
    ArrangementView { PlayerView() } secondary: { UpNextView() }
        .arrangementViewStyle(.split)   // .split.axes(.horizontal), .overlay
}

Keep navigation containers outside the arrangement, and don't put an arrangement inside a List or ScrollView. The hinge API, onHingeChange and UIHingeInteraction, is for effects driven by the hinge's discrete status (closed, partially open, fully open) and its continuous angle. It isn't a layout input.

ArrangementView, UIArrangementViewController, onHingeChange and UIHingeInteraction are names from the Tech Talks. None is in a shipped SDK yet.

What happens to your paywall?

A paywall built as one vertical stack breaks on both displays as soon as your app fills them.

The hero, headline, plans, and CTA sequence assumes 19.5:9. Filling a full screen at 1.42 to 1.45 from a 19.5:9 asset loses roughly a third of the height by our calculation. At regular width, go to two columns. Our recommendation is visual in one column, plans and CTA in the other, with the CTA and plan picker kept out of the fold.

Three more paywall specifics. Put the close button of a full-screen paywall in the cancellationAction placement in SwiftUI, or as a leading item with leftItemsSupplementBackButton = false in UIKit, which is the top slot Apple asks you to reserve for back and close wherever the bars go vertical. If you draw your own, respect each safe-area inset separately, or it lands under the status bar and camera, or on the wrong edge in Split View. If your paywall sheet has a toolbar, that toolbar goes vertical on the outer display, and a sheet with only a close button is a candidate for the opt-out above. The purchase confirmation sheet is system-owned and you don't change it, so the only strings to revisit are your own references to Face ID.

On our side: Adapty renders paywalls natively in SwiftUI inside your own window and re-measures from the window on every resize. Builder configs can already branch at render time on window width and height and flip a stack between vertical and horizontal, which is the mechanism a two-column regular-width paywall needs, and it re-evaluates when the window resizes. Nothing in the renderer branches on userInterfaceIdiom. We'll run our templates through the iPhone Duo simulator once the Xcode 27.1 beta ships and share what we find.

How do you test it?

Once the Xcode 27.1 beta ships, open Device Hub, select iPhone Duo, and use the controls to open, close, rotate, and fold the device. For Split View, drag your app by the home indicator to one edge, then to the other.

Before the beta, iPhone Mirroring on a Mac gets you part of the way, since iOS 27 lets you resize your app larger than before. iPad Split View or Stage Manager stands in for window resizing and compact width only, and neither reproduces the vertical bars or the outer display's proportions.

Walk this matrix: closed portrait and landscape, open portrait and landscape, partially folded in book and tabletop poses, Split View on the left and on the right, Picture in Picture at the top, and right-to-left. In each, check that nothing interactive sits under a bar, the camera, or the fold, that the layout recalculates without a relaunch, that every action in the overflow menu has a title, and that hero images and video aren't cropped in a way that loses their meaning.

Two release-side items. App Store Connect lists separate screenshot sizes for the outer display (1398×2034 or 2034×1398) and the inner display (2007×2853 or 2853×2007, larger than the panel's 1878×2670), and uploading them will be possible "later this year" per Apple. And any snapshot test pinned to device dimensions needs revisiting.

Cameras are their own subject. iPhone Duo has two front cameras, ordinary discovery returns a Virtual Front Camera that switches between them, and that virtual camera is capped at 1080p and 60fps with no depth. For depth, or for 4K and 120fps from the outer camera, address the cameras individually and adopt AVCaptureDeviceDirectionCoordinator, announced in the Tech Talk and not yet in a shipped SDK. The inner camera stays at 1080p and 60fps either way.

What to do this week

Apple runs iPhone Duo Group Labs on September 16 and 17, and forum Q&As for SwiftUI, UIKit, and Photos & Camera on September 23. The "Preparing your app for iPhone Duo" guide and the workshops are also coming later this month.

Before the Xcode 27.1 beta

• Migrate UIKit apps to the UIScene lifecycle
• Run the grep audit
• Replace idiom and orientation branches with size classes
• Handle each safe area inset separately
• Move your bars into system containers, with a title and symbol on every item
• Handle scene request refusals

After it lands

• Rebuild and walk every pose in Device Hub
• Fix vertical bar ordering
• Turn centered layouts into two columns
• Put reserved regions around your important controls

If your paywall is one of those centered layouts, our SwiftUI setup guide covers moving it behind remote configuration so the fix doesn't need a release.

Yurii KleimenovProduct Lead, Adapty Core