A Guide to Duo-assed Apps

September 25, 2026

A Duo-assed app stays itself while the phone changes shape around it. It carries what you were doing across the fold without losing any of it. It shows more on the inner display, not the same thing bigger. It works all the way on the cramped outer display. And it lets the system put its controls where the hardware wants them.

The name is borrowed. “Mac-assed Mac app” was coined by Collin Donnell and Brent Simmons ran with it: an app built for the Mac on the Mac’s terms, not something transplanted with alien affordances. The more I’ve worked on it the more clear to me that iPhone Duo needs the same idea. And we kinda need to speed-run it. Every iPhone app runs on this device on October 23rd 😬.

So here I attempt a guide for making architecture and design decisions up front on the info we have. It covers what the device does to an app, the principles that follow, the patterns that implement them, and a checklist to review against. Of course a lot may change once they are in-hand and I’m out over my skis here…

This is the long version. The short one, with one app’s story, is The Duo-assed App.

What this is built on. iPhone Duo was announced September 9, 2026 and ships October 23 on iOS 27.1. The simulator arrived with Xcode 27.1 beta on September 18. Nobody outside Apple and a few press hands-on sessions has held one. So everything here comes from Apple’s published material (the Human Interface Guidelines, the overview, six tech talks, two group labs, and the September 23 forum Q&As), the first week of developer reports from the simulator, fifteen years of earlier form-factor transitions, and measurements from a probe app in the Duo simulator. Where I’m reasoning past what a source says, I say so. Expect it to be wrong in places, and expect a revision after the hardware ships.

1. The device, as an app sees it

Two displays, one hinge

1.42 is close to the square root of 2, so each half of the inner display has nearly the proportions of the outer display, as John Gruber pointed out. That’s why a folded split and a Split View half both feel like the outer display, twice.

Apple doesn’t publish point sizes. In the simulator the outer display is 466 × 678 pt, and the inner display’s framebuffer works out to 669 × 951 pt at 3x, rendered about 6.4% larger than the panel and scaled down, the way the Plus models do it (Blake Crosley predicted this from App Store Connect’s screenshot size). Closed, in portrait, a NavigationStack gets a 382 × 562 pt content area: the vertical bar on the trailing edge takes 84 pt, and the safe area insets are 82 top, 34 bottom, and 84 trailing. Know these numbers for design reviews. Then don’t lay out against them (P2).

Other facts that touch apps: Touch ID in the side button and no Face ID, no Action Button, Apple Pencil support later in 2026, and the idiom is still .phone. There is no direct way to ask whether you’re on a Duo. Apple, direct response: “There is no API to detect whether your app is running on iPhone Duo… all iPhone apps can be resized to any size. Starting with iOS 27, iPhone apps can be resized on iPad and on Mac via iPhone Mirroring.” iPad-only apps get no compatibility mode here, unlike on Vision Pro, and a Duo-only app isn’t something Apple supports (Group Labs Q&A). On the web, WebKit’s Viewport Segments and Device Posture APIs are experimental in iOS 27.1, behind a feature flag in Safari.

Poses

Apple’s word is pose, and there are five: closed, open (flat), book (partly folded, hinge vertical), laptop (partly folded, hinge horizontal, sitting on a table facing you), and tent (standing on its edges). The hinge API reports closed, partially open, or fully open, plus an angle. In the simulator, laptop pose is the partly folded pose rotated a quarter turn: the inner display becomes 669 × 951 pt portrait, still regular in both directions, with horizontal bars and the fold running across it.

What happens on its own (if you have been keeping up)

• Controls move to the side. On the outer display, and on the inner display in landscape, the navigation bar, toolbar, tab bar, status bar, and Dynamic Island stack vertically along one edge, lined up with the hardware (the same side in right-to-left languages). Apple: “The only pose where we’ve kept horizontal bars is on the inner display in portrait.” What’s left on the outer display is about the shape of a normal iPhone.

• Reserved regions. Two kinds: occlusions (cameras, the Dynamic Island) and divisions (the fold, which is active only when partly folded). Measured in the simulator, the fold is a 40 pt band down the middle of the inner display: a zero-width line plus 20 pt margins on each side, x 455.5 to 495.5 in landscape. By default reservedRegions returns only active regions, so the flat fold and the idle under-display camera (58 × 37 pt) show up only if you pass .includeInactive.

• System components dodge them. Alerts, menus, sheets, and toolbar buttons move off the fold, and split views go to an even 50/50. Sheets are centered when the phone is flat and move to the leading edge when it’s partly folded. There’s no trait or notification for a region appearing. You read regions during layout and use the hinge status as the cue.

• Split View, fixed at 50/50, inner display in landscape only. Each app’s controls go to its own outer edge, so the app on the left gets a bar on the left. “All apps participate in multitasking on iPhone Duo.”

• Pinned Picture in Picture. Video pins to the top and the app underneath resizes to what’s left, live.

• Multiple instances. “iPhone Duo is the first iPhone to support multiple instances of your app’s UI. If your app supports this on iPad, it will on iPhone Duo as well.” (Leverage multiple displays and scenes)

• Closing and opening are a resize, not a relaunch. From the September 17 group lab: “It’s not like your app is getting created on one display and then torn down… you’re getting resized.” A full-screen app sees no scene phase change at all. With two apps in Split View, closing moves the one you were using to the outer display and backgrounds the other, and reopening soon brings both back. Apple’s written lab answers say text input and scroll position “typically persist automatically since the app’s process keeps running.” That’s true only for state your view tree keeps. An app that swaps its root on size class still loses it (P1).

What you get for doing nothing

Once you link against iOS 27 there’s no opting out of resizing. A developer with a small utility asked on the forums whether it could stay half-width and leave room for another app. Apple: “No you cannot. The expectation going forward is that all apps, including iPhone-only ones, will be fully adaptive and adjust to any available scene size at runtime.” UIRequiresFullScreen is still honored for Split View, “but your app will still resize when someone opens or closes,” and in the simulator it also puts the app in the scaled box above. UIRequiresFullScreen~ipad keeps the iPad behavior and leaves the Duo edge to edge.

Louie Mantia made the point that matters most: Vision Pro was opt-in. This isn’t.

2. Why this needs its own standard

Apple treats it as a new layout, and so does everyone who has seen it. Gruber, after the hands-on: “In some ways iOS on the Duo feels more different from iOS on all other post-iPhone-X phones than iOS on the original iPad felt from iOS on the iPhones of that time.” Steve Troughton-Smith on announcement day: “This is like a whole new platform dropping with a month’s lead time.” Apple’s design talk make the point plainly: “You don’t want just a stretched out iPhone app.”

The Duo was the worst kept secret in awhile, and of course the groundwork has been going in for years. Size classes replaced idiom and orientation checks at WWDC 2014, three months before the iPhone 6 Plus. iOS 26 brought iPad windowing and Liquid Glass, and iOS 27.0 made iPhone apps resizable under iPhone Mirroring. Liquid Glass pushed toolbars toward icon-only buttons, which Nathan Manceaux-Panot noticed is what makes a vertical toolbar possible at all. Apple’s overview says it plainly: “If your app already works on iPad and Mac or you’ve prepared your app to resize in iPhone Mirroring, you’re well on your way.” Adam Bell of Apple, replying to Casey Liss: “Duo support feels like a natural extension of the work you need to do to support iPadOS resizability. Custom controls need more work.” Apple had its own bills to pay. Maps and Find My moved off custom bars to system navigation in this release “just to get the vertical bar behavior” (Troughton-Smith).

Maye there is something to learn from Android? Seven years of Android foldables filled inner displays with stretched or letterboxed phone apps. Instagram was letterboxed on the Galaxy Fold until late 2023. Google went from case studies, to Play Store ranking (2022), to Android 16 ignoring apps’ orientation and aspect-ratio locks on large screens (2025), to Android 17 removing the opt-out (2026). It even changed the hardware: the first Pixel Fold’s wide inner display was dropped in the next model, partly because portrait-locked apps sat in the middle of it between black bars. Gruber’s verdict: “no developers truly adapted software to take advantage of the double-area inner displays.” And the first bug every Android source reports is the same one. State lost on fold.

Apple has been on the other side of this argument. Tim Cook in 2012, showing Twitter on a Samsung tablet: it “looks like a blown-up smartphone app, because that’s exactly what it is.” A stretched app on the Duo’s inner display is the same slide.

History says the first versions will be wrong in ways the simulator can’t show. That’s principle ten (P10).

3. The principles

Ten of them, each reduced to something you can test.

P1. The fold happens mid-task

Apple’s design talk: “People may open and close the device frequently.” The HIG: “Keep functionality and the state of elements the same between displays.” Closing the phone halfway through a reply and opening it again on the couch is ordinary use, so nothing gets lost across it: the navigation path, the selection, the scroll position, the text being typed and the keyboard, where the video was, a half-filled form, an open sheet. Google’s checklist for the same event lists the same things, and Google’s Pixel Fold guide spells out the cost: “If your app loses state, the user loses all previous form entry data and is forced to start all over.”

The hierarchy can’t change shape across the fold either. The outer display shows one level (Mail’s list, or a message), the inner shows two, and they’re the same hierarchy at two widths. An app that’s a tab bar app closed and something else open strands people every time they fold it.

Apple’s engineers named the usual cause in the September 17 lab: a SwiftUI view that swaps containers in an if on size class “will see state loss” on fold, because the two branches are different views with different identity. Their advice for a multi-step flow is the general rule: “model the navigation path independently from how the flow is presented across the two displays.” For state that has to outlive a scene, not just a fold, stateRestorationActivity(for:) is still the tool.

My blog post walks through one app that did exactly this.

P2. Lay out from the space you’re given

Size classes, scene and container geometry, layout margins, safe areas. Never userInterfaceIdiom, never UIInterfaceOrientation, never screen bounds, never a device model check. UIScreen.main “is ambiguous and will be deprecated” (Prepare your app for iPhone Duo). Apple: “Avoid fixed widths, breakpoints, or any metrics tied to a specific screen.” Google learned the same thing (”Window size classes are not intended for isTablet-type logic”), and Microsoft’s Surface Duo guidance said it first: “you should avoid designing to the specifications of any specific devices available today.”

An app on a Duo shows up at a lot of sizes: outer portrait, outer landscape, inner landscape, inner portrait, half of Split View, any of those shortened by pinned video or the keyboard, and each of those partly folded. Two width classes cover it: compact for the outer display, regular for the inner. Safe areas are lopsided here because the bar is on one side, and in Split View it may be on the left. Apple calls out view.safeAreaInsets.left * 2 by name as the bug to go find.

Use the most local geometry you have. UIScreen.main.bounds keeps reporting the outer display after the phone opens, and when a developer asked whether to read the scene’s screen instead, Apple went one step further: “use the most local layout information you can,” meaning a view’s own size over its window’s. On the outer display, the edge the bar sits on (toolbarVerticalEdge, or verticalBarEdge in UIKit) is a better signal for a landscape layout than size class or orientation. And expect traits to change a lot. Craig Hockenberry: “In the past, you may have gotten away with accessing the traits in viewDidLoad/viewWillAppear… Especially if your app was portrait-only.” Trait reads belong in viewIsAppearing and trait-change handlers.

P3. The inner display shows more, not bigger

The HIG: “Maintain your app’s information hierarchy, but show an additional level of hierarchy on the larger inner display if it makes sense for your content.” Apple offers three shapes: a split view (Mail, Notes), a stacked layout that becomes two columns (Music), or a sidebar for information-dense apps (Health). The sidebar is something you ask for. On every iPhone, the Duo included, a UITabBarController stays a tab bar at regular width unless the app sets sidebar.preferredPlacement = .sidebar. Google’s version of the rule: the unfolded layout should be a superset of the folded one.

It isn’t an iPad, either. Federico Viticci: “The iPhone Duo does not run iPadOS and it is not an iPad when you open it.” Apple’s Phone team made the dialer its own tab, where the iPad uses a popover, because “this is a phone.” James Thomson found PCalc running its iPad configuration on the inner display and wasn’t sure that was right. And text has a comfortable line length. Marco Arment’s first fix to Instapaper after holding a real iPad was much thicker margins, because the screen was “actually too large for comfortable text reading spanning the entire width.”

P4. The outer display is a small phone

And might be the most that is used most?? No idea how natural popping that phone open a hundred times a day will be. The outer display is wider and shorter than any iPhone, and in landscape it’s compact in both directions. The keyboard eats a lot of it (Hockenberry: “Pulling up a keyboard on a closed Duo is likely to be a surprise”). Casey Liss, first look at Callsheet in the simulator: “Opened: looking good! Closed: Dear God no.” Android agrees. Samsung’s first warnings to Galaxy Fold developers included its narrow cover display, and reviewers complained about how little of it the keyboard left.

Every flow has to finish closed. The closed layout deserves the same design attention as the open one, since it’s the one people use standing in line.

P5. Let the bars go where the hardware wants them

The side bar is, in the HIG’s words, “one of the core patterns of iPhone Duo.” You get it only from bars that system containers own (NavigationStack, NavigationSplitView, TabView, UINavigationController, UITabBarController). A standalone UIToolbar, UINavigationBar, or UITabBar, or a bar you drew yourself, never goes vertical. Then (Raise the bar with iPhone Duo):

• Give every item a symbol and a title. Vertical uses the symbol, overflow uses both, a title-only item stays in a horizontal bar, and a custom view doesn’t go vertical unless you say it can.

• Order: Back or Close at the top, then the prominent action (Done), then groups in their original order. Use semantic placements and item groups, not spacers.

• Set visibility priority so the right things overflow last: the frequent action (Compose, New Note) and anything showing status (badges). Overflow happens most in outer landscape, with the keyboard up, and with pinned video.

• Decide per screen whether the toolbar or the tab bar gives way first. Navigation screens keep the tabs, task screens keep the tools (toolbarVerticalCompressionBehavior(.prefersToolbarItems), or verticalBarCompressionBehavior = .prefersBarItems in UIKit).

• Fold any custom overflow menu into the system one. Check what overflow does to a button with a primary action and a long-press menu. Greg Pierce found that in overflow “the primary action disappears, and you just get the menu as a submenu.”

• Keep controls next to what they act on. Mail’s list controls stay above the list, not in the side bar.

• Opt out rarely, and as a fixed choice rather than something that flips with view state: a single-screen, bottom-heavy app (Calculator), or a sheet with one button (toolbarVerticalBehavior(.disabled), or preferredVerticalBarBehavior in UIKit). Varying it by size class is allowed when the two layouts really are different. Safari turns the vertical bar off at regular width because its tabs need the room. Apple: “You should really only reach for disabling the vertical bar if your use case is similar enough.” PCalc took the calculator exemption after three days of working around the bar.

• A custom bar that has to sit beside the system’s reads the edge from toolbarVerticalEdge (it can be leading or trailing) and gets its place from safeAreaBar in SwiftUI or layoutGuide(for: .bar(onEdge:extent:)) in UIKit. A custom tab bar also owes people what the system’s does: labels on long press, and the Large Content Viewer at accessibility text sizes.

P6. Respect the fold

When the phone is partly folded, the middle of the inner display is a curve. Keep taps and text out of it. System components already do. For your own layout, prefer containers that adapt (split views, arrangement views), use an even number of grid columns, keep the outer margins and widen the gap at the hinge, and query reserved regions for the rest. Scrolling content doesn’t dodge the fold (“articles, feeds, documents, and lists don’t displace,” from Strike a pose). Fixed controls and labels do. Microsoft found the same exception for maps: people drag the map off the seam themselves.

Move as little as you can. The HIG: “Avoid extreme layout changes as people fold the device… favor small adjustments over rearrangement.” Move related things together (a selected photo and its menu), and treat an occlusion as temporary when it is. FaceTime’s self-view dodges the inner camera only while the camera is on. The Google Duo team put it concretely in 2021: they took every small button out of the middle of the screen so nobody had to press into a crease.

P7. Poses are “yes, and” not gates

Apple: “You don’t want to tie functionality to a specific pose,” and from the group lab, “don’t feel stressed about having to sizzle up every single pose… in 90% of the cases, [your layout] does not need to do anything special.” The HIG: “Maintain the same functionality across device poses.” Like how many apps really need a tent pose behavior? We can’t even get people to embrace standby widgets.

One pose layout has a real track record: laptop pose, look at the top half, touch the bottom half. Video or the call goes up, the controls go down to the half resting on the table. Apple’s TV app does it, and Google Duo, Zoom, and YouTube did on Android. ArrangementView gives it to any two-part layout. Apple also suggests supporting landscape so tent pose works.

Greg Pierce’s skepticism belongs here: “90% of the work to adapt your average app to the iPhone Duo will be to support partially folded modes that the ~1% of iPhone users who have the Duo will actually use <5% of the time.” Spend accordingly. Make the partial folds correct (nothing in the crease, nothing lost), and make them special only if the app is video, calls, camera, or reading.

The first public worked example shows both sides of it. James Thomson posted PCalc’s Duo work day by day. On day 2 he used UIHingeInteraction to learn the phone was folding and the reserved region API to find the hinge, then moved the buttons off it. On day 3, laptop pose put every button on the lower half. By day 5 the keypad split around the hinge as the phone started to fold and switched to the laptop layout past a threshold (“Is this too cute?”). Hockenberry’s reply is this principle in a sentence: “It could be confusing to have different layouts: you probably won’t be watching the animation & state changes when you open a physical device. ‘Why does the divide button move around?’” Thomson agreed he’d need the hardware to know. That’s the right posture until October 23rd. Build the correct version, prototype the special one, and decide with the device in your hand.

P8. You’re sharing the screen

Split View, pinned video, and multiple windows are things people do to your app, not features you choose. The app will run at half width with its bar on the left. It will get shortened by a video while someone types. If it supports multiple windows on iPad, it gets them here too (Troughton-Smith: “You better have your multi-window multi-instance state-syncing ducks in a row”). New windows can only be created on the inner display, so use UIWindowSceneActivationAction, which hides itself when windows aren’t available, and handle a refused scene request.

Apple is exact about it: “All apps participate in iPhone Duo’s multitasking, in that you cannot prevent multitasking with any sort of API in your app.” That doesn’t oblige you to support multiple scenes. But if you do, each window gets its own SceneDelegate, so anything you do in scene callbacks (security checks, session setup) runs once per window, and once-per-process work belongs on the app lifecycle notifications. UserDefaults and @AppStorage are app-wide, so two windows share them.

P9. A camera faces a direction, not a position

Open the phone and the outer front camera now points away from you. Flip it around and the rear cameras face you. An app that captures has to choose cameras by the direction they face relative to its view, and expect the active camera, the mirroring, and the rotation to change when the phone opens, closes, or flips (Choosing a camera by the direction it faces). The default virtual front camera switches between inner and outer on its own and is the right choice for most apps.

With a capture session running and the app full screen on the inner display, a camera capture accessory can put UI on the outer display (a preview for the person being filmed, a teleprompter). The system can take it away at any time, so treat it as a bonus. It’s the only way to use both displays at once. An ARKit session counts as a capture session for it, and AlarmKit apps get the outer display through the same system-run mechanism.

Details from Apple’s camera Q&A that change code. The virtual front camera drops frames when it switches between outer and inner, with no dropped-frame reason and no interruption notification, just a gap in the sample buffer timestamps, so Vision and Core ML pipelines have to tolerate a jump. The inner camera tops out at 60 fps. A portrait-only camera UI no longer stays put on the inner display, and Apple’s answer to a request for a fixed-orientation key was AVCaptureDevice.RotationCoordinator, which handles the preview and leaves the interface to you. Android’s record says camera preview is the classic bug that only shows up on hardware, and the Duo simulator has no cameras at all.

P10. Hold the hardware, and plan the second release

Every transition has had the same shape. Design blind, ship, hold the device, fix what the simulator couldn’t show. This is an expense you can’t avoid if you really want to nail it 😭.

• iPad, 2010. Marco Arment recompiled Instapaper for the iPad the night it was announced (”everything except the reading screen looks ridiculous”), made a cardboard iPad, and shipped a careful version on day one because the pixel-doubled fallback “sucked.” Three weeks after getting hardware he shipped 2.2.3: controls moved to the top, much thicker margins, a brightness control, and new tap zones because the iPad is “usually held two-handed by its sides.” At Omni, the team 3D-printed a “fauxPad” and ran paper prototypes on it.

• Apple Watch, 2015. Arment again. A scaled-down iPhone structure “seemed like a sensible adaptation… In practice, it sucked.” “After using my initial app on a real Apple Watch for just one day, I set out to completely rethink and restructure it.”

• iPhone X, 2017. Halide was designed without one, using a physical mockup and an iPhone 8 Plus as a stand-in, and still needed an ergonomics update afterward. Sebastiaan de With: “There’s nothing like having the actual hardware.”

• Vision Pro, 2023. David Smith: “Some concepts work in the simulator but don’t really translate to the device.”

• Duo, day one of the simulator. Troughton-Smith: “you don’t have to spend long with the iPhone Duo Simulator to realize you damn well better have one of these devices on hand for testing your apps.”

• Duo, week one. Hockenberry, looking at a keyboard layout with controls in the crease: “Some layout decisions will only be possible once a device is in hand… Don’t tell me which one you prefer unless you have a Duo in hand.”

What the simulator can’t show: how each pose is held and where thumbs reach on something 6.5 inches wide, what the crease does to what’s under it, how often people really fold mid-task, the timing of a fold, anything involving a camera, both displays lit at once, StandBy, and most app extensions.

The rule that falls out of all that: ship a careful, system-component build on day one, and put a second release on the calendar for two to four weeks after you have hardware. Careful doesn’t mean skipping it. In every one of these transitions, the compatibility mode was worse than a modest native version.

4. Architecture decisions

These are my conclusions from the principles, not something Apple or anyone else says in so many words, yet. Most of them are analogous to decisions a Mac-assed Mac app makes, coming from from a different direction. Both are about an app surviving a container it doesn’t control.

A. State lives above the layout. Navigation path, selection, scroll anchors, drafts, and playback position live in a model that outlives any particular arrangement of views, one per scene. The compact and regular layouts are two renderings of the same state. If a fold can destroy it, it was stored in the wrong place.

B. One adaptive container, not two view trees. Use NavigationSplitView, TabView with sidebar adaptability, and ArrangementView, which collapse and expand without losing identity. Don’t write if horizontalSizeClass == .compact { PhoneRoot() } else { PadRoot() } at the root. It’s the documented cause of state loss on fold. Where a branch can’t be avoided, push it as far down the tree as it will go and keep the state outside it.

C. No device knowledge anywhere. No idiom checks, no orientation checks, no UIScreen.main, no hard-coded point sizes, no “is this a Duo” flag (there isn’t one). Get the screen from the window scene and the scale from the trait collection. Grep for all of this before anything else. Greg Pierce’s first Duo task was deleting userInterfaceIdiom == .pad checks.

D. System containers own the bars. That’s the price of P5. Look for standalone UIToolbar, UINavigationBar, and UITabBar, hand-built bars, and child navigation controllers (there’s an open bug, FB24840142, where those wrongly get vertical bars). Apple has also acknowledged that with the bar on the leading edge, bar layout guides inside a UINavigationController land 84 pt off (FB24906205), so test custom bar content with the bar on both sides. Troughton-Smith’s Take One “mostly works” except that its embedded UIToolbar doesn’t adapt. Every toolbar item gets a symbol, a title, a group, and a priority where it’s defined.

E. State per scene, one shared model. No global “current item.” Two copies of the app side by side each keep their own navigation and selection while sharing one store, and a change in one shows up in the other.

F. Two-part screens are arrangements. Wherever a screen is a primary and a secondary view (player and lyrics, video and controls, map and details, document and inspector), make it an ArrangementView (split for side by side, overlay for foreground over background) and keep navigation outside it. Apple’s teams: “Almost every single app has an ArrangementView.” Don’t put one inside a List, ScrollView, or split view: “Place navigation containers around arrangement views rather than within them.” For a sidebar or any hierarchy, use NavigationSplitView.

Plan for the collapse. When the split can’t fit (compact width, or a shape or pose that doesn’t suit its axes), an arrangement shows only one view: the one with the higher .layoutPriority, or else the primary. splitArrangementAxis in the environment tells you when that’s happened. Anything essential in the secondary view (a video editor’s controls) needs another way in when it’s hidden. Apple didn’t answer that one in the Q&A, so it’s a design decision per screen.

The exception is a canvas meant to run under everything: a map, a photo, a game. A split gives each side its own rectangle, which is the wrong shape for that. One ZStack with a floating card, whose position follows the width and the division region, keeps the single view tree without taking an edge away from the canvas. If you do this, tell the canvas what the card covers, or whatever it’s centered on ends up underneath it.

G. Reserved regions are a layout input for custom views. Anything edge to edge or laid out by hand (canvases, games, custom grids, custom bars, floating cards) queries reservedRegions for divisions and occlusions and treats them like safe areas that come and go. Prefer even column counts wherever there’s a division, even an inactive one. There’s no trait or notification for a region becoming active. Read regions in the layout pass (layoutSubviews, a GeometryReader, or UIKit’s automatic observation tracking) and treat a hinge status change as the cue to look again (Apple’s answer).

H. Hinge data drives effects, never layout. onHingeChange(isEnabled:_:) and UIHingeInteraction give a live angle and a status for interactions (Apple’s demo is a whammy bar). The two frameworks differ. SwiftUI’s closure gets the old and new DeviceHingeContext, with an angle of type Angle and a status with three values (closed, partiallyOpen, fullyOpen). UIKit’s UIHinge has the angle in radians as a CGFloat and a fourth status, unknown. Both fire once at launch. The update rate and precision are, in Apple’s words, system policy that “can change based on system state,” so prefer the status when that’s enough. Layout comes from size classes, arrangements, and regions. An app that reads the angle to pick a layout has rebuilt the device check C rules out.

I. Cameras go through the direction coordinator. Use the virtual front camera unless you need the individual ones. If you do, use an AVCaptureDeviceDirectionCoordinator per view, a fresh rotation coordinator on each switch, mirroring set on purpose, and a masked preview during the switch. The same code works on single-display iPhones, so it costs nothing to adopt everywhere.

J. Resizing is cheap and continuous. Opening, closing, Split View, and pinned video resize the app live. A layout pass must not reload data, re-run queries, restart players, or re-create web views. Samsung’s 2019 list of first-generation Fold bugs was all this kind of thing, down to apps that quit because they called finish() on teardown.

K. Both layouts are test targets. Put the core flows under UI test at compact and regular width, with a fold in the middle of each flow and a check that state survived. Until you have hardware, iPhone Mirroring’s resizable window and your iPad build are two more places to watch an iPhone layout resize. xcrun devicectl device appResize resizes a running app from the command line, which suits automated layout checks, but XCUITest reports stale, shrunken element frames after a live resize, and there’s still no supported way to set the pose from the command line or a test.

5. Design process, so far…

1. Classify the screens, not the app: single column, list and detail, two-part, canvas or immersive, capture. Each kind has a known answer (P3, F, G, I).

2. Write the hierarchy once. For each level, say what shows compact and what shows regular. If the two lists aren’t the same hierarchy at two widths, fix the hierarchy before drawing anything.

3. Inventory the bars. Every toolbar and tab item: symbol, title, group, placement, priority, and which gives way first on each screen.

4. Draw the outer display first, including landscape and with the keyboard up. It’s the tighter constraint and the one people use more.

5. Draw the inner display as an expansion of that: split, two columns, or sidebar. Check it at half width for Split View, and with the bar on the left.

6. Walk the folds. For each core flow, fold and unfold in the middle of it on paper. What’s on screen after, where’s the cursor, what moved? Then mark what sits on the crease in book and laptop pose.

7. Decide the pose extras, if any. Video, calls, camera, and reading apps usually have one. Most apps have none, and that’s fine.

8. Build with system components, run the section 6 checklist in the simulator, and ship the careful version.

9. Hold the hardware. Make a physical mockup first if grip matters to the design (open, it’s 6.48” × 4.64”; closed, 3.31” wide). Book the second release now.

The question to keep asking: if someone folds the phone right here, what happens to what they were doing?

6. Review rubric and checklist

Score each category 0 to 3. (The rubric is mine, modeled on the Mac-assed one.)

Mark camera N/A if the app doesn’t capture, and score as a percentage. Under 34% is a stretched iPhone app. 34 to 66% is resizable but generic. 67 to 86% is solid. 87% and up is Duo-assed.

The “what if I fold it right now” checklist

• Type half a message closed, open the phone, keep typing. Same cursor, same keyboard, same text. Then the other way.

• Scroll deep into a list, open a detail, fold, unfold. Same item, same scroll position, and Back goes where it should.

• Open a sheet, a menu, and an alert, and fold with each one up. The sheet should move to the leading edge in book pose and back to center when flat.

• Start playback and fold. It doesn’t restart.

• Every flow finishes on the outer display in portrait and landscape with the keyboard up.

• Rotate in every pose. The inner display ignores your orientation lock, so look at what it does to a portrait-only app.

• Split View on both sides. On the left, the bar is on the left and nothing assumes otherwise.

• Pin a video and type in the app underneath it.

• If the app supports multiple windows on iPad, open two here, change something in one, and check the other. Try opening a window while closed.

• Book and laptop pose on every screen: nothing tappable or readable on the crease except scrolling content.

• Toolbars: every item has a symbol and a title, Back or Close is at the top, the frequent action overflows last, there’s only one ellipsis, and a button with a menu still does its main action from overflow. Tab titles aren’t left truncated after unfolding (a known bug, so note it rather than work around it).

• VoiceOver through the vertical bar and its overflow menu. The largest Dynamic Type on the outer display. Reduce Transparency with the vertical bar.

• Camera apps, on hardware only: open, close, and flip during preview and during recording.

• Build with the 27.1 SDK and look for a black strip or a box. If you see one, you’re in a compatibility mode.

Anti-patterns

A stretched phone layout on the inner display. An iPad layout dropped in without a second look. A different app closed than open. State lost on fold. Branching on size class at the root. Idiom, orientation, or screen-size checks. Hand-drawn bars. Text-only toolbar items. A private overflow menu next to the system one. Controls on the crease. Features that exist in only one pose. Reading the hinge angle to pick a layout. Choosing a camera by position. Assuming the bar is on the right.

7. What breaks in existing apps

What I’ve seen running ordinary iPhone apps (SwiftUI, iPhone-only, mostly portrait-locked) in the Duo simulator, before any intentional changes. None crashed (yay!). Most of what went wrong was layout of course. And then there was one more thing…

• Portrait lock doesn’t box an app. UIRequiresFullScreen does. A portrait-locked app built with the 27.1 SDK gets the inner display edge to edge in landscape, 951 × 669 pt, regular in both directions. So every quiet “portrait phone” assumption (fixed heights, full-width hero images, controls pinned to the bottom, buttons that span the screen) gets shown wide and short. A full-width Get Started button came out about 870 pt wide. An app with UIRequiresFullScreen got boxed and scaled instead. UIRequiresFullScreen~ipad keeps the iPad opt-out and leaves the Duo edge to edge. And the lock is gone for good: Apple’s answer to “is there a sanctioned way to lock the inner display to portrait” was “No.”

• Centered things land on the fold. A centered title, a centered button, or a centered block of copy straddles the crease in book pose. A floating card in a trailing column (up to about 400 pt wide beside the vertical bar) put its leading edge inside the fold region, with its text only a few points clear.

• The outer display is narrower than people design for. A 382 pt content column truncated an onboarding title that fit on every other iPhone.

• The bars mostly just work. NavigationStack, TabView, and .toolbar went vertical with no code changes, and a TabView stayed a tab bar on the inner display. The Previews canvas doesn’t draw the vertical bars (Hockenberry), so check bars in the simulator.

• Canvases run under the bars, and so do their labels. A full-bleed map is right, but place labels drawn over it ended up under the side bar’s buttons. Keep labels and callouts inside the safe area on every edge, not just the top, since the bar is on the side.

• The ‘one more thing’ and the worst surprise was state. An app with an iPad layout chose between its phone and iPad roots on size class. That had been safe, because a phone never reached the regular branch. On a Duo it does, every time the phone opens. Someone deep in a 3D map on the outer display opened the phone and landed on the app’s front page, in the same running process, no crash. Closing it again didn’t bring the map back either. The map view on its own survived every pose change with its camera intact. The swap at the root is what threw the place away. The full story, with screenshots, is in the blog post.

• Idiom checks pick the wrong thing. A sheet that chose a form sheet over detents by checking userInterfaceIdiom == .pad gave the Duo’s wide inner display phone detents, since a Duo says it’s a phone. Decide from the size of the presenting container, measured outside the sheet (a sheet’s own size class reads compact).

Getting set up

• The Duo simulator needs Xcode 27.1 beta and macOS 26.6 or later. The iOS 27.1 simulator runtime is a separate download of about 8 GB (xcodebuild -downloadPlatform iOS). Apps with Metal shaders also need xcodebuild -downloadComponent MetalToolchain. (yay, secrecy making everyones lives harder)

• Xcode 27 has no Simulator.app. Devices open in Device Hub, where the Duo’s pose is set by the closed, open, and partly folded buttons in the device window’s toolbar, plus a slider for any hinge position. Holding Option over the pose buttons drives the fold by hand (Aaron Vegh). simctl has no pose command.

• Don’t power the Duo’s screens on and off with simctl io screenConfig power. Turning off the outer screen put SpringBoard into a crash loop until the simulator was rebooted.

• Build with normal simulator signing. Without it no entitlements get embedded, and apps that use CloudKit or App Groups crash at launch.

• The first boot reports “Data Migration Failed” and PosterBoard crashes once; the device works anyway. Using 27.1’s Device Hub while building with 27.0 makes PosterBoard throw constantly; clearing DerivedData and erasing the simulator fixes it (Hockenberry).

• Builds from the 27.1 beta go through TestFlight, as long as they’re archived on a Mac running release macOS. App Store Connect won’t take Duo screenshots until “later this year.”

• Xcode 27.1 adds a Display group to the Previews canvas for previewing a view on the other display. It’s a cheap check to put next to each root view’s previews. Most app extensions can’t run in the Duo simulator, so widgets still need hardware.

8. The honest tradeoffs

It’s a $1,999 phone and a small share of users. Dennis Oberhoff’s point stands: the Duo creates no new market for developers. Greg Pierce: “don’t do it for Apple… Don’t do it for sales.” The case for doing the work anyway is what the work is. Resizing, state that survives a layout change, system bars, and state per scene pay off on iPad, in iPhone Mirroring, on the Mac, and on whatever Apple ships next. Matt Birchler’s Nonogame needed zero code changes because that work was already done. Casey Liss, five days into the simulator: “Don’t keep punting on being a good platform citizen.” The bill that came due for him was running more than one copy of the app at once.

It isn’t optional the way Vision Pro was. Every iPhone app runs on it, boxed or not, and press coverage of the compatibility modes means the floor is visible to users and reviewers. Hockenberry’s guess about unadapted apps: “I’m going to assume it looks like shit.”

Older codebases pay the most. Troughton-Smith’s Pastel has a full iPad app and still needs “a lot more work” because of custom layout containers. Hand-built bars, custom containers, and one-screen-at-a-time assumptions carry the most cost. For those apps, building with the 27.0 SDK buys time at the price of a black strip.

Apple’s design has real critics. Hockenberry points out that Close, Done, and Cancel change sides depending on which half of Split View the app is in. Nico Reese finds the toolbar order confusing between modes. The controls are always on the right, with no left-handed setting. Gruber calls the outer display “no better than a tolerable compromise.” Still, the HIG’s advice not to override bar placement is right for now. A consistent pattern with flaws beats every app inventing its own.

The tools arrived late, and rough. The videos shipped September 9, the simulator September 18, and the device ships October 23. The simulator has no cameras and no StandBy, can’t light both displays, and can’t run most extensions. The first Q&A turned up acknowledged bugs in bar layout guides and tab titles, and Pierce gave up four days in: “I’m done trying with the Duo until another simulator comes out.” That’s one more reason to build the day-one version from system components. They’re the parts Apple will fix for you.

This is a simulator document. Every transition in P10 embarrassed the confident early advice. The principles that rest on Android’s seven years and on Apple’s stated behavior (P1, P2, P5, and P6) should hold. The ones about what people will do with poses and how they’ll want to use the inner display (P3, P4, and P7) are the likeliest to change.

9. Still unknown?

• Whether reservedRegions includes inactive regions by default. Apple’s reference page says it returns regions “regardless of whether they are currently active.” The simulator returns only active ones unless you pass .includeInactive. Code to what the simulator does, pass the option when you want the flat fold, and check again on hardware.

• Whether the camera capture accessory needs an entitlement. A group lab panelist said yes. None of the documentation mentions one, and neither Q&A answered it.

• Whether the accessory scene rotates in laptop pose. The simulator always lays it out in portrait. Apple asked for a Feedback rather than say what hardware does.

• How long Split View survives a close. Apple: “We’re not sharing the exact timing.”

• The hinge angle’s range on hardware, and the SwiftUI margins modifier mentioned in the labs without a name.

• Occlusion frames for boxed apps in laptop pose. A UIRequiresFullScreen app got its occlusion rectangles rotated 180° from where they are on screen (the sensor housing reported bottom-left while it sits top-right), though its safe area was right. Seen once in the simulator.

• What to do when an ArrangementView hides controls that matter. Asked in the Q&A, and not answered by Apple.

• Everything in P10’s list of what the simulator can’t show.

Written September 2026, before iPhone Duo ships. API names are checked against Apple’s documentation and the iOS 27.1 SDK. The measurements are from the Xcode 27.1 beta simulator. Last updated Sept 25 2026 at 4pm mountain time