Size classes, safe areas and standard containers

The fastest way to a good iPhone Duo layout is to write less iPhone Duo code. Size classes tell you how much room you have, safe areas tell you where it’s safe to put controls, and the system containers already know how to move between the two displays.

Size classes on iPhone Duo

Read them from the environment in SwiftUI or the trait collection in UIKit:

// SwiftUI
@Environment(\.horizontalSizeClass) private var horizontalSizeClass
@Environment(\.verticalSizeClass) private var verticalSizeClass

// UIKit
traitCollection.horizontalSizeClass
traitCollection.verticalSizeClass

Two consequences:

• Regular width is no longer iPad. On the inner display, your iPhone app gets the size classes your iPad layout was written for. Apple’s guidance is that the inner display should look like a natural extension of your iPad layout, so if you already have one, let it run.1
• Size classes change mid-session. Opening the phone is a trait change, not a relaunch. In hybrid apps, observe traits on both sides of UIHostingController and UIViewRepresentable so UIKit and SwiftUI views agree.4

If you have room for it, support landscape on the outer display: Apple expects people to stand the phone up like a tent.1

Use standard containers

These adapt to every pose with no extra work:

• Split views. NavigationSplitView and UISplitViewController collapse to one stack when closed and tile or overlay their columns when open.
• Tab views. TabView and UITabBarController appear on both displays and lay out vertically when appropriate.
• Navigation stacks. NavigationStack and UINavigationController get the new vertical bars. See Vertical toolbars and tab bars.
• Presentations. Sheets, popovers, context menus and alerts reposition themselves. Sheets are centered on the inner display; you can request leading or trailing placement with presentationPlacement(_:) or preferredPlacement.1

To give the inner display a sidebar instead of a tab bar, opt in:

// SwiftUI
TabView { /* ... */ }
    .defaultTabBarPlacement(.sidebar)

// UIKit
tabBarController.sidebar.preferredPlacement = .sidebar

Apple’s engineers point out that a sidebar-adaptable tab view doesn’t become a sidebar on iOS by default, so you need this line.3

Respect the safe area, on each side separately

On iPhone Duo, standard bars lay out outside the safe area and avoid the status bar and camera on their own. Horizontal bars contribute top and bottom insets; vertical bars contribute leading or trailing insets.

• Foreground content (anything interactive) stays inside the safe area. SwiftUI does this by default. In UIKit, use safeAreaInsets or the safeAreaLayoutGuide.
• Background content such as full-bleed artwork may extend behind bars: .ignoresSafeArea() in SwiftUI, view.bounds in UIKit.

The trap is symmetry. Safe areas and layout margins on iPhone Duo are often asymmetric: a vertical bar can sit on the left in landscape or in Split View, and the opposite side gets a different inset.1

// Avoid: assumes opposite insets are equal
let width = view.bounds.width - view.safeAreaInsets.left * 2

// Prefer: handle each side independently
let width = view.bounds.inset(by: view.safeAreaInsets).width

Test this by putting your app into Split View on the inner display in Device Hub, then dragging it by the home indicator to the other side. Vertically laid-out bars can appear on either side.3

Match the screen corners

iPhone Duo has new display shapes.1 If you draw rounded containers near the screen edge, use the concentricity APIs from iOS 26, which are updated for iPhone Duo:

// SwiftUI
ConcentricRectangle()
    .fill(Color.green)
    .padding(8.0)
    .ignoresSafeArea()

// UIKit: UICornerConfiguration

When safe areas aren’t enough

For custom edge-to-edge UI, like your own bottom sheet or a hand-built bar, iOS 27.1 adds reserved regions: the frames of the hinge and camera areas that system UI already avoids.2 They’re covered in Hinge, poses and adaptive layouts.

Accessibility still applies

Support Dynamic Type at every pose. Apple’s engineers note that non-scrolling layouts should reflow at accessibility sizes rather than cap text at the largest standard size, and that custom layouts spanning the hinge may need explicit accessibility containers or sort priorities to keep VoiceOver order sensible.3 Standard containers handle that for you.