iPhone Duo ships on 23 October 2026, and if you have an app on the App Store the first question is what you are obliged to change. Apple's answer, from the Tech Talk Prepare your app for iPhone Duo: “Your app runs on iPhone Duo even without recompiling, but screen usage improves with each SDK.”
That sentence is the whole shape of it. There is no device family to declare, no capability key for your Info.plist, and no second binary. The only lever Apple documents is which SDK you build against — plus the assumptions your existing layout code makes about orientation, the main screen and symmetric insets.
Everything below was read on 10 September 2026 from Apple's own pages: the six Duo Tech Talks (111461–111466), the new HIG page Designing for iPhone Duo, Apple's Duo developer page, the Newsroom release and the hardware specifications. The App Store half — screenshot sizes, and what App Store Connect will accept and when — has its own post.
There is nothing to declare
This deserves saying early, because it is the claim most likely to be invented over the next month. Across eleven Apple pages — the HIG page, both App Store Connect specification pages, the Newsroom release, the developer page and all six Tech Talks — searching for UIRequiredDeviceCapabilities, UIDeviceFamily, UIRequiresFullScreen, Info.plist, “device capabilit” and “Designed for iPhone” returns zero hits in every file.
So: no new device family, no capability declaration, no separate binary, no plist change. If you read that the Duo needs one, ask which Apple page says so.
There is also no deadline. Apple's Get Ready for iPhone Duo page, 116,456 bytes on 10 September 2026, contains no occurrence of “deadline”, “mandatory”, “required by”, “will be required” or “no later than”. A specific cut-off date has been circulating in developer forums with nothing attached to it; that page publishes none, and which SDK you build against stays your decision until Apple says otherwise.
One key is worth a look even though it appears in none of those Duo sources: UIRequiresFullScreen. Apple's documentation marks it deprecated as of iOS 26.0 and iPadOS 26.0, having introduced it in 9.0, and states that “Opting out of iPad multitasking and dynamic resizing is deprecated.” The replacement Apple names is a combination of UISceneSizeRestrictions and prefersInterfaceOrientationLocked, and the instruction is to handle multitasking and dynamic resizing, then remove the key.
There is a documented escape hatch worth knowing before you need it: if you still need the key for earlier iOS versions, Apple says to add UIRequiresFullScreenIgnoredStartingWithVersion and name the version from which the system should start ignoring it. The migration is TN3192. None of this is Duo-specific — it arrived with iOS 26 — but a device whose whole premise is resizing is where an app still opting out of it will show.
The SDK is the opt-in
Apple's chapter summary continues: the iOS 27 SDK “extends your app left of the status bar on the inner display”, while the iOS 27.1 SDK “reaches the screen edge” and lays standard navigation and toolbar buttons out vertically.
Read it closely: it attaches “on the inner display” to the iOS 27 behaviour and names no display at all for the iOS 27.1 one. Apple also states that iPhone Duo “will be available with iOS 27.1”, so the SDK that gives you the most matches the OS version the device ships with. The SDK itself arrives with Xcode 27.1, which is a separate date and not the hardware's — see the tooling section below.
The 27.1 SDK adds one thing worth knowing by name before you need it: ReservedRegion in SwiftUI and UIViewReservedRegion in UIKit, which Apple says let custom UI claim as much screen space as possible “without colliding with system UI”. If you have hand-drawn chrome that currently avoids the system by hard-coded inset, that is the API to look at.
Four assumptions your layout code probably makes
Each of these is something Apple states directly, and each is the kind of code that keeps working everywhere else while failing on one device.
| What the code assumes | Apple's wording | What replaces it |
|---|---|---|
| Orientation tells you the layout | “The inner display doesn't honor supported interface orientations” | Size classes. The inner display is regular in both dimensions |
| The main screen is your screen | “Don't reference the main screen on a two-display device — it's ambiguous and will be deprecated” | traitCollection.displayScale instead of UIScreen.main.scale; window?.windowScene?.screen for a screen |
| Opposite insets are equal | “Avoid assuming insets on opposite sides are equal” (comment in Apple's sample) | Handle each edge independently, and test in Split View |
| A fixed width is safe | “Avoid fixed widths and display-specific dependencies” (HIG) | Layout margins and safe area insets |
The orientation one is most likely to hurt, because it fails quietly. A layout decision taken from supportedInterfaceOrientations, or a portrait-versus-landscape branch, has no input on a display that does not honor orientations. That consequence is our reading rather than Apple's wording: nothing errors, and the layout gets made for a shape the device is not in. Apple's guidance is to decide on size classes, and it adds the useful part — the inner display is regular in both dimensions, the trait combination that leaves room for a sidebar.
The main-screen one is worth grepping for today. “Ambiguous” is precise: with two displays there is no single main screen. Apple says the API will be deprecated, not that it already is — so the call still compiles, and what it hands back is the thing Apple calls ambiguous.
The safe-area one is the least intuitive. Apple's phrasing is that safe areas and layout margins are “often asymmetric” here, and that you should handle each side independently and test in Split View. Anything reading one inset and applying it to both edges is wrong on this device — and there is no number to hard-code instead, because Apple has published no point dimensions and no scale factor for either display, which the screenshot post covers.
The two displays are not the same problem
Two Apple sentences from the same day.
The Tech Talk: the outer display “behaves like other iPhone models”, while the inner is “regular in both dimensions, leaving room for sidebars”.
The HIG: because the outer display is “wider and shorter than the display on other iPhone devices”, the system “moves controls to the side” to preserve vertical space and reflect the display's asymmetry.
These are not in conflict, but reading the first as “the outer display is like other iPhones” would be a mistake. It says the display behaves like other iPhone models — a claim about traits, not shape. Its shape, per the second sentence, differs from every other iPhone Apple sells, and the system responds by moving controls sideways. Behaviour and geometry are separate claims, and only one says “same”.
The hardware is a 7.6-inch inner display and a 5.4-inch outer one, both ProMotion up to 120Hz, both with Dynamic Island and Always-On. Apple's own footnote is the line a layout engineer should read twice: measured “as a standard rectangular shape” those screens are 7.58 and 5.36 inches, and the “actual viewable area is less”.
The HIG's summary of the design problem is not really about two displays at all: because the device has two displays and supports “a wide range of poses and Split View multitasking”, an app “can appear at many different sizes”. Two displays is countable. Poses multiplied by Split View is not, which is why the guidance is resize-first rather than a list of two layouts.
Which talk holds which API
Apple published six Duo Tech Talks. These are the symbols appearing as code samples on their pages, which is not documentation of what they do — the Preparing your app for iPhone Duo guide is listed as still to come.
| Talk | Title | Symbols on the page |
|---|---|---|
| 111461 | Prepare your app for iPhone Duo | ConcentricRectangle / UICornerConfiguration; ReservedRegion / UIViewReservedRegion |
| 111462 | Raise the bar | axisBehavior(.verticalPreferred), .horizontalOnly, toolbarVerticalEdge, ToolbarOverflowMenu |
| 111463 | Strike a pose with adaptive layouts | ArrangementView / UIArrangementViewController, with .split and .overlay |
| 111464 | Leverage multiple displays and scenes | onHingeChange / UIHingeInteraction, reporting hinge.status == .partiallyOpen and hinge.angle; .sceneAccessory / CameraCaptureAccessory |
| 111465 | Build a great camera experience | none captured in this pass |
| 111466 | Design for iPhone Duo | none captured in this pass |
A blank cell means no code sample was captured when these pages were read, not that the talk contains none.
Two things stand out. ConcentricRectangle and UICornerConfiguration are iOS 26 APIs, not iOS 27 — they appear in a Duo talk but are not Duo-specific, and you do not need 27.1 to adopt them. And hinge.status == .partiallyOpen names a state neither fully open nor closed — the only case in Apple's sample. Whether your app is asked to draw during one is not something either page states.
None of those symbols come with behaviour you can rely on from the name. Inferring what .split and .overlay each do from the word is how folklore gets written.
The tooling has shipped, or has not, depending on the page
Apple's Tech Talk chapter text tells you to download Xcode 27.1 and run the iPhone Duo simulator in Device Hub, with on-screen controls to open, close, rotate and fold the device.
Apple's Duo developer page lists Xcode 27.1 beta as “Coming later this month”, alongside the Preparing your app for iPhone Duo documentation, also “Coming later this month”. The Newsroom release describes Device Hub support in Xcode as “upcoming”.
Two Apple sources of three say the tooling is not out. Plan on the two, and treat the chapter text as written against a build you may not have. Apple is running Group Labs on 16 and 17 September and Forum Q&As on 23 September, which is the one listed place a question about .split versus .overlay could get an answer from Apple.
What this post cannot tell you
Whether any of this does anything for your business. Across eleven Apple pages — the HIG page, both App Store Connect specification pages, the Newsroom release, the developer page and all six Tech Talks — searching for “conversion rate”, “convert better”, “more downloads”, “rank higher”, “ranking”, “featured more”, “drive downloads” and “boost” returns zero matches. Apple makes no claim that adapting to the Duo improves anything commercially, and Apple's two Duo developer surfaces do not mention the App Store at all. Adapt because your app looks wrong otherwise, not because a page promised you a number.
What the new APIs do. Symbol names on a talk page are not a specification. Apple's own guide is pending, and anything written about ArrangementView or UIHingeInteraction before it lands is reading a code sample, the same as this post.
Whether your layout is right. Nothing here was run on hardware or in a simulator — the device does not reach a customer until 23 October, and by two of Apple's three statements the simulator is not out either. This is a reading of Apple's pages.
Any point size, breakpoint or width. Apple has published no point dimensions and no scale factor for either display. The figures circulating are arithmetic from an assumed scale factor, not a specification, and a breakpoint derived from them is a guess wearing a number.
The work that does not depend on any of that is available today: grep your project for every branch on orientation, every read of the main screen, and every place a leading inset is reused as a trailing one. That list is exactly as long now as it will be on 23 October, and it is the same list whether or not the tooling arrives on time.