iPhone Duo's Official Human Interface Guidelines: The Device Changes Form at a Gesture, but Your Attention and Workflow Never Break

Apple has finally released its own foldable phone, iPhone Duo. The device has not yet gone on sale, but Apple has already updated its Human Interface Guidelines with guidance dedicated to designing interfaces for iPhone Duo.

The overarching principle of the entire guideline is this: apps must adapt seamlessly between the two displays, and the experience across folding and unfolding must remain continuous. There are three core guidelines:

• Prioritize continuity. Closing, half-folding, and unfolding are physical actions that should never become breaking points in the software experience. When a person changes postures, functionality, element states, and focus on the task at hand must all carry over.
• Adapt to form, but don't customize for poses. The system adjusts layout to match the physical form—during a half-fold, overlay views split to both sides, and columns automatically become equal in width. Yet the guideline is unequivocal: do not write a separate layout for each pose. What changes is the system, not your code branches.
• Adaptation is not enlargement. Moving from the outer display to the inner display is not about stretching icons and font sizes, but about restructuring information hierarchy as usable area expands: a single column unfolds into a two-column view, and hidden drawers become persistent sidebars.

To understand the interface design guidelines for iPhone Duo, one must first look at what changed with its physical displays.

Prior to this, the iPhone display aspect ratio long remained around 19.5:9, typical of a "tall and narrow" screen. On such tall screens, placing a navigation bar at the top and a tab bar at the bottom still left plenty of vertical height for users to scroll up and down to read content.

However, the form factor of iPhone Duo completely overturns this premise:

• Outer display: A 5.4-inch OLED display with a resolution of 1398 × 2034 pixels. It remains a portrait display, but its aspect ratio is roughly 1.455:1, closer to 3:2 than the 19.5:9 of other iPhones—relatively wider horizontally and shorter vertically.
• Inner display: A 7.6-inch foldable OLED display with an unfolded resolution of 1878 × 2670 pixels, similarly trending toward squarish large-screen proportions.

iPhone Duo outer display Home Screen: screen aspect ratio is wider and shorter than traditional iPhones, and the layout center of gravity for interface controls shifts toward the side.

The 7.6-inch inner display Home Screen of iPhone Duo unfolded: on the same Home Screen, app icons expand from 4 columns on the outer display to 8 columns.

If the traditional "top navigation bar + bottom tab bar" design were retained on the outer display, sandwiching content from top and bottom, the remaining reading area in the middle would be severely compressed, showing only a handful of lines per scroll.

Therefore, the core solution Apple offers in the iPhone Duo guidelines is: move control bars to the side.

When closed and using the outer display, the system by default moves the toolbar, tab bar, and key action controls to a vertical axis along the side of the screen; when opened on the inner display in landscape orientation, these controls also remain on the side, ensuring that vertical content height does not jump jarringly when users unfold the screen or rotate the device. The guidelines repeatedly emphasize: this is still designing for iPhone, and established iOS patterns and best practices remain applicable. Apps that use standard system components and already support resizing will adapt to various poses with almost no changes.

Hardware Anatomy: Placement Rules for Dual Displays, Cutouts, and Invisible Cameras

The physical structures of the inner and outer displays on iPhone Duo differ, which directly dictates where system interactive elements are positioned (the table below can be scrolled sideways on phones):

The spatial relationship is worth noting: on the outer display, the hinge is along one side edge and the camera is at the top corner of the opposite edge; on the inner display, the crease passes straight through the center, while the camera is not in the center, but above the half-screen to the right of the crease. An interactive diagram is provided later in the discussion of reserved regions where both forms can be compared.

Building on this hardware foundation, the permanently visible front camera on the outer display aligns strictly with side controls along the vertical axis; meanwhile, the inner front camera uses an under-display hidden design that remains completely invisible during everyday browsing. Only when the camera is called or during video calls does the system actively move surrounding interface elements aside to mark the active location of the lens.

Vertical Controls: How the Side Single Rail Works

Controls that were previously scattered across the top and bottom of the screen are moved to the side here—yet rather than merging into a single strip, they remain organized into distinct sections according to their original groupings. In the guidelines, Apple specifies the hierarchical order and adaptive logic of this "side control rail."

1. Order of Controls on the Vertical Axis

When holding the outer display in one hand, side controls are anchored strictly top-to-bottom:

1. Dynamic Island: Positioned by hardware—it is the software form of the outer camera cutout, expanding from here when Live Activities occur. The side control rail starts aligned with it.
2. Status Bar: Displays time, battery, and network status.
3. Toolbar & Navigation: Houses primary page actions such as "Back," "Close," or "Done."
4. Tab Bar: Carries the core module switching of the app, parked in the easy-to-reach zone at the bottom.

Four-part layout of the outer display side control bar from top to bottom: Dynamic Island, status bar, toolbar, and tab bar.

It should be noted that this vertical control rail is active only on the outer display and on the inner display in landscape; when the inner display is held in portrait, ample vertical height allows the system to automatically restore the familiar top bar and bottom horizontal tab bar. The position of controls on the vertical axis is one of iPhone Duo's most fundamental patterns, and default bar placement should generally not be overridden; furthermore, because vertical controls stay aligned with the hardware, they maintain a relatively fixed position relative to the camera on the outer display and will not switch to the other side in right-to-left (RTL) language environments.

Precisely because controls are not placed on the side in every pose (portrait on the inner display reverts to horizontal bars), and available space varies, the guidelines specifically emphasize that relative control positions must remain consistent across poses: when people switch postures, they should not have to hunt for where buttons went. This is the concrete requirement of "uninterrupted attention" applied to interface controls.

2. Avoiding Asymmetric Conflicts and Split View Multitasking

Because controls are tucked to one side, the visible content area naturally exhibits asymmetry.

• In single-app mode, safe area insets must be relied on to ensure scrollable content is not obscured by side controls.
• In Split View multitasking with two apps, the apps flank both sides of the crease. Here, the system mandates: the left app's control bar is arranged along the far left edge, and the right app's control bar along the far right edge. Both apps hug the outer hardware borders. The guideline’s reminder here: use the safe area to prevent controls from covering content, and take into account controls on the opposite edge as well—your app does not know which side it will be placed on, so safe areas on both sides must be handled.

In Split View multitasking with two apps, control bars are positioned at the far left and far right outer edges of the screen, operating without mutual interference.

3. Action Button Priority and Overflow Collapsing

While vertical space on the side is more generous than horizontal width, it can still become cramped as features accumulate. The default order given by the guidelines is bottom-up: when comparing toolbar items among themselves, items positioned lower collapse first into the ellipsis overflow menu (which resides in the toolbar group in the upper section of the side rail).

Note that this rule applies to which toolbar items yield first among themselves. Which of the two bars—the toolbar or tab bar—yields first is a separate rule discussed in item 4 below; both are termed "default," but govern different things.

Developers can specify priorities for actions via APIs (ToolbarItemVisibilityPriority in SwiftUI, UIBarButtonItemVisibilityPriority in UIKit):

• Retain high priority first: Items like "Compose" in Mail, "New Note" in Notes, or items with badges conveying critical status should collapse later so users can spot them at a glance.
• Use text buttons sparingly, prioritize symbols: The mechanism provided by the guidelines is that labeled buttons with text remain in horizontal bars and do not move to the side vertical axis. But it stops there, leaving unstated where such buttons actually appear—or whether they appear at all—on forms like the outer display that lack a horizontal bar entirely. The weight of this recommendation stems precisely from what is left unstated: use symbols whenever possible, and avoid text buttons.
• Provide both title and symbol: Except for items that are inherently text-only, every toolbar item should provide both a title and a symbol, allowing the system to pick which to use based on context; even when a symbol is displayed, include a title—it is what appears in overflow menus and expanded presentations.
• Group related items and avoid manual spacing: Organize related toolbar items using component groupings (ToolbarItemGroup in SwiftUI or UIBarButtonItemGroup in UIKit). The system automatically spaces items and groups while adapting to available space, avoiding manual insertion of fixed spacing.

4. Two Compression Strategies Under Constrained Space

First, establish a prerequisite: the side control rail is anchored to the hardware. When the device is used in landscape, the control rail remains on the same hardware edge (staying relatively fixed relative to the outer display camera) rather than rotating back to the top or bottom of the screen. The trade-off is that the usable length along this edge becomes significantly shorter, leaving insufficient room for both the toolbar and tab bar. The guidelines define two fallback strategies for this:

• Navigation-oriented (default): Toolbar contents collapse first into the ... overflow menu, preserving the tab bar in full. Suited for browsing and channel-switching scenarios.
• Task-oriented: The tab bar compresses into a single minimized control, clearing space to display complete toolbar buttons. Suited for document editing, drawing, or specific workflows.

Behind both strategies lies a baseline principle: compress presentation, not availability. As interfaces adjust to available area, controls may collapse into overflow menus, and content may shift or resize; all of this is permitted. But regardless of how people hold or view the device, the same controls and content must remain accessible—changing a pose must never cause functionality to disappear.

Navigation-oriented compression (shown on the outer display in landscape, with the Dynamic Island black dot in the lower-right corner): the toolbar collapses into an ellipsis menu, while tab bar items remain intact.

Task-oriented compression (also shown on the outer display in landscape): the tab bar shrinks into a single control, yielding space to complete toolbar buttons.

5. Proximity Principle for Local Controls

Not every button belongs on the side rail. The guideline principle is: place controls alongside the content region they belong to, rather than relocating them to the side for the sake of uniformity—position itself tells the user what a button governs.

Taking Mail with a split-view layout as an example, actions affecting the entire message list (such as sorting or filtering) must stay at the top of the left list pane; only actions specific to the currently viewed message (such as reply, archive, or delete) appear on the far-right vertical toolbar.

Control proximity principle: controls affecting the left list remain above the list, while controls affecting the message body on the right are aligned on the far-right sidebar.

Reserved Regions: More Complex Avoidance Physics Than Safe Areas

In previous iOS development, interface avoidance relied primarily on the safe area—avoiding display rounded corners, the Home Indicator at the bottom, and the notch or Dynamic Island at the top. But on iPhone Duo, with the introduction of foldable characteristics, Apple expanded this mechanism into reserved regions.

Reserved regions represent physical and functional intervals on the screen where "content cannot overlap" or "components must dynamically avoid." Most system components step out of the way on their own; custom components must use reserved region APIs to move content aside, ensuring critical elements steer clear of these locations:

How the Crease Affects Interface Layout

When a user unfolds iPhone Duo flat on a desk, the center crease is simply part of a continuous, normal display. But as soon as the user partially folds the device (such as opening it like a book, or propping it up like a laptop), the system marks this center crease as a reserved region (called "fold region" in the component, which is the same thing) and triggers avoidance behaviors:

1. Automatic repositioning of popovers and menus: System alerts, context menus, and sheets avoid being awkwardly split across the crease, automatically moving aside so they do not sit on it.
2. Symmetric restructuring of split lists: Taking Notes as an example, when unfolded flat, the left note list is narrower and the right note content is wider; in a partially folded state, however, the system split view automatically widens the left column to a full 50%, letting the list occupy the entire left display and content occupy the entire right display.
3. Use even column counts for grids: When designing flow-based grid layouts, prioritize even column counts (2 columns, 4 columns, etc.) so content cleanly divides across both halves when folded.
4. Do not use this as an excuse for major layout overhauls: The guidelines specifically caution against shifting anything beyond elements that would otherwise be unreadable or untappable. Suddenly disappearing controls or drastic jumps make interfaces difficult to track; subtle adjustments are always preferable to tearing down and rebuilding.

Fully unfolded: the note list on the left is narrow, while the content on the right is wide.

Partially folded: the left column automatically expands to match the right column's width, each occupying a physical half-screen. Both official diagrams render the device chassis identically; the difference lies solely in the width ratio between the left and right columns.

New Containers: Two Modes of Arrangement Views

If reserved regions describe "which areas the system steps around for you," arrangement views describe "how to lay out your own two views to keep pace with these changes." To reduce the cost of developers writing conditional layout checks for dual-screen folding, Apple introduced this entirely new layout container to the iOS ecosystem.

An arrangement view manages two subviews internally: a primary view and a secondary view. It automatically coordinates the geometric relationship between these two subviews based on whether the device is on the inner or outer display, in landscape or portrait, flat or partially folded. However, throughout the guidelines, Apple never provides an abstract criterion for "which content should be Primary"; developers can only deduce this from specific behaviors—for instance, in an overlay arrangement, the Primary view is the layer superimposed on top (hence usually a control panel or action card), while the Secondary view is the base layer underneath.

The guidelines divide arrangement views into two major categories:

1. Split Arrangement

Split arrangement is designed for scenarios requiring two screens side by side (the guidelines offer no product examples; two are provided here for comprehension: watching video on the left, reading comments on the right; viewfinder on top, photo album below).

• Horizontal split: Arranges subviews side by side automatically when container width exceeds height.
• Vertical split: Arranges subviews stacked vertically automatically when container height exceeds width.
• Code intuition and axis constraints: The mapping provided by Apple indicates that horizontal stacks (HStack) or vertical stacks (VStack) in SwiftUI translate directly into split arrangement, and the guidelines suggest considering migration if an existing layout resembles them; developers can also restrict the axes permitted for split arrangement. One point the guideline leaves unstated: regarding whether primary or secondary comes first or sits on the left in a split arrangement, the guideline provides no rule; official diagrams illustrate secondary on the left and primary on the right—if you follow the intuition of HStack and treat the first subview as primary, the order is reversed. When actually migrating, this sequence must be tested on your own.

Split arrangement: secondary view and primary view each take half of the available area. This diagram illustrates the fully unfolded state.

2. Overlay Arrangement

Overlay arrangement suits scenarios combining primary content with floating overlay panels (again, provided for comprehension: a map base layer with a floating search card; full-screen video playback with a floating console).

• When fully flat: The secondary view fills the entire screen, while the smaller primary view stacks atop the secondary view as a card or floating layer.
• When partially folded: The two views automatically decouple from their layered arrangement, each standing apart to occupy a physical half-screen—for example, the upper half propped upright displaying video, while the lower half rests flat on a desk serving as a controller.
• Code intuition and fold toggling: This maps directly to layered containers (ZStack) in SwiftUI. When developers prefer the secondary view not to appear, they can also actively collapse it.

Overlay arrangement: the secondary view fills the screen, and the primary view rests atop it as an overlay. This diagram illustrates the fully flat state; when partially folded, the two separate to occupy each side, which is not shown here.

Architectural Red Line: Arrangement views handle only geometric placement and do not manage navigation. The guideline states: navigation containers must wrap around arrangement views rather than sit inside them—NavigationSplitView / TabView in SwiftUI, corresponding to UISplitViewController / UITabBarController in UIKit.

Six Poses: Why Apple Urges You Not to Adapt to Each One Individually

The hinge gives iPhone Duo many ways to be held and propped up. The official documentation provides illustrations for six poses, while the text of the guidelines explicitly names three: half-folded like a book, lying flat on a desk, and propped up on an edge.

Official pose diagram, showing six panels from left to right: closed and held in portrait (outer camera cutout visible in the top-right corner), propped diagonally on a table along a horizontal hinge, fully unfolded lying flat in landscape, book-style V-shape half-fold, fully unfolded lying flat in portrait, and partially folded upright along a horizontal hinge. There are no text labels on the diagram, and the guidelines text explicitly mentions only three of them.

Faced with so many poses, many developers and designers instinctively ask: do we need to write six layout routines, listening to device gyroscope or hinge angle sensors?

The guideline's answer is unequivocal: do not design separate layouts for each physical pose.

The Familiar Key: Size Classes

Apple’s recommended path is to keep relying on the established iOS size class system. Within this framework, screen real estate is not measured by absolute pixel counts, but abstracted into two categories: compact and regular. The system dynamically determines size classes based on device type, window configuration, and multitasking status; Apple’s advice is to design for compact width on the outer display and regular width on the inner display, which together suffice to cover basic presentations across various poses. However, an objective constraint exists here: on the inner display, portrait mode restores top and bottom horizontal bars, whereas landscape maintains the side vertical rail—two completely different control layouts, yet the system size class for the inner display width remains the single value (Regular) in both. For this divergence driven by orientation switching, the guideline states that the system handles it automatically (so long as standard components are used), but throughout the entire text leaves unstated what specific variables developers should use when custom code is needed to distinguish between portrait and landscape on the inner display.

Developers only need to refine two foundational presentations:

1. A single-column layout that stows away cleanly under compact width;
2. A multi-column or split layout that expands comfortably under regular width.

Another point is easy to overlook: cross-display consistency required by the guidelines operates on three levels. Functional consistency is the first level; element state consistency is the second—the same toggle or the same selected item cannot change appearance across displays; the third and most crucial level is that information hierarchy remains unchanged, only revealing an extra layer on the larger inner display when content genuinely calls for it.

Taking the built-in system Mail as an example:

• In the closed state (outer display/compact width), constrained by usable area, the user must choose between list (primary) and message body (secondary), seeing only one layer of content at any given time.
• In the unfolded state (inner display/regular width), both progressive layers are present simultaneously: the list stays persistently on the left, with the message body on the right. The hierarchy has not changed at all; it simply reveals an extra layer—no hardcoded "foldable inner vs. outer display" branching is needed in code.

On the outer display: a single-layer list or message body occupies the entire screen, representing a typical compact size class experience.

On the unfolded inner display: automatically stretches into a two-column split view with list on the left and detail on the right, representing a typical regular size class experience.

Cross-Display Handling for Game Interfaces

For the principle of "not specializing layouts for each pose," the guidelines carve out an exception for immersive games: orientation may be locked strictly to landscape or portrait. But this exception has boundaries—when poses change, visuals must still fill the entire screen. Concrete recommendations include:

• Prioritize aspect ratio adjustments: Rather than relying on black bars (letterboxing / pillarboxing), prefer adjusting the aspect ratio to utilize the screen naturally; if black bars are unavoidable, artwork assets can be added to the surrounding padding area to help maintain full-screen immersion.
• Keep controls consistent during scaling: When resizing and scaling interfaces, text and control dimensions should remain as consistent as possible.

Two Final Considerations: When Full Width Is Allowed, and What You Need to Change

Full-Width Interfaces and Calculator’s Shift from 4 columns × 5 rows to 5 columns × 4 rows

For interfaces that do not require persistent control bars, the guidelines recommend considering taking up the full width of the display, provided there are no conflicts with the Dynamic Island or status bar—an approach well-suited to non-scrolling, immersive visual interfaces.

Taking Calculator as an example, it spans the full width of the display on the iPhone Duo outer display, restructuring its button matrix from 4 columns × 5 rows on iPhone 16 to 5 columns × 4 rows, while keeping the two circular tool buttons at the top—full width does not mean stripping away controls. In actual design, full width and inset layouts can also be combined: for instance, extending a background image or page header across the full width of the display while keeping interior scrollable content inset.

Evolution of the Calculator grid: iPhone 16 on the left uses a traditional 4 columns × 5 rows vertical button layout, whereas the iPhone Duo outer display on the right restructures into 5 columns × 4 rows, fitting the wider physical outer display more naturally.

Migration Checklist for Developers and Designers

As noted earlier, apps that use standard system components and already support resizing will require little modification. The checklist below targets the other group: apps with hardcoded widths, custom layout drawings, and manually positioned controls. The implementation principles outlined in the guidelines boil down to five rules:

1. Eliminate all fixed widths: Any layout code that hardcodes widths or relies on a specific screen must be rewritten to adapt dynamically, using safe area insets and system layout margins instead.
2. Use pure text buttons sparingly: Except for items that are inherently text-only, provide both a title and an icon for every toolbar item (Label("Title", systemImage: "..."))—the system uses that title in overflow menus and expanded presentations.
3. Partition control ownership rather than piling everything onto the side: Place filtering and creation for the left pane at the top of the left column, reserving the right vertical axis for actions on the right detail view, maintaining spatial proximity between controls and the objects they act upon.
4. Audit toolbar item visibility priority: Identify the 1–2 core, high-frequency actions in your app (such as compose, search, checkout) and grant them the highest visibility priority; ensure all secondary features are prepared to collapse gracefully into the ellipsis overflow menu.
5. Entrust side-by-side and floating elements to arrangement views: Replace custom coordinate positioning and bespoke animations for side-by-side cards or floating controls with native split or overlay containers, allowing the system to handle crease avoidance and unfolded repositioning.

Conclusion: From "Making the Phone Bigger" to "Standing the Interface Up"

The iPhone Duo HIG does not follow the tired foldable path of simply "scaling up the app viewport." When the screen gets wider and shorter, controls stand up along the side; when the hardware adds a crease, it is abstracted into a system-level reserved region; when poses become too numerous to count, size classes are called upon once again to absorb them.

All three steps point to the same philosophy: what changes is how layouts settle, but what remains unchanged is that it is still an iPhone—as the guidelines themselves note, apps using standard components that support resizing will barely need to be touched. Real effort will be required where layouts are drawn and controls are placed by hand. These rules will only truly be validated once the device lands in users' hands—for now, what is certain is only how Apple plans to build it.