Prompt
Use SafeAreaView to render content that respects the safe area insets on notched devices. Include a header bar and scrollable content below it.
Solution
Safe areas exist because modern screens aren't rectangles you can draw on edge to edge: notches, Dynamic Islands, home indicators, and Android display cutouts all overlap the viewport, and content behind them is unreadable or untappable. SafeAreaView pads its children into the unobstructed region.
The trap that makes this an interview question: core SafeAreaView from react-native is iOS-only — on Android it renders as a plain View, so shipping it as your cross-platform answer puts Android content under the status bar or cutout. The production answer is react-native-safe-area-context: wrap the app in SafeAreaProvider and use either its SafeAreaView or, better, useSafeAreaInsets(). Insets-as-numbers beat a wrapper component because they compose — add them to a tab bar height, feed them into an animated header — and the library delivers them synchronously on first render via initialWindowMetrics, avoiding the flicker core SafeAreaView can show during navigation transitions and inside modals.
The layout structure here is the other half: the header sits inside the safe area at fixed height; the ScrollView takes remaining space, with padding on contentContainerStyle (the content), not the scroller itself. And apply insets per-edge at screen level — top on headers, bottom on footers — not blanket padding, or scrollable content loses its full-bleed look. That matters more as Android pushes apps toward edge-to-edge rendering.
Red flag: presenting core SafeAreaView as the cross-platform solution. Name the safe-area-context library unprompted.
Say it: "Core SafeAreaView is a no-op on Android — I standardize on safe-area-context's provider plus useSafeAreaInsets, because composable inset numbers work per-edge and cover Android cutouts."