Skip to content
Duo Support
Quote

Handle occlusion regions around the under-display camera

MajorNeeds iOS 27.1 SDKlayout

What you see

A button or a piece of text sits behind the inner camera and is partly hidden or hard to tap.

Division regions versus occlusion regions on iPhone DuoTwo diagrams. On the left, a division region — the hinge — runs across the display and splits it into two usable areas; it is active only while the device is folded and has zero width when flat. On the right, an occlusion region — the under-display camera — sits on top of one corner, covering content rather than dividing the screen.usableusableHINGEDivision regionsplits the area in twokind: .divisionone usable areaCAMOcclusion regioncovers, does not dividekind: .occlusion
A division region is active only while the device is folded and has zero width when flat, so your layout must handle it appearing and disappearing — not merely moving.

Reserved regions come in two kinds, and the distinction matters. A division region splits an area in two. An occlusion region sits on top of an area and hides what is under it. The under-display FaceTime camera on the inner display is an occlusion region.

The three reserved regions on iPhone Duo

Region When it is present What the system does
Outer front-facing camera Always Expands into the Dynamic Island for Live Activities; standard side controls account for it automatically
Inner front-facing camera Only while the camera is active Hidden when inactive; when it activates, the UI moves aside to show it is in use
Folding region Only while the device is partly folded Divides the inner display into separate usable areas

The inner camera is the one to plan for. Because it only appears while active, a layout that looks clear in every screenshot can still end up with a control underneath it the moment the camera turns on.

The API

GeometryReader { proxy in
    let regions = proxy.reservedRegions(kind: .occlusion)
    let frames = regions.map(\.frame)
}

Treat these frames the way you already treat the safe area: background and decorative content may pass beneath them, but anything the user needs to read or tap should be laid out clear of them.

// Background art may extend under an occlusion region
BackgroundArtwork()
    .ignoresSafeArea()

// Interactive content should not
ControlsView()
    .padding(.top, occlusionInset)

Why not just use the safe area?

The safe area already accounts for standard system furniture, and for most apps that is enough. Query occlusion regions when you are drawing your own full-bleed surface — a camera preview, a map, a canvas, a game — where you have deliberately opted out of the safe area and are now responsible for the geometry yourself.

Same as division regions, occlusion regions have active and inactive states, and options: .includeInactive returns the ones that are not currently in effect.

How to verify

Show a full-bleed screen on the inner display and check the area around the camera. Nothing tappable should be underneath it, and any text that passes near it should remain fully legible.

Applies to

← All checksFree evaluation