Designing for iPhone Duo: What Moves, Splits, and Stays

What does designing for iPhone Duo require? Two layouts, not a layout per pose: “A compact width layout for the outer display and a regular width layout for the inner display give you the fundamentals for every pose,” and Apple’s own advice is to “design your app to be freely resizable.” (4:32) On top of that base sit four patterns the guide and its three companion Tech Talks describe: controls move to the side of the display and keep a top-to-bottom order; content offsets from those controls unless it is deliberately full-bleed; interactive elements displace away from the fold while scrolling content does not; and a new container, the arrangement, splits or overlays two views by rules. The talks describe the APIs behind the last two, and arrangements arrive with iOS 27.1.

Apple published Designing for iPhone Duo in the Human Interface Guidelines the afternoon of the keynote, alongside three design-facing Tech Talks: “Design for iPhone Duo,” “Strike a pose with adaptive layouts on iPhone Duo,” and “Raise the bar with iPhone Duo.” The developer post on this site works the points arithmetic and the SDK rules. This one is about the design decisions the guide asks for, quoted from Apple’s own words with the timestamp in each talk, and what I plan to do about them in my own apps.

TL;DR: Design for two size classes and let the system pose the app. Bars go vertical on the side of the outer display and on the inner display in landscape; the inner display in portrait keeps horizontal bars. Icon items go vertical, text-only items stay horizontal, and the top of the vertical bar is for Back or Close, then a prominent action like Done. Content offsets from the bar through the horizontal safe area unless it is immersive and does not scroll. At the fold, “elements like alerts move to the trailing side” (4:09) in the book pose and interactive controls move to the bottom half on a table, while “continuous scrolling content like articles, feeds, documents, and lists don’t displace.” (3:46) Arrangements are the new layout container, split or overlay, and Apple’s rule for choosing is the one you already use: a horizontal or vertical stack becomes a split, a ZStack becomes an overlay.

One rule before the patterns

Two of the talks and the guide repeat one sentence, and it is the sentence to design from. Vince, from Apple’s design team: “People will use iPhone Duo in many different poses, and you’ll want your app to look great across all of them. But that doesn’t mean designing a custom layout for each pose. Instead, focus on two size classes: compact width on the outer display and regular width on the inner display. Avoid fixed widths, breakpoints, or any metrics tied to a specific screen” (3:50). The guide says the same thing in its poses section. Vince adds one optional layout, for the device seated on a table like a laptop, where “media can sit at the top, while tappable controls live on a stable base at the bottom,” (4:48) provided it “has all the same controls and general hierarchy as other poses” (4:57).

Frame from Apple’s September 9, 2026 event stream, 11:05 a.m. PT: the standing pose. The guide’s list is “partially folded like a book, placed down on a surface, or standing on its edges.”

Everything below assumes that base, which is the same base the resizable-iPhone checklist audits and the iPad resizability post explains. If a layout is built from size classes, layout margins, and safe-area insets, Vince’s promise is that “your app should already adapt to iPhone Duo” (4:27).

The side: what moves there, what stays put

On the outer display, controls that lived at the top and bottom “move to the right side of the display in order to maximize vertical space and to make them easier to reach with your right thumb” (1:18). The side holds the tab bar, the toolbars, navigation controls like Back, the status bar, and the Dynamic Island, “which expands vertically as Live Activities arrive” (1:48). On the inner display the bars stay vertical in landscape and return to horizontal in portrait, “the only pose where we’ve kept horizontal bars,” (5:27) because “there’s plenty of vertical space for app content” (5:32). In Split View, “when an app is on the left side, the controls move to the left edge of the display too” (3:11). And the bar is aligned to the hardware, so “it stays on the same side of the device in right-to-left languages” (4:21).

Frame from Apple’s September 9, 2026 event stream, 10:59 a.m. PT: the device mid-fold with the inner display facing, and the side-mounted controls at its right edge.

Two things decide whether a given control goes vertical. The first is its container. Anna, from UI Frameworks: “make sure you’re using the bars provided by navigation containers like TabView or NavigationStack,” (2:19) because content from custom UIToolbar, UINavigationBar, or UITabBar instances “won’t be considered” (2:58). In split views “only the detail column participates,” (3:43) and inspectors “don’t receive their own” (3:53) bar. The second is the item’s content. Vertical bars have “flexible item height and have a fixed width,” (6:10) which “makes vertical bars better suited for symbol-only item representations” (6:13). So “items with an icon, like the back and share buttons, change their axis to be vertical. And text-only items, like the edit button, continue to stay on the horizontal axis” (7:06). Vince’s version is the designer’s: “Toolbar items that are too wide for the space on the right, like a text button or a segmented control, should stay put in the nav bar on iPhone Duo” (6:22).

The ordering rule is short. “Reserve the top for primary navigation controls, like back or close, followed by prominent actions, such as done” (4:47). In SwiftUI a custom Back or Close uses the cancellationAction placement (5:02) and a prominent action uses topBarPinnedTrailing (5:24); in UIKit, a leading item with leftItemSupplementsBackButton left at its default of false (5:06), and pinnedTrailingGroup for the prominent action (5:27). Everything else keeps its original grouping, with “a vertical spacer visually separating top and bottom placements” (5:34).

The bars talk’s rules for individual items, each with its cue:

• The test for a custom item: “is it simply reinforcing the symbol, or does it carry standalone information?” (9:36)
• A count belongs in a badge, which turns a text-and-symbol item into a symbol-only one that “feels at home in a vertical bar” (9:23); “a cart button displaying a dollar amount” stays horizontal (9:52).
• An item that switches between a symbol and text, like Edit, stays horizontal; the system Edit button already does, and a custom one takes the horizontal-only AxisBehavior (8:11, 8:32).
• A custom or complex view stays horizontal by default (8:40); if it “does support a vertical representation” (8:48), the vertical-preferred axis behavior lets it into the bar (8:54).
• Give every item a title even when it shows a symbol, because “the system uses it whenever an item moves into an overflow menu or an expanded form” (7:44).
• Keyboard accessory bars “should remain attached to keyboard rather than moving to the vertical axis” (10:00).
• Custom views read the toolbarVerticalEdge environment property, or trait in UIKit, to know whether a vertical bar is present (10:35).

Overflow is where design preferences get expressed, and the talk gives five rules:

• “By default, items overflow from bottom to top” (13:23); each item can carry a high, low, or custom visibility priority, assigned “by groups” (13:36) first, then within a group. The priority and overflow APIs are the WWDC26 toolbar additions covered in this site’s iOS 27 SwiftUI post; at 13:49 the talk sends you to Apple’s WWDC26 session on what’s new in SwiftUI.
• Decide what compresses first: in navigation-focused views “the toolbar compresses first, so primary destinations remain accessible” (12:07), the default; in task-oriented views “the tab bar compresses first to preserve frequently accessed actions” (12:18), set with toolbarCompressionBehavior (12:22).
• Fold an app’s own overflow menu into the system one, ToolbarOverflowMenu in SwiftUI or additionalOverflowItems in UIKit (12:36, 12:43), and keep the ellipsis for overflow alone (12:53).
• “Frequently used actions like Compose in Mail or New Note in Notes should be amongst the last to move into overflow” (13:59).
• Badged items “should remain visible for longer to preserve glanceability” (14:11).

Vertical bars are not mandatory. A single-page, bottom-heavy layout like Calculator, or a sheet with a single toolbar item such as Close, can turn the bar off with toolbarVerticalBehavior or preferredVerticalBarBehavior (14:28, 14:37, 14:47).

Centered, or offset

With the bar on one side, “a lot of layers are now asymmetrical” (6:33). Vince gives three positions. Most content takes an offset so it is not hidden behind the controls, and “if your app aligns to horizontal safe area insets, that offset happens automatically” (6:58). Some UI still centers on the full display with no offset, which “works well for immersive, highly visual interfaces that don’t scroll, as long as you’re sure interactive elements won’t be blocked by controls on the right” (7:10). And the two mix: “a full-width background image or header with scrollable foreground content that’s inset,” (7:22) so long as “every interactive element lives inside that scrollable area so nothing gets covered up” (7:28). The guide’s safe-area note adds the Split View case: the opposite edge can carry the other app’s controls, so the safe area matters on both edges.

The fold: displacement

Frame from Apple’s September 9, 2026 event stream, 11:08 a.m. PT: the display’s layers. Partially folded, the curve through the center is the “folding region” of the guide.

Maria, a Human Interface Designer on Apple’s design system, opens with the principle: “Great design for iPhone Duo hinges on knowing when to adapt” (2:25). Many interfaces “can flow naturally around reserved regions,” (2:30) and the rest use displacement, “which adjusts the frame of the existing elements based on the available space, keeping important content visible, reachable, and unobstructed even when the device is partially folded” (2:39). The pattern has a scope, “from a button to an entire container or larger parts of a layout,” (3:03) with two rules: “If an element can adapt independently, move it on its own. And when elements work together, move them together to preserve their relationship,” (3:17) and “be mindful of excessive movement,” (3:26) because “moving an element far away from its source weakens their visual relationship” (3:29). Her example is a context menu on a selected photo: rather than centering the menu in the trailing region, “both elements move together and align around the fold” (3:39).

The exception is the one designers will lean on most: “Continuous scrolling content like articles, feeds, documents, and lists don’t displace. These experiences already adapt through scrolling, so moving them between the available regions can interrupt continuity” (3:46). Vince says it from the other direction: the system nudges interactive elements out of the curve because “buttons are tough to tap when they land right in the fold,” (9:28) the behavior is built into “sheets, alerts, menus, toolbar buttons, and more,” (9:40) and “scrollable content doesn’t need to avoid this region” (9:57).

The fold’s orientation sets the regions: in the book pose it runs vertically and the regions are left and right; on a table, or in portrait, it runs horizontally and the regions are top and bottom. Where a displaced element goes depends on the pose, and Maria’s reasons are the useful part. In the book pose, “elements like alerts move to the trailing side. This keeps them closer to where they’ll appear as the device closes and the experience continues on the outer display” (4:09). Propped on a table, “the top region works well for content that benefits from visibility at a distance,” (4:29) and “the bottom region works well for interactive controls,” (4:39) where “tappable elements like media controls can move here, providing a more stable surface for touch” (4:43). The talk on principles agrees: in portrait, partially folded, “interactive elements move to the bottom half of the display, making them easier to reach while keeping the device stable on the surface” (2:33). When several regions would do, stay contextual: a search field “takes advantage of the extra space” (5:00) when the device is open and, as it folds, its “width and position adapt to remain over the view it’s searching” (5:04).

The system does most of this. “Action sheets, alerts, menus, and popovers are all lightweight contextual experiences that can appear over a reserved region,” (5:23) and it “automatically repositions components around the reserved region” (5:34). A split view “keeps both columns visible by adjusting their width and positioning them into an even 50/50 split” (5:40). A grid is the case you own: in Maria’s Fitness design, “I can preserve the outer margins while increasing the spacing around the hinge, keeping each container within its region” (5:56). Her summary of every example is the design brief: “we’re moving, resizing, or reorganizing what’s already there. Keep content, functionality, and layouts available so people can access the full experience regardless of how they’re using iPhone Duo” (6:04).

Reserved regions, the machinery under displacement

Maria introduces the term in the adaptive-layouts talk: “New hardware features also play a role in shaping the available space. These include the hinge and the two cameras across the outer and inner displays. We call these reserved regions,” (0:37) and advises treating them “just like any other areas your layout already adapts to,” (0:53) her example being the window controls on iPadOS. There are three: the outer camera, the inner camera while it is active, and the fold (1:00, 1:18, 1:32). The developer post carries the guide’s definitions of each and records my check that the guide links no documentation for the APIs, so this section stays with the machinery. Harry, a UI Frameworks engineer, describes the API. “In SwiftUI, you query reserved regions using a GeometryProxy from a GeometryReader or onGeometryChange modifier. Use the new reservedRegion method on the geometry proxy to get the regions available in your view.” (6:38) In UIKit, “you’ll use the reservedRegion method available on UIView,” (7:03) and “you can query the frame property of a reserved region to incorporate it into your own layout” (7:07).

There are two kinds. The fold “is backed by a division reserved region because it divides a larger area into multiple smaller areas,” (6:55) and it “is only active when someone has folded the device. When flat, it’s inactive and has a width of zero” (7:26). The camera is an occlusion region: these “don’t divide areas, instead they occlude them,” (7:54) and the region “is active when the camera is active and inactive when the camera is inactive” (8:12). Inactive regions are queryable with the includeInactive option, and Harry’s reason to look at them is a design decision: “in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state” (7:41). The guide repeats that as a rule. As of 4:15 p.m. PT on the day of the keynote, the guide links no documentation page for these APIs, and Apple’s developer page dates the Xcode 27.1 beta to “later this month.”

Arrangements: split or overlay

Frame from Apple’s September 9, 2026 event stream, 11:00 a.m. PT: the inner display Apple calls 80 percent larger, the canvas arrangements are for.

Harry’s definition: “A layout container sits in between these navigation and content containers. These layout containers arrange two views according to a set of rules. They’re called arrangements” (9:20). The rules take inputs, “the horizontal and vertical size class of the view, the aspect ratio of the view’s width over its height, and whether there are any active division regions,” (10:37) and produce outputs: “whether I should show the view at all” (10:52) and, if so, “what’s its frame” (10:54). Then the date: “in iOS 27.1, you can use system provided arrangements in your own apps” (11:02).

In SwiftUI an ArrangementView takes a primary and a secondary view (11:25) and a style set with arrangementViewStyle (11:57); in UIKit a UIArrangementViewController takes primary and secondary view controllers (11:39). The split style, the default, “splits horizontally when the view is wider than it is tall” (12:13) and vertically when taller, and can be restricted to one axis; if it cannot split on its primary axis it “chooses to only show a single view” (12:49). The overlay style “prefers to position content above or below each other,” (13:31) and when the device folds it “prefers to position the primary and secondary views side by side,” (13:51) which a view can detect through the overlayArrangementZIndex environment property to switch between a collapsed and an expanded form (14:01).

Choosing between them is the talk’s clearest advice, and the guide adopts it. “If you’re already implementing a split-like layout in parts of your app using components like an HStack or VStack, consider using the split arrangement. If you’re already implementing an overlay-like layout in parts of your app using components like a ZStack, consider using the overlay arrangement” (14:44). Without an existing pattern, use an overlay “when there’s a clear foreground/background relationship between your views,” (15:10) like controls over readable content in Accessibility Reader, and a split “when there’s more of a main detail relationship,” (15:32) like a podcast and its transcript, where “it’s important that neither of them are ever obscured” (15:43). The two limits, navigation containers around an arrangement rather than inside it and no arrangement inside a List or ScrollView, are at 16:15 and 16:26 in the talk; the guide states only the first, in the sentence the developer post quotes.

The inner display: three honest layouts

“You don’t want just a stretched out iPhone app” (7:39). Vince offers three shapes. A split view, which surfaces “multiple levels of your app hierarchy at the same time” (7:46), with the condition that the hierarchy “doesn’t change between the outer and inner displays,” (7:51) because people “may open and close the device frequently while using your app, so it needs to be predictable and consistent inside and out” (7:59). A reflow, following Music, where “a vertically stacked layout” (8:15) becomes “a two-column layout when there’s more horizontal space” (8:18). Or a tab bar presented “as a sidebar on the inner display,” (8:26) which “works best for information-dense apps like this example from Health” (8:33). The guide’s Mail example is the split view case: a list or a message when closed, both side by side when open.

Sheets get their own rules. On the outer display “sheet controls also move to the side,” (8:46) which you can turn off for a sheet with a single toolbar button, in which case “sheets stop just short of the front-facing camera and the status bar repositions itself” (9:04). On the inner display sheets “use standard horizontal bars” (9:13) by default, and when the device is partially folded they “slide over to avoid resting in the fold” (9:20). The bars talk adds the placement exception: inner-display sheets are “centered by default, and items remain horizontal,” (4:03) but with the preferredPlacement API, “sheets placed on the left remain without a vertical bar, while sheets placed on the right receive one” (4:11).

The audit

The bars talk and the adaptive-layouts talk each end with an audit list, so here they are as one. The bars talk’s closing list (15:10): build with the latest SDKs, because the vertical bars are opt-in by SDK (2:06); audit the bars and their order (4:41), and update custom items so they can lay out vertically; and assign visibility priorities “so the system can adapt” (15:26). Then, from the adaptive-layouts talk (16:40): “start by auditing your app’s centered layouts. Consider whether you can make it a two column layout, or what displacement pattern makes sense in that use case”; use standard containers and presentations for the free behavior (16:49); reach for ArrangementView for custom split or overlay layouts; and “identify the highest priority manually laid out controls in your views and consider adopting the ReservedRegions API to implement your own displacement where needed” (17:06).

What I plan to do with it

Three of my apps are iPhone apps, and the guide sorts them cleanly. The sorting is my reading, not Apple’s.

• Get Bananas is a list. Lists do not displace, the tab bar and toolbar move to the side on their own if I keep using the system containers, and the one design decision is the visibility priority: the add-item action is my Compose, so it should be the last thing to overflow.
• Reps logs each set as a row of weight, reps, and a log action, in a grid during a workout, which is Maria’s Fitness example. The decision: in the book pose a three-column row puts the middle column on the hinge, so the grid goes to two paired columns. In the table pose the log action sits in the bottom half. The tradeoff is one more tap per set against a target that never lands in the fold, where Vince says “buttons are tough to tap” (9:28). The rest timer stays at the top, the region Maria says works well for “content that benefits from visibility at a distance” (4:29).
• Return draws health charts, which are scrolling content. Where a chart and its range picker sit in a vertical stack today, Harry’s rule maps that stack to a split arrangement, which keeps both visible as the device folds; the chart itself should never displace.

Key Takeaways

For designers:

• Two size classes, not poses: compact width outside, regular width inside. The one optional extra Apple’s designers suggest is a table layout that keeps the same controls.
• Icons go vertical, text stays horizontal; the top of the side bar is Back or Close, then Done; frequent actions and badged items overflow last.
• Scrolling content never displaces; alerts, menus, sheets, and controls do, and the destination follows purpose: alerts to the trailing side in the book pose and to the top region on a table, touch controls to the bottom half.

For design engineers:

• The fold is a division region that is active only when folded and has zero width flat; the inner camera is an occlusion region active only when the camera is; both are queryable from a GeometryProxy or a UIView.
• Arrangements ship with iOS 27.1: a stack becomes a split, a ZStack becomes an overlay, and navigation containers stay outside them.
• Use system bars from navigation containers, or the vertical layout never happens.

FAQ

Do I need a layout for each pose?

No. Apple says to design for two size classes, compact width on the outer display and regular width on the inner display, and to avoid fixed widths, breakpoints, or metrics tied to a screen. The one optional extra, from the design talk, is a table-pose layout with the same controls and hierarchy.

Which controls stay horizontal on iPhone Duo?

Text-only items, items too wide for the side bar like segmented controls, items that switch between a symbol and text like Edit, keyboard accessory bars, and, if you choose, the whole bar in a bottom-heavy single-page app or a sheet with a single toolbar item.

What is displacement?

Apple’s pattern for moving, resizing, or reorganizing existing elements so they stay visible and reachable when the device is partially folded. Alerts, menus, popovers, sheets, and toolbar buttons get it from the system; scrolling content is exempt.

When do arrangement views and reserved-region APIs ship?

The adaptive-layouts talk says system-provided arrangements are usable in your own apps in iOS 27.1, and Apple’s developer page dates the Xcode 27.1 beta to later in September. The design guide links no documentation for either API yet.

Does scrolling content have to avoid the fold?

No. Both the design talk and the adaptive-layouts talk exempt scrolling content; it already adapts through scrolling.

Sources

1. Apple Human Interface Guidelines, Designing for iPhone Duo, change log entry dated September 9, 2026 (“New page”), fetched September 9, 2026 at 4:15 p.m. PT. Quoted: the size-class sentence and the poses list. Paraphrased: the three reserved regions, the even-columns rule, the Mail example, and the safe-area note on Split View.
2. Apple Developer Tech Talk, Design for iPhone Duo, Marcos and Vince, Apple design team. Quotations are from the talk’s English subtitle track at the timestamps given in parentheses.
3. Apple Developer Tech Talk, Strike a pose with adaptive layouts on iPhone Duo, Maria, Human Interface Designer, and Harry, UI Frameworks engineer. Quotations are from the talk’s English subtitle track at the timestamps given in parentheses; API names are as spoken in the talk.
4. Apple Developer Tech Talk, Raise the bar with iPhone Duo, Anna, UI Frameworks engineer, and Maria, Human Interface Designer. Quotations are from the talk’s English subtitle track at the timestamps given in parentheses; API names are as spoken in the talk.
5. Apple Developer, Get Ready for iPhone Duo, fetched September 9, 2026 at 4:10 p.m. PT: “Xcode 27.1 beta … Coming later this month”; the design guide linked in place of the earlier “Coming soon.”