#How panes are arranged

Each platform follows its own conventions. iOS delegates arrangement to SwiftUI's ArrangementView. Android has no system equivalent, so the library applies Material's adaptive layout rules, the ones behind Compose's calculatePaneScaffoldDirective, to the window size and the fold that Jetpack WindowManager reports.

axes names the directions in which panes may be placed: "horizontal" is side by side, "vertical" is stacked. A split along an excluded axis never happens; the primary pane shows alone instead.

#iOS

• A half-open hinge splits the panes on either side of it, keeping 20 pt clear on each side of the crease.
• Otherwise the size classes decide. Side by side needs a regular horizontal size class and stacked a regular vertical one. When both are regular, the arrangement's longer side is halved. When both are compact, as on an iPhone in landscape, the primary pane shows alone.
• overlay puts both panes at full size, primary in front. A half-open hinge separates them, with the primary after the hinge: on the trailing side, or below it.
• In a split, primaryEdge sets the layout direction of SwiftUI's arrangement, the only control it has over the side. The panes keep the inherited direction. In an overlay, it sets the edge SwiftUI gives each pane.

#Android

• The window decides how many panes fit: two side by side from 840 dp wide, and never in a window under 480 dp tall, such as a phone in landscape, which Android's guidance considers too short for two panes. Two stacked fit in tabletop posture, or in a single-column window at least 900 dp tall.
• A hinge that hingePolicy avoids decides the axis, and the panes are separated by hingeGap centred on the crease. A half-open hinge splits the panes whatever the window size, as on iOS; a flat one only where two panes fit anyway. When the split doesn't fit, or axes excludes it, the primary pane shows alone on the side of the hinge primaryEdge names, leading by default, or above it.
• Otherwise the panes halve the arrangement and touch.
• overlay puts both panes at full size, primary in front. An avoided hinge separates them, as on iOS.
• Right-to-left layouts put the primary pane on the right, and primaryEdge sides are mirrored with them.

#The primary pane's side

Without primaryEdge, a split's primary pane is on the leading side and an overlay's goes after the hinge, on the trailing side. primaryEdge names the side instead, whenever the panes are side by side:

<ArrangementView style={{ flex: 1 }} primaryEdge="trailing">

primaryEdge="trailing" suits a book-style foldable in a left-to-right app: closed, its cover display sits over the right half of the inner one, so the content on the cover stays in place as the device unfolds, and the secondary pane opens beside it. Leading and trailing follow the layout direction, and stacked panes, such as in tabletop posture, are unaffected.

Stacked, a split's primary pane is always on top. An overlay's goes below the hinge, on the half that rests on the table in tabletop posture, unless primaryEdge names "top" or "bottom". To set both, pass the horizontal side, then the vertical one:

<ArrangementView
  style={{ flex: 1 }}
  arrangement="overlay"
  primaryEdge={['trailing', 'top']}
>

Screen readers go through the panes in reading order, whichever is primary: with the primary pane on the trailing side, or below, the secondary pane is read first.

#Where the platforms differ

See the platform comparison for screenshots of each posture and orientation.

#Fallback iOS only

When running below iOS 27.1 or building with an older SDK:

• split displays only the primary pane. The secondary React tree remains mounted but is outside the visible native hierarchy.
• overlay layers primary over secondary at full size.
• axes and primaryEdge have no effect. Hinge state remains unavailable.

Android has no fallback mode: a device without a fold is arranged as flat, and its hinge state is unavailable.