Safe areas differ across device forms
Aliases: form-factor inset · live safe area · hinge placement
What it is
A floating primary is hard-coded “16 from the bottom”. On a short Home-button phone it sits cleanly; on a fullscreen phone it sits in the indicator; on a foldable mid-state it may sit in the hinge gap; on three-button Android it fights Back. Safe areas vary with form means the legal landing for a tappable control is not one coordinate across devices. It is a live region each form declares. Copying a point that was safe on one prototype onto every device will, on another, send the primary into an untappable or mis-tap band.
The claim is that interactive landings follow form. It is not how a notch crops the picture, or whether a background paints past the screen — those are a different layout-system rule.
Why it happens
A safe area is the system’s statement of which pixels, on this form, may be treated as a stable hit region. Inputs are rounded corners, punch-holes, the indicator, a hinge, a three-button bar; the output is an inset that moves with the device. An app that writes button coordinates on an artboard is ignoring those inputs. Change the form, the system’s statement at the same physical place changes, the button stays on the old coordinate, and it is either cropped out of reach or poked into a gesture band.
Folds, external displays and desktop windowing change form in flight. A safe area is not a constant read once at launch. It is an event re-sent on rotate, fold and split view. Landings have to follow that event, not a first-layout calculation.
Where it stops holding
A single SKU whose form never changes can treat the safe area as a constant. Decorative backgrounds and full-bleed images are not “tappable landings” and may paint past the inset. A desktop window under a mouse has no indicator and no punch-hole; the safe area degenerates to window padding and this form difference almost vanishes. The Web, on old browsers that cannot read system insets, can only give a conservative floor — extra gap rather than assuming a punch-hole is absent.
Applying it
- Primary buttons, tab bars and gesture hot zones follow the system inset. Do not hard-code pixels-from-bottom or pixels-from-side.
- Cover at least, in a device matrix: short Home-button, fullscreen indicator, three-button nav, unfolded foldable, landscape. On each, check that the same primary still sits inside the declared safe area.
- Listen for inset changes from rotate, fold and split view, and re-place fixed controls; do not compute once on a cold start.
- How to check: a press-frame of the same primary on every device in the matrix. If the hit target falls into the indicator, the hinge, a punch-hole or the three-button bar on any one, the coordinate was still copied from a single prototype.