Safe area insets & layout margins

iPhone Duo safe-area reference values

The table compares the outer display in closed portrait with the inner display fully open in Landscape Left. Layout dimensions and insets use points; hardware dimensions use pixels. A window with different bars, orientation or available space may have different usable regions.

Apple’s hardware specifications list the inner panel as 1878 × 2670 pixels in portrait, transposed here for landscape. The outer-portrait layout values were rechecked against safearea.info on October 4. The inner layout column retains the September 23 third-party reference snapshot; its dynamic state was not available for a fresh check.

Do not infer panel resolution by multiplying a design frame by a reference scale. The 951 × 669 pt inner layout reference is not a new measurement or a claim about Apple’s physical pixel grid. No concrete Figma file or layer was verified for this table.

What are the iPhone Duo safe area insets?

Use the numeric table as a starting reference for its stated configurations. Apple describes iPhone Duo safe areas and layout margins as frequently asymmetric; standard system containers and custom app layouts can reserve different amounts of space.

For UIKit, read UIView.safeAreaInsets or use the safe-area layout guide. In SwiftUI, content respects the safe area by default unless you intentionally extend it. Treat each edge independently instead of mirroring a value to the opposite side.

Safe area and reserved regions solve different problems

SwiftUI and UIKit expose reserved-region information for content that needs to avoid a camera or an active fold. Read it separately from safe-area insets when laying out custom controls.

The adaptive-layout talk distinguishes division regions, such as an active fold that separates usable regions, from occlusion regions such as cameras. A fold can be known even when inactive; its active frame changes with the device state.

Measure safe-area insets in your app

To check the values inside your own app, read them after the view is visible and laid out. This small example reports the insets and usable view frame.

let insets = view.safeAreaInsets
let usableFrame = view.bounds.inset(by: insets)

print("safeArea", insets)
print("usableFrame", usableFrame)

WKWebView and CSS safe-area values

WebKit documents viewport-fit=cover together with env(safe-area-inset-top), env(safe-area-inset-right), env(safe-area-inset-bottom), and env(safe-area-inset-left) for edge-to-edge web layouts. Those variables describe the web rendering environment, not a universal iPhone Duo constant.

In a hybrid app, first establish whether the native WebView container already respects a safe area. Adding the same inset in native layout and CSS can double-compensate. VisualViewport can help diagnose visible viewport changes, but it should not be treated as the source of native safe-area geometry.

.edge-aware {
  padding-top: max(16px, env(safe-area-inset-top));
  padding-right: max(16px, env(safe-area-inset-right));
  padding-bottom: max(16px, env(safe-area-inset-bottom));
  padding-left: max(16px, env(safe-area-inset-left));
}

Layout margins and reference scope

Layout margins describe content spacing; safe-area insets and reserved regions describe different constraints. Do not turn a margin shown in an unspecified design file into a universal device rule. Record the exact kit version, frame or layer, and original source before adopting a precise margin value.

Compare sources only for the same display, orientation, window and system-container configuration. For cases not listed here, measure the app’s current layout values. Apple’s design-resource directory identifies starting materials, but the directory alone does not verify the contents of a particular Figma layer.