Adapting to Orientation, Safe Areas, and Notches

Why orientation and safe areas change your layout

Orientation changes (portrait vs. landscape) and device-specific “unsafe” regions (status bars, navigation bars, camera notches, rounded corners, gesture indicators, fold hinges) can cause UI elements to become clipped, overlapped, or hard to reach. A layout that looks correct on a simulator without a notch can fail on a real device with a cutout, or when rotated into landscape where the notch moves to the side. “Safe areas” are the system-provided insets that define where content can be placed without being obscured by system UI or hardware features. Your job is to ensure that essential content and interactive controls stay inside safe areas, while allowing non-essential visuals (like background images) to extend behind system bars when appropriate.

Two common mistakes lead to problems: placing controls at absolute screen edges (so they collide with notches or gesture areas), and treating orientation as a separate screen design (so you duplicate layouts and introduce inconsistencies). Instead, treat safe areas and orientation as constraints/insets that your layout responds to. You should also distinguish between “content” (text, buttons, inputs) and “decorative surfaces” (backgrounds, hero images). Content usually respects safe areas; decorative surfaces can often ignore them.

Key concepts: safe areas, insets, and cutouts

Safe area vs. full screen

Full screen is the physical display rectangle. The safe area is the region where the system guarantees your content won’t be covered by system UI or device cutouts. On many phones, the top safe inset accounts for the status bar and notch; the bottom safe inset accounts for the home indicator/gesture area. In landscape, left/right insets may appear because the notch becomes a side cutout.

Insets you should care about

• Top inset: status bar, notch/camera cutout.
• Bottom inset: home indicator, gesture navigation bar, system UI overlays.
• Left/right insets: rounded corners, side cutouts in landscape, fold/hinge areas on some devices.
• Keyboard inset: when the keyboard appears, it changes the usable area; treat it similarly to a temporary safe area change.

Safe area is not just padding

Safe area insets are dynamic. They can change when rotating, when entering split-screen/multi-window, when system bars show/hide, during calls (in-call status bar), or when picture-in-picture overlays appear. Don’t hardcode a single padding value. Use platform APIs that provide current insets and update your layout when they change.

Orientation: what really changes

Orientation affects more than width and height. It changes how users hold the device, where thumbs rest, and how much vertical space is available for stacked content. In portrait, vertical scrolling is common; in landscape, vertical space is limited and horizontal space is abundant. The safe area insets can also shift: a notch that was at the top in portrait becomes a left or right inset in landscape.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Rather than creating a completely different UI for landscape, start by making your layout flexible: allow containers to reflow, allow toolbars to compress, and prioritize content. Reserve dedicated landscape layouts for cases where the interaction model truly benefits (e.g., a video editor timeline, a map with a side panel, a tablet master-detail view).

Practical workflow: make a screen safe-area aware

Step 1: Identify “must be safe” elements

List the elements that must never be obscured: primary navigation controls, back button, primary call-to-action, form fields and their labels, error messages, and any content that must be readable (prices, totals, confirmation text). These elements should be constrained to the safe area.

Step 2: Identify “can bleed” elements

Background colors, gradients, images, and large decorative headers can extend into unsafe regions to create an immersive look. If you do this, ensure that any text or buttons placed on top still respect safe insets. A common pattern is a full-bleed background image with a safe-area-aligned content overlay.

Step 3: Apply safe area constraints at the right level

Apply safe area padding to the container that holds your interactive content, not to every individual element. This keeps spacing consistent and reduces bugs. For example, wrap your screen content in a “SafeAreaContainer” that reads insets and applies padding, while allowing a background layer to ignore insets.

Step 4: Test the extremes

Test on: a device with a notch, a device without a notch, gesture navigation vs. 3-button navigation (Android), landscape rotation, and a small phone. Also test with large text accessibility settings and with the keyboard open. Safe areas and orientation issues often appear only in these extremes.

Implementation patterns (platform-agnostic)

Pattern A: Full-bleed background + safe content overlay

This pattern gives you modern, edge-to-edge visuals while keeping controls safe. Structure your screen into two layers: a background layer that fills the entire screen, and a content layer that is padded by safe insets.

// Pseudocode layout tree (platform-agnostic) Screen {   Layer(background) {     FillEntireScreen()     BackgroundImageOrColor()   }   Layer(content) {     Padding(safeInsets)     Column {       TopBar()       MainContent()       BottomActions()     }   } }

Key detail: the background ignores safe insets; the content respects them. If you place text on the background (e.g., a title over a hero image), that text belongs in the content layer, not the background layer.

Pattern B: Safe-area-aware bottom action bar

Bottom buttons are frequently blocked by the home indicator or gesture bar. Make the bottom bar sit above the bottom inset, and optionally add extra spacing so it’s comfortable to tap.

// Pseudocode for bottom actions BottomBar {   Padding(left: 16, right: 16, top: 12, bottom: safeInsets.bottom + 12)   PrimaryButton() }

This ensures the button never touches the very bottom edge on gesture devices. If you also have a scroll view above it, ensure the scroll view’s content inset accounts for the bottom bar height plus safe inset so the last items aren’t hidden behind the bar.

Pattern C: Scroll content with dynamic insets

Scrollable screens often fail when the last input field is hidden by the home indicator or keyboard. Use dynamic content insets: top inset for the status bar/notch, bottom inset for the bottom bar and system gestures, and additional inset when the keyboard appears.

// Pseudocode for scroll view insets ScrollView {   ContentPadding(top: safeInsets.top, bottom: safeInsets.bottom + bottomBarHeight)   OnKeyboardChange(keyboardHeight) {     SetExtraBottomInset(keyboardHeight)   } }

When the keyboard opens, scroll the focused field into view. This is not only about insets; it’s also about focus management so the user can see what they’re typing.

Orientation handling: step-by-step adaptation

Step 1: Decide what should reflow vs. what should resize

When rotating, you typically want one of these behaviors:

• Reflow: components rearrange (e.g., a vertical stack becomes a horizontal row).
• Resize: components keep their order but adjust sizes (e.g., a chart becomes wider, text wraps less).
• Reveal more: landscape shows additional panels (common on tablets).

Pick one per screen. Mixing all three without a plan leads to unpredictable layouts.

Step 2: Use breakpoints based on available size, not orientation labels

Orientation is a proxy for available width/height, but it’s not reliable on foldables, tablets, or multi-window modes. Instead of “if landscape then…”, use “if width > X then…”. This makes your UI robust in split-screen where you might be “portrait” but still wide, or “landscape” but narrow.

// Pseudocode breakpoint logic if (availableWidth >= 600) {   UseTwoColumnLayout() } else {   UseSingleColumnLayout() }

Even if your platform provides an orientation flag, prefer size-based decisions for layout structure.

Step 3: Reposition navigation and actions thoughtfully

In landscape on phones, vertical space is scarce. Consider these adaptations:

• Move secondary actions into an overflow menu.
• Use a compact top bar height if the platform supports it.
• For media screens, allow immersive mode but keep essential controls within safe areas.

Do not shrink tap targets below recommended sizes to “make it fit.” Instead, reduce non-essential chrome or allow scrolling.

Step 4: Recalculate safe insets after rotation

Safe insets can change dramatically after rotation. For example, a notch becomes a left inset in landscape, which can push a left-aligned back button too close to the cutout if you ignore it. Ensure your layout listens for inset changes and recomputes padding/constraints accordingly.

Notches and cutouts: practical design rules

Rule 1: Never place critical icons in the cutout zone

Even if the system reports a safe area, custom drawing or full-bleed toolbars can accidentally place icons under the notch. Keep navigation icons and titles inside the safe area bounds. If you use a custom header, explicitly apply top and horizontal safe insets.

Rule 2: Treat landscape cutouts as left/right insets

Many teams only think about top/bottom safe areas. In landscape, the unsafe region may be on the left or right. This affects side drawers, edge swipe gestures, and horizontally aligned toolbars. Apply left/right safe padding to headers and footers, not just top/bottom.

Rule 3: Avoid “centered title under notch” illusions

When a notch exists, visually centering a title across the full screen can make it appear off-center relative to the safe area. Prefer centering within the safe area width, or align the title with the main content column. This keeps the title aligned with what the user perceives as the usable space.

Rule 4: Background images can extend, but gradients need care

Full-bleed images are usually fine behind the status bar. Gradients and overlays can create readability issues if the status bar icons (time, battery) sit on top. Ensure sufficient contrast where system icons appear. If your platform allows, choose status bar icon color (light/dark) based on the background brightness in that region.

Safe areas with navigation bars and gesture areas

Bottom gesture indicator overlap

On gesture-based systems, the bottom area is reserved for system navigation gestures. If you place a button too low, users may trigger the system gesture instead of tapping your control. Always add bottom padding equal to the safe inset plus a small comfort margin for primary actions near the bottom.

Android navigation modes

Android devices can use gesture navigation or 3-button navigation. The bottom inset differs between modes and can change at runtime if the user switches settings. Rely on window insets rather than assuming a fixed navigation bar height.

Edge-swipe gestures and side content

Some systems use edge swipes for back navigation or system panels. Even if the area is “safe” visually, placing critical horizontal swipe interactions at the extreme edge can conflict with system gestures. Provide a small internal margin for horizontally draggable elements, or start drags from within the content area rather than the very edge.

Keyboard and orientation: keeping forms usable

Forms are where safe areas and orientation problems become obvious. In landscape, the keyboard can consume most of the height, leaving only a narrow strip for content. Combine these techniques:

• Scroll-to-focus: when an input gains focus, scroll it into view above the keyboard.
• Sticky actions: keep the primary action (e.g., “Continue”) visible above the keyboard when possible, but ensure it respects the bottom safe inset.
• Reduce non-essential elements: collapse helper text or hide decorative headers while typing in landscape.

// Pseudocode: focus handling on input focus OnFocus(input) {   ScrollView.ScrollToMakeVisible(input, extraOffset: 12) } OnKeyboardChange(height) {   ScrollView.SetBottomInset(height + safeInsets.bottom) }

Be careful not to double-apply insets (e.g., adding safeInsets.bottom and also a system-provided keyboard-safe inset that already includes it). If your framework provides a combined “system bars + keyboard” inset, prefer that single source of truth.

Common pitfalls and how to avoid them

Pitfall: Hardcoded padding values

Hardcoding “paddingTop: 44” might look correct on one iPhone model but fail on others, and it will be wrong on Android. Use system insets. If you need additional spacing for aesthetics, add it on top of the safe inset (safeInset + designPadding).

Pitfall: Applying safe padding to the entire screen including backgrounds

If you apply safe padding to the root container, your background may no longer be edge-to-edge, causing visible gaps near rounded corners or status bars. Separate background and content layers so only content is padded.

Pitfall: Ignoring left/right insets

Landscape notches and rounded corners can clip side-aligned controls. Always apply horizontal safe insets to headers/footers and any edge-aligned interactive elements.

Pitfall: Overlapping fixed headers/footers with scroll content

If you have a fixed bottom bar, the scroll content must have enough bottom padding so the last item can scroll above the bar. Otherwise, content appears “cut off.” Compute this padding as bottomBarHeight + safeInsets.bottom.

Pitfall: Layout jumps on rotation

When rotating, some screens briefly render with old insets then update, causing a visible jump. Mitigate by responding to size/inset changes in a single layout pass when possible, and avoid animations that amplify the jump. If your framework supports it, batch updates or use a layout transition that feels intentional.

Testing checklist for orientation and safe areas

• Rotate portrait ↔ landscape on a notched device and verify headers, back buttons, and titles remain fully visible.
• Check bottom actions on gesture navigation: buttons should not sit on the home indicator area.
• Open the keyboard on the last input field; ensure it scrolls into view and the primary action remains reachable.
• Test with system font size increased; verify that safe-area padding still leaves enough space and nothing is clipped.
• Test in split-screen/multi-window (where available) to validate size-based breakpoints.
• Verify that decorative backgrounds can extend edge-to-edge without pushing content into unsafe areas.