iPhone Duo and the Safe-Area

I took a screenshot of the Safety Area's and Occlusions on the iPhone Duo outer display.

The article Designing for iPhone Duo tells us to...

Consider using the full display width for interfaces where bars aren’t necessary. Some layouts can span the full display, which works well for visual, immersive interfaces that don’t scroll, as long as nothing conflicts with the Dynamic Island or the status bar. Calculator, for example, occupies the full width of the display. You can also combine both approaches, letting a background image or header span the full width while scrollable content stays inset.

The Graphics Content can easily take up the full space which can be achieved by ignoring the safe area (.ignoresSafeArea()). And knowing the iPhone Duo there is no occlusion so I can also ignore the safe area for the interactable content.

However we now are entering an awkward state. Because now I need to make decisions based on a specific device. Knowing the iPhone Duo I can ignore horizontal safe area and expand to full width because there is no occlusions here, but ignoring the safe-area may result in unexpected behavior on other (future) devices which then requires me to use code that specificly targets certain devices.

I wished SwiftUI had something that I could safely expand the interactable content the full width.

Answered by DTS Engineer in 906841022

Hello @crystalminds,

I wished SwiftUI had something that I could safely expand the interactable content the full width.

Rather than checking for a specific device before ignoring the safe area, you can query the live occlusion regions and lay out around whatever is actually reported, so the same code adapts as device geometry changes:

GeometryReader { proxy in
    let occlusions = proxy.reservedRegions(kind: .occlusion)

    YourContent()
        .ignoresSafeArea()
    // Avoid only the specific region(s) the query reports,
    // rather than an entire edge's safe area.
}

Worth noting, on iPhone Duo the occlusion array won't be empty, since the outer camera's region is "always present, and expands into the Dynamic Island for Live Activities." But that frame is scoped to the corner, not a full-width band — so you can still go full width and just inset around it. The same code holds up on devices with no occlusion at all (empty array) and on whatever a future device reports.

For more, see Strike a pose with adaptive layouts on iPhone Duo, which covers reservedRegions in both SwiftUI and UIKit.

I hope this information is helpful.

 Travis

Hello @crystalminds,

I wished SwiftUI had something that I could safely expand the interactable content the full width.

Rather than checking for a specific device before ignoring the safe area, you can query the live occlusion regions and lay out around whatever is actually reported, so the same code adapts as device geometry changes:

GeometryReader { proxy in
    let occlusions = proxy.reservedRegions(kind: .occlusion)

    YourContent()
        .ignoresSafeArea()
    // Avoid only the specific region(s) the query reports,
    // rather than an entire edge's safe area.
}

Worth noting, on iPhone Duo the occlusion array won't be empty, since the outer camera's region is "always present, and expands into the Dynamic Island for Live Activities." But that frame is scoped to the corner, not a full-width band — so you can still go full width and just inset around it. The same code holds up on devices with no occlusion at all (empty array) and on whatever a future device reports.

For more, see Strike a pose with adaptive layouts on iPhone Duo, which covers reservedRegions in both SwiftUI and UIKit.

I hope this information is helpful.

 Travis

Accepted Answer

toolbarVerticalCompressionBehavior(_:) discussed in Raise the bar with iPhone Duo answered the full display width question I had. For anyone reading along.

iPhone Duo and the Safe-Area
 
 
Q