Adaptive layout guide

How should layouts adapt on iPhone Duo?

An app can move between displays, orientations and window sizes without starting a new user task. Treat full-display layouts as examples, not the only possible app bounds. The current scene and system containers determine the usable space.

A full-window inner display can offer a regular-width layout, but an app in a smaller window must respond to its actual traits and dimensions. Do not infer every window’s size classes from the hardware name.

Apple Staff confirms that iPhone Duo uses the .phone idiom. Supporting Duo does not require adding an iPad target; supporting a regular-width iPhone window and choosing to support iPad are separate decisions.

Use the current scene, not global screen assumptions

Apple advises against using the main screen as a layout source on a device with multiple displays. Prefer SwiftUI environment values, UIKit trait collections, the current scene bounds, or a screen obtained from the relevant window scene.

The inner display does not follow supported interface orientations in the same way as the outer display, so layout branches based on interface orientation are less robust than size-class and available-space decisions.

Let system navigation and presentation containers adapt first

NavigationSplitView, UISplitViewController, TabView, and UITabBarController already adapt across iPhone Duo poses. Columns can collapse when closed and appear tiled or overlaid when open. Sheets, popovers, context menus, and alerts also adapt.

Before building custom pose logic, verify whether a standard container already expresses the desired behavior. Custom bars should use safe areas and reserved regions rather than hard-coded offsets.

When do controls move into the vertical bar?

Standard navigation containers contribute their toolbar and tab items to the vertical bar. A standalone custom bar does not gain this behavior automatically. Items need an icon and a useful title so the system can present them in different locations.

Display-edge placement matters: in a split view, the detail column can participate while other columns stay horizontal. Inspectors do not receive a second vertical bar.

Choose the layout API for the job

Keep the scene, bar and fold decisions separate. Use an arrangement only when the relationship between primary and secondary content benefits from it.

Design around the fold with reserved regions and displacement

When partially folded, the hinge can become an active division reserved region. Apple’s displacement pattern moves the existing element or container into an appropriate usable region while preserving its relationship to surrounding content.

For more structured two-region layouts, Apple’s arrangement APIs can express split and overlay presentations. Do not move every element independently simply because a fold exists; preserve meaningful groups and avoid unnecessary motion.

Use the reported layout arrangement and reserved regions for layout decisions. A hinge-angle value can drive a visual effect, but an invented angle threshold is not a substitute for the system’s usable-region information.

Preserve the task while the layout changes

Treat layout state and business state as different layers. Opening the device may change columns, bars, safe areas, and viewport dimensions without changing the selected item, draft text, pending request, media position, or current workflow step.

For WKWebView, keep the page instance alive when possible, update the native container, and let the web layout reflow inside the supplied area. A resize callback should not be an implicit signal to reload data or recreate the page.

For a design review, try one list-to-detail task with the same realistic content in a compact and a wider composition. Mark the selected item, unfinished input and scroll position that must survive. This is a Plurigent exercise, not a tested platform result.

• Keep selection and navigation context stable when columns appear or collapse.
• Keep form values and validation state through size changes.
• Reposition sheets and overlays without duplicating requests.
• Recompute safe areas and viewport values instead of caching device-model constants.
• Test keyboard-visible transitions, not only empty static screens.

Common adaptive-layout anti-patterns

Avoid device-name checks, fixed screen-width tables, mirrored safe-area assumptions, global UIScreen.main layout logic, and component recreation tied directly to width thresholds. These approaches make one screenshot look correct while weakening the next configuration.

Use explicit layout rules and observable test cases instead: which content has priority, what changes at compact versus regular space, what remains the same, and what state must survive.