A layout that looks correct on one simulated iPhone size has passed almost no useful test. Text can expand, split-screen contexts can narrow the available width, and iPhone Mirroring can present a resizable window. The question is not whether a view fits the device you started with. It is whether the view continues to communicate its hierarchy when the space changes.
Device Hub in Xcode 27 turns that review into a short, repeatable pass. It provides a shared place to work with simulators and physical devices, including environment controls, live interaction, and a resize mode for a simulated iPhone screen.
Use resize mode to expose layout assumptions
Resize mode is useful because it removes the comfort of named devices. Run the app, enter resize mode in the Device Hub canvas, then drag a side or enter dimensions. Device Hub snaps the screen to a valid size, which makes it practical to probe narrow, wide, short, and tall states without rebuilding a matrix of simulators.
For each important screen, test at least these situations:
- the narrowest width where the primary action must remain visible;
- a short height where a keyboard or a sheet competes with the content;
- a wide shape where fixed-width content can look stranded;
- a size between common device classes, where an implicit breakpoint is likely to fail.
The goal is not to eliminate every line wrap. It is to check that controls remain reachable, reading order still makes sense, and the layout does not turn a temporary size into a permanent state decision.
Make flexible space a deliberate choice
The resize pass often reveals a view that has hard-coded a width or made a GeometryReader value responsible for too much of the layout. Prefer the SwiftUI layout system when it already expresses the relationship you need.
struct EmptyState: View {
var body: some View {
ContentUnavailableView {
Label("No saved searches", systemImage: "magnifyingglass")
} description: {
Text("Save a search to find it quickly later.")
} actions: {
Button("Create Search", action: createSearch)
.buttonStyle(.borderedProminent)
}
.padding()
}
}The content can wrap and the button can retain its intrinsic size. If a custom view must switch arrangement, use available width as a signal for that local choice, not the device idiom. A view that only understands "iPhone" and "iPad" will be surprised by a resizable iPhone window.
Change environment settings before calling the UI done
Device Hub’s inspector can change conditions such as appearance, text size, contrast, orientation, and other simulated-device settings. Make those checks part of the same pass as resizing, rather than a separate accessibility cleanup at the end.
A practical sequence is:
- Start at the default environment and verify the core task.
- Increase text size and look for clipped labels, truncated button titles, and accidental fixed heights.
- Turn on dark appearance and increased contrast, then check custom colors and selected states.
- Resize again with the accessibility setting still active.
Testing combinations matters. A layout that handles a large type size at the device's default width can still fail when it is both narrow and scaled up.
Treat physical devices as the final interaction check
Device Hub presents simulators and paired physical devices in the same workflow, but a simulator remains an approximation. Use it to explore sizes and repeat environment changes quickly. Then run the actual task on hardware for gestures, keyboard behaviour, rendering, and any input path that depends on the device.
Apple’s release notes also call out Device Hub behaviours that differ from physical pointer input. When pointer accuracy matters, validate it with the appropriate hardware configuration or the recommended testing path, not only a simulated interaction.
Key takeaway
Resize mode is not a way to collect screenshots at arbitrary dimensions. It is a way to find assumptions your layout never stated. Combine it with text-size and appearance checks, then fix the ownership of space rather than patching each device size.