The questions developers ask about iPhone Duo

You care today only if you want to look right on day one. The device ships with iOS 27.1, and the SDK that adds full Duo support, Xcode 27.1, lands later this month. Meanwhile the useful work is free: rebuild against the iOS 27 SDK, delete your screen-size assumptions, and run the app in a resizable window.

Our reading: the teams that look prepared on 23 October will be the ones doing this now, not the ones waiting for the SDK to arrive.

No. Once you link against iOS 27 you get resizability, and Apple was explicit that there is no flag to keep the old fixed behaviour.

Our reading: this is the most consequential answer of the session, because it turns "should we support the Duo?" into "our app now has to survive a wide, short window". That work is worth doing anyway. It is the same adaptation an iPad or a resized window already asks for.

Three things, in order: rebuild against the iOS 27 SDK, adopt size classes instead of orientation branches, and remove UIScreen.main in favour of scene geometry. Apple's own testing suggestion is unglamorous and effective: resize your app in iPhone Mirroring, which gives a near-Duo aspect ratio without changing what the frameworks think the device is.

Our reading: if your app already behaves on iPad, most of this is done. What is left is usually custom bars and hard-coded inset maths.

Updated SDKs, a new version of deviceHub that knows all the Duo poses and orientations, and an updated modernize-your-app skill that now covers SwiftUI as well as UIKit and understands the Duo. Xcode 27.2 beta is already out, but the device ships with 27.1, so do not build a release plan around 27.2 features.

Our reading: the modernize skill is the cheapest first pass at the patterns that break on a resizable screen. Treat its output as a diff to review, not a fix.

Update, 18 September 2026: not anymore — Xcode 27.1 beta ships the iPhone Duo Simulator runtime. What the beta gives you, and what does not work in it yet. Alongside it, Apple's recommended combination remains a resizable iPhone plus deviceHub, which is genuinely good at finding layout-guide and corner-interaction mistakes. The team behind the TV app found most of their bugs that way, reproducing them by resizing.

Our reading: what you cannot verify before hardware is anything pose-reactive: fold angles, seated positions, the 50/50 partial fold. Plan a device pass for those.

Yes. Supported orientations are honoured on the outer display but ignored on the inner display, where your app gets a regular/regular environment and adapts whether you asked for it or not. A portrait lock is not a shield. The recommended replacement is width-based decisions: ask how much room you have, not which way the device is held.

Our reading: the practical fix is to visit every interfaceOrientation check and ask what it was really protecting, usually a column count or a control position, then key that off size instead.

Orientation is still exposed as an environment value and a trait, so technically you can. Apple's advice is not to lead with it: decide from available width, the way App Store and Health switch between one and two columns. Same content, rearranged.

Our reading: width-based rules also survive Split View, where each app gets half the screen and "orientation" stops describing much of anything.

No, and this was Apple's most repeated point, including as its answer to "what is the biggest design mistake you are seeing". Their own designers burned time trying to make every pose a moment before concluding that supporting the staples covers almost everything. Extras should exist only where they genuinely serve the app, with a video player moving controls to the bottom when seated as the canonical example.

Our reading: treat pose-specific work as a second release, and animate transitions rather than cutting between layouts. A hard cut between two arrangements reads as a glitch.

Neither, as a mental model. Apple wants it read as one device that got wider, not "a phone closed, an iPad open": no separate window management, no per-state settings, and opening an app should feel like resizing its window. That said, an app that is already good on iPad has done most of the work.

Our reading: the practical test is "does my app look sane in a resizable window on a Mac or an iPad?" If yes, the Duo is mostly free.

In practice you get two columns at a time, with the root column as an overlay that slides in, the Mail pattern. Use NavigationSplitView in SwiftUI or UISplitViewController in UIKit, and consider configuring a tab view to present its tabs as a sidebar when wide. Partially folding gives you a 50/50 split for free if you are on those containers.

Our reading: if you hand-rolled a three-column shell, this is the biggest single piece of Duo work in your codebase, and moving to the system containers pays off on iPad too.

Only if it is a system tab bar. UITabBarController and SwiftUI TabView adapt with no extra work. A UITabBar you added as a subview, or a fully hand-drawn bar, will not: you are left aligning against the vertical bar's metrics yourself. Apple's own Maps and Find My teams spent the year migrating fake toolbars onto navigation and tab controllers precisely to get this for free.

Our reading: for most apps that migration is less work than emulating the vertical bar, and it also buys the system behaviour people notice, such as labels appearing on touchdown.

Against the camera side. The vertical bar follows the camera as you rotate, so it can be left or right. In Split View the left-hand app takes the left-hand bar. There is also a system variant worth testing: with Reduce Transparency on, an opaque rectangle is drawn behind the vertical bar.

Our reading: anything that assumed a bar at the bottom on both edges is where bugs will come from, including your screenshots and help content.

Symmetry. Side safe areas and content insets are asymmetric because the bar is only on one side, and portrait-only apps are the worst offenders since they only ever worried about top and bottom. Read the real insets and layout guides from the system instead of balancing them yourself. Watch for the friendly trap: code that works because the broken assumption was never exercised.

Our reading: resizing in iPhone Mirroring and dragging window corners surfaces most of these before you have hardware in hand.

Only if you are a camera app with the system entitlement and an active camera session. The entitlement alone does nothing. The shipping example is Kid Cue: a large camera preview inside, an animation outside holding a child's attention. Everyone else gets one display at a time.

Our reading: if a feature idea depends on "content on one screen, controls on the other", drop it now rather than discovering this at implementation time.

Depends on whether the tabs describe the sheet or the app. Find My kept them together, because every tab fills the same sheet and separating would have put two unrelated things on screen. If a tab owns its own sheet, separating can be right.

Our reading: the test question is "what does this tab change about the screen?" If the answer is "the contents of that panel", keep them together.

Same model as iPad: two views of your app side by side, or paired with other apps. Instances of the same app share state and storage, and updates flow through the SwiftUI and UIKit mechanisms you already use.

Our reading: worth an audit if you cache "the" current document or selection in a global. Two instances on one screen makes that assumption visible.

Dynamic Type and the readable content guide matter more on a larger canvas, and Reduce Transparency changes what sits behind the vertical bar. The milestone worth noting: VoiceOver now spans both displays at once, which Apple called a first.

Our reading: test at the largest accessibility text sizes on the inner display, which is where a resizable layout is most likely to fall apart.

Yes. Hide the status bar and behave like any full-screen app. Using the vertical controls is not mandatory if they do not fit, and immersive or AR-style experiences were named explicitly.

Our reading: choose it deliberately for audio, games or camera work, not as a way to avoid adapting. The screen still resizes.

The panel did not know of an API for it, so do not design around detection. Both orientations behave the same, which means the safer route is supporting either.

No WebKit expert was on the panel. Apple pointed at the existing JavaScript standards for foldables and asked for feedback once the SDK lands this month.

Answered with "it is magic, you do not need to worry about it", which is charming but not a specification. If your app maps accelerometer axes to the screen, treat this as unverified.