Status-bar occlusion is a common layout miss

What it is

When an app paints to the full window, the system status bar, notch, island, rounded corners, and home indicator sit on top of content; they are not another row in the layout. Forgetting to yield tappable and readable objects to the safe area (insets) puts a close control under the island, a first-row title into the clock, a landscape cutout through Back. That is a layout miss: system chrome already spent those pixels and the app still treats them as its own. This entry is only about occlusion and yielding. It is not about refusing to draw a fake status bar, and not about notifications as an entry.

Why it happens

The window’s root size is the whole glass. System chrome is an overlay whose height also changes: an in-call or hotspot bar doubles the status strip, the keyboard rewrites the bottom inset, rotation moves a cutout from the top to a side. A layout that reads “status bar height” once at launch will not yield to later changes. After leaving immersive full screen, if insets are not restored, a temporarily hidden top bar lands on a close button still pinned to the top. Edge-to-edge backgrounds are usually fine—they were going to be covered anyway. Text and hit targets on the same coordinates are not: the covered part cannot be read or tapped. The miss is common because desktop previews and un-notched daily flagships never put the failure in front of you; it travels with notched bodies and taller status bars.

Studying it

Code occlusion: screenshot key screens on hardware, paint system chrome as a translucent region, and mark intersections with text, icons, and hit targets. Rotate, show the keyboard, turn on hotspot, and code again.

Independent variables: whether safe-area insets are applied, notched versus un-notched, taller status bar, portrait versus landscape. Dependent variables: number of intersected controls, untappable close or back, clipped primary titles, task failures before versus after a fix.

Simulator safe areas that disagree with real corner radii and island shape miss rim hit failures. Do not substitute “looks uncovered” for a tap test—the hit region may be larger than the icon, so a tap beside the visible glyph still lands in chrome. Automated screenshots must match system appearance or dark chrome on dark content will be under-coded.

Where it stops holding

Maps, photos, and video canvases may go to the rim on purpose if interactive controls stay inside the safe area. Captions and scrubbers that sit on the bottom still need the home-indicator inset or the gesture strip covers them on edge-to-edge phones. A desktop window has no such overlay. Immersive full screen that hides the status bar has no occlusion during the hide; the miss clusters at the moment of exit.

Applying it

• Constrain text, close, back, and primary buttons to the safe area; backgrounds and ornament may paint full-bleed.
• Listen for inset changes: taller in-call bar, keyboard, rotation, leaving immersive—yield again each time, rather than computing once on the first frame.
• In landscape treat left and right cutouts as the new top and bottom; do not ship only a portrait top inset.
• Verify on a notched or island device with a debug translucent chrome overlay, through every sheet and first screen on the main path. Any tappable target or primary text intersecting chrome is a miss. Turn on personal hotspot or an incoming call and watch whether the first row is eaten by the taller status bar.

Related

• Within the group: K1.05.1 The status bar is system territory; apps must not fake it · K1.05.2 Notification Center is a second entry from outside the app
• Adjacent: F1.12 Fixed Elements and Safe Areas · F2.12 Safe Areas and Irregular Screens · K1.06 Widgets and Lock-screen Entry Points
• Search terms: safe area · display cutout · layout inset