Adaptive layouts around the fold

When iPhone Duo is partially folded the inner display curves through the middle. Anything sitting in that curve gets harder to read and much harder to tap. The same thing happens to a photo printed across the spine of a book: near the gutter it stops reading as one continuous image.

So the fold is not decoration. It is a real constraint on where content can go — and iOS models it as a reserved region you can query and design around.

Reserved regions

Reserved regions are areas of the view that hardware imposes on your layout. Treat them exactly like the window controls you already work around on iPadOS: not obstacles, just facts about the available space.

Two kinds, and the distinction matters:

Division regions split one area into several smaller usable areas. The fold is a division region. Content does not flow through it — it belongs on one side or the other.

Occlusion regions cover part of an area without splitting it. Think of them as frames sitting inside your bounds. The inner FaceTime camera is an occlusion region.

Concretely, iPhone Duo has three reserved regions, and it's worth knowing which is which because they behave differently:

Regions are active or inactive:

• The fold's division region is active only while the device is partially folded; fully open, it is inactive. The Tech Talk adds that it then has zero width, but the later reference and Group Lab Day 3 both say an inactive region keeps a frame, and suggest reading it ahead of time so a layout already clears the fold and nothing moves when the device bends. Check that frame in the simulator before depending on its size.
• The camera's occlusion region is active only while that camera is streaming.

Note the asymmetry between the two cameras: the outer one is a permanent fact of your layout, while the inner one appears and disappears under you. Handle the second as a change you animate through, not a constant you read once.

You get only the active ones by default; the Tech Talks and the API reference agree on that. Pass the includeInactive option to also see regions that exist but aren't currently in play — which is what you want for stable, high-level decisions. A grid, for instance, can prefer an even column count on any device that has a fold, so the layout doesn't reshuffle every time the user bends the device.

Querying them

In SwiftUI, get a GeometryProxy from GeometryReader or onGeometryChange, then ask it for reserved regions. Note the two signatures differ — SwiftUI takes a third parameter UIKit doesn't:

// SwiftUI, on GeometryProxy
func reservedRegions(
    kind: ReservedRegion.Kind,
    options: ReservedRegion.QueryOptions,
    layoutDirectionBehavior: LayoutDirectionBehavior
) -> [ReservedRegion]

// UIKit, on UIView
func reservedRegions(
    kind: UIView.ReservedRegion.Kind,
    options: UIView.ReservedRegion.QueryOptions = []
) -> [UIView.ReservedRegion]

The layoutDirectionBehavior argument matters in right-to-left layouts: the fold is fixed in hardware, so whether you want region positions mirrored with your content or left in physical coordinates is a decision you have to make rather than inherit.

Pass .includeInactive in options to also get regions that exist but aren't currently active.

Each region gives you more than a rectangle:

• frame — where it sits in the view's coordinate space.
• isActive (active in Objective-C) — whether it's currently in play.
• kind — division or occlusion.
• margins — the clearance the system keeps for interactive content. The reference is explicit that frame already includes these margins, so keeping controls out of frame is enough; don't pad by margins a second time. Inset frame by margins to get the bare hardware area — the limit for full-bleed media, which may run closer than controls.
• id — stable across queries, so you can tell the region you saw last time from a new one. ReservedRegion is Identifiable, so regions can drive a ForEach directly.

Frames are in the coordinate space of the view you queried, with (0, 0) at its top-leading corner, and only regions that overlap that view come back. A region that clips a corner can have a negative origin or run past your bounds, so don't assume it lies inside them. Query in the view that does the positioning, so the frames and the content share coordinates. Two places this bites:

• In a custom SwiftUI Layout, the bounds passed to placeSubviews don't always start at (0, 0). Compute positions from zero and add bounds.origin only when you place each subview.
• In UIKit, read regions in updateConstraints(). UIKit tracks what you read there and calls it again when the regions change, so you don't need an observer of your own.

In SwiftUI the query takes a third parameter, layoutDirectionBehavior (default .mirrors), which flips region frames for right-to-left layouts so a custom Layout doesn't have to. Pass .fixed for the physical frames.

Query reserved regions for custom, manually laid out controls. If you are using system containers, you already have this handled — see below.

Displacement: the design pattern

Most interfaces can simply flow around a reserved region. Some deserve a more deliberate response, and the pattern for that is displacement — adjusting an element's frame based on the available space so that important content stays visible, reachable and unobstructed while the device is folded.

The typical case: an element sits centered while the device is open, and once folded it moves into whichever region actually supports its purpose.

Choose the right scope. Displacement scales from a single button to an entire container. If an element can stand on its own, move it alone. If elements work as a unit, move them together — pulling a context menu away from the photo it belongs to breaks the relationship even though both are technically visible.

Don't move things far. Distance weakens the visual link between an element and its source. Aligning both around the fold usually beats banishing one to the far region.

Don't displace continuously scrolling content. Articles, feeds, documents, lists — these already adapt by scrolling. Relocating them between regions interrupts continuity and gains nothing. Scrollable content is also exempt from fold avoidance generally; it's fine for it to pass under the curve.

Where things should move

Let purpose decide, and note that purpose changes with pose:

• Folded like a book — send transient things such as alerts to the trailing side, near where they will continue to appear as the device closes onto the outer display.
• Propped on a table — the top region is for content that reads at a distance; the bottom region is the stable surface, so tappable controls belong there.
• When several regions would work — pick the contextual one. A focused search field should stay over the view it is searching, adapting its width and position as the device folds, exactly as it stays over the keyboard on iPhone.

How things should adapt once moved

Position and size are the usual changes, but not the only ones. A split view can keep both columns visible by rebalancing to an even 50/50 split. A grid can hold its outer margins and simply widen the gap at the hinge, keeping every cell whole and inside one region.

The through-line: you are moving, resizing and reorganizing what is already there — never removing it. Every piece of content, every function, every layout stays reachable no matter how the device is being held.

Containers that adapt for free

Before writing any of this yourself, check whether a system container already does it:

• Navigation — NavigationStack, NavigationSplitView, TabView
• Content — List, ScrollView — with one caveat from Apple's reference: they don't split their rows around the fold, so a row can run across it. That's fine for continuously scrolling content (see displacement, above); where a row's controls end up in the curve, read the division and lay that row out yourself.
• Presentations — action sheets, alerts, menus, popovers all reposition themselves around reserved regions automatically

Arrangements

Between navigation containers and content containers sits a third kind: a layout container that arranges exactly two views by rule. That's an arrangement, new in iOS 27.1.

The rule is a function. Inputs: horizontal and vertical size class, the view's width-over-height aspect ratio, and whether any division region is currently active. Outputs: whether each view is shown at all, and what frame it gets.

Building one

In SwiftUI, put an ArrangementView inside your NavigationStack and give it a primary and a secondary view. In UIKit, use UIArrangementViewController as the root of a UINavigationController and assign view controllers to the .primary and .secondary placements.

The split style

The default. It divides the bounds between the two views, equally unless you say otherwise — side by side when the view is wider than tall, with the primary leading, and stacked when taller than wide, with the primary on top.

Constrain it when only one axis makes sense: apply .axes(.horizontal) to the split style. In UIKit, configure UISplitArrangement the same way and pass it to updateArrangement(_:animated:). That method and setViewController(_:for:animated:) both default animated to false, so pass true when the change should animate.

When the arrangement can't split along an axis — because you excluded it, or because a closed iPhone Duo is held in landscape — it shows only the primary view rather than producing a bad layout. Pick the primary with that in mind: it is the view that survives.

Size the panes when equal halves are wrong. In SwiftUI, put one of these on a view: splitArrangementLayoutRatio(_:) for a fraction of the container, splitArrangementLayoutSize(minWidth:idealWidth:maxWidth:…) for points, or splitArrangementFixedLayoutSize() to prefer the view's ideal size. The view with the higher layoutPriority gets what it asks for and the other takes the rest. In UIKit, give a placement a DimensionRange:

var split = UISplitArrangement.split
var primary = split.defaultViewProperties
var width = UISplitArrangement.DimensionRange()
width.minimum = .absolute(250)
width.preferred = .fractional(0.3)
primary.width = width
split.setViewProperties(primary, for: .primary)
arrangementController.updateArrangement(split, animated: true)

The payoff on this device: when the secondary view is dismissed, the primary doesn't recenter across the whole display the way it would on iPad. It stays inside the region the fold defines, so its controls stay reachable and clear of the curve.

The overlay style

Where split prefers side-by-side, overlay prefers stacking one view above the other — and moves them side-by-side when the device folds, which is exactly when the stacked view would otherwise get cramped.

Precisely: with no active division region — closed, or fully open — the primary view sits on top of the secondary. Once partially folded, the primary moves to the trailing or bottom region relative to the fold, and the secondary to the leading or top. That ordering is worth internalising before you pick which view is primary: the primary is the one that ends up where the thumb is, not the one that gets the larger area.

If the default side is wrong for your content, set it: overlayArrangementEdge(_:) on the view in SwiftUI, or edge on the overlay's view properties in UIKit, chooses which horizontal edge that view takes in landscape.

Because the relationship changes with the pose, you often want to change the subordinate view's presentation to match. Read the stacking state and adapt: in SwiftUI, the overlayArrangementZIndex environment value; in UIKit, state(for:) on the arrangement view controller and then its zIndex. A list that is collapsed while stacked can expand once it's given its own region.

Choosing between them

Follow the pattern the app already uses. Something built from HStack/VStack maps to split; something built from ZStack maps to overlay. Both translate directly and bring iPhone Duo support with them.

With no existing pattern to follow, ask what the relationship between the two views is:

• Foreground over background, where partial obscuring is acceptable — overlay. Controls floating over readable content that scrolls beneath them is the canonical case.
• Main and detail, where neither may ever be obscured — split. A player and its transcript is the canonical case.

When not to use one

• Arrangements provide no navigation infrastructure. Don't put a NavigationSplitView or a TabView inside one — in UIKit, a split view or tab bar controller.
• Don't nest an arrangement inside anything that lays out views itself: List, ScrollView, a grid, a collection view, or a split view.
• If you need expanding and collapsing column behavior, you want a real split view, not an arrangement.

A working order

1. Audit centered layouts. Would a two-column layout be better? If not, which displacement pattern applies?
2. Prefer system containers and presentations — most adaptation is free.
3. Where the app has a custom horizontal split or overlay, replace it with ArrangementView. You gain iPhone Duo behavior across every supported device, not just this one.
4. Only then, for the highest-priority manually positioned controls, adopt the reserved-region APIs and implement displacement by hand.

For hinge-driven interaction rather than layout, see ../iphone-duo-hinge-and-scenes/SKILL.md — live hinge angle is the wrong tool for laying out views, and the right one for driving effects.