From Size Class to Available Space: Is horizontalSizeClass Still Reliable?

Starting with WWDC 26, when an iPhone app is mirrored to a Mac through iPhone Mirroring, its window can be freely resized. At the same time, iPhone-only apps running on iPad will also enter a resizable environment. Even without updating a physical device to a beta system, developers can already experience this change through Xcode 27 previews or the iOS 27 simulation environment in Device Hub.

However, the impact of this update goes far beyond simply making iPhone app windows resizable. It is changing how many developers have long understood the layout system. Some traits that were commonly used as layout inputs in the past, such as horizontalSizeClass, are no longer suitable as the primary basis for determining window width.

So is this change a sudden shift, or the inevitable result of Apple’s long-term evolution of its layout system? This article explores that question.

My iPhone App Got Ugly

Recently, I have been refactoring an old project of mine, rewriting the entire app with newer programming ideas and APIs.

After seeing the resizable iPhone app behavior shown at WWDC 26, I immediately tested how my own app behaved in this scenario. Since the app had already reserved adaptation logic for iPhone, iPad, and macOS, I originally assumed that after stretching the window width in Device Hub, the existing adaptive layout would be enough to handle the change.

But to my surprise, NavigationSplitView did not switch from a single-column layout to multiple columns, and the Tab-related components also did not transform into the expected presentation.

After checking the environment’s horizontalSizeClass, I found that no matter how the window size changed, it always remained compact.

However, when the app runs on iPad with the pad idiom, horizontalSizeClass still changes within a certain range as the window size changes. If the iPad device family is removed and the app runs on iPad in iPhone-only compatibility mode, its behavior becomes much closer to that of the iPhone host in Device Hub.

At first, I suspected this was an unresolved issue in Beta 1. It was not until I watched the WWDC 26 session Modernize your UIKit app that I realized this was actually an intentional design decision by Apple.

This Is Not a Beta Bug: The New Contract from WWDC26

In Session 278, Modernize your UIKit app, Apple explicitly brings iPhone apps into the dynamic sizing environment:

• In iPhone Mirroring on Mac, the iPhone window can be freely resized.
• iPhone-only apps running on iPad also enter a resizable environment.
• Apps should adapt to arbitrary scene sizes at runtime instead of assuming a fixed device aspect ratio.
• UIScreen.main and screen bounds are no longer reliable. Developers should use the effective geometry of the window scene, or the actual available size of the view or superview.
• userInterfaceIdiom is no longer suitable as a basis for layout decisions.
• iPhone apps running on iPad or in Mac mirroring may still run under the phone idiom, which means phone idiom is no longer equivalent to a narrow-screen layout.
• Orientation is no longer reliable either. In a resizable environment, supported orientations are closer to preferences; even if the window’s aspect ratio changes, the system may still maintain portrait orientation.
• For precise layout control, surrounding view size should be used first.

This explains the counterintuitive behavior I encountered earlier: even after the window was made wider, horizontalSizeClass in the iPhone host could still remain compact.

This is not a beta bug. It is the result of Apple intentionally separating “host semantics” from “available geometric space.”

Is horizontalSizeClass Still Reliable?

The answer is: yes.

But what it reliably expresses is the coarse-grained semantics of the current trait environment, not the window width itself.

This may be one of the easiest things to misread this year. A wider window in an iPhone host does not mean the system will necessarily switch horizontalSizeClass to regular. Conversely, even a relatively narrow iPad window may produce very different trait results depending on its idiom, scene, presentation, or container environment.

For developers, the truly important change is not that “iPhone has become iPad,” but rather:

• userInterfaceIdiom: only describes the host semantics under which the app is running. It should no longer be used as a basis for layout decisions.
• horizontalSizeClass: is the system’s coarse-grained contextual judgment of a trait environment, not a continuous width sensor.
• The geometry of a view or scene is the more precise basis for layout when dealing with arbitrary window sizes, changing aspect ratios, floating windows, and mirroring scenarios.

Therefore, horizontalSizeClass is still suitable for expressing system container semantics, such as whether menus should collapse or whether system Tabs or Sidebars are available. But for an app’s own layout breakpoints, such as “switch to a two-column layout after a certain width” or “show side navigation,” the decision should be based on the actual available size of the current root view, container view, or scene.

From Device to Scene, from Orientation to Available Space

If we only look at WWDC 26, this change can easily be understood as a new problem introduced by iPhone Resize.

But if we connect the dots from the past several years, we can see that Apple has actually been moving in the same direction all along: continuously reducing the importance of “device type + screen orientation” as the basis for layout decisions, and gradually guiding developers toward scene, trait hierarchy, and available space.

• 2014: Apple introduced Size Class in iOS 8. This year, Session 278 once again emphasized the same design idea: device rotation is essentially just a bounds change.
• 2019: iPad multiwindow and UIScene broke the traditional assumption that “one app has only one UI instance.” A scene began to have its own lifecycle, state restoration, screen, and geometry information.
• 2022: The Desktop-Class iPad updates in iPadOS 16 pushed iPad interfaces further away from being merely “enlarged iPhone apps” and toward denser, more desktop-like productivity interfaces, laying the foundation for later variable-space design.
• 2023: The session Unleash the UIKit trait system made this direction even clearer. Environment information was shaped into contextual data that propagates layer by layer through scene, window, presentation, view controller, and view, rather than existing as a single device-level fact. This also explains why the horizontalSizeClass developers read in an iPad window, sheet, or split column often differs from intuition.
• 2024: Tab Bar and Sidebar were treated as different presentations of the same navigation hierarchy under different spatial conditions, establishing a unified language for later automatic navigation morphing.
• 2025: iPadOS moved even closer to macOS, with windows, menu bars, pointers, and multiwindow workflows all becoming more desktop-like.
• 2026: iPhone apps entered a resizable environment, and the assumption that “iPhone apps only serve a fixed phone aspect ratio” officially became invalid.

iPad Full Screen Shows the Same Trend

The changes to Full Screen on iPad actually point to the same trend.

Apple has not taken away the user’s right to choose a full-screen working style, but it is gradually taking back the developer’s ability to lock an app into an old compatibility mode through UIRequiresFullScreen.

In iPadOS 26, users can still choose between Full Screen Apps, Windowed Apps, and Stage Manager through Settings or Control Center. But for developers, UIRequiresFullScreen has already been defined as a deprecated compatibility mode and will be ignored by the system in the future.

In other words, Full Screen is gradually changing from “something developers can require” into “something jointly determined by the user and the system.” For more on this, see Apple’s TN3192 and UIRequiresFullScreen documentation.

This brings iPad Full Screen and iPhone Resize back to the same main thread: developers can express preferences, minimum sizes, and temporary orientation locks, but they should no longer assume they own a fixed and unchanging canvas.

Back to My Project: Building My Own Layout Strategy with Geometry

After understanding these rules, I began to reexamine how my own app should respond to iPhone Resize.

Although it is possible to inject \.horizontalSizeClass = .regular into a SwiftUI subtree based on scene geometry, allowing some containers to enter regular semantics, this is not suitable as a global strategy.

This approach affects every view in that subtree that reads the environment value, and different components do not behave consistently under the combination of “phone idiom + injected regular.”

For example, NavigationSplitView can expand its sidebar, but in my testing, TabView(.sidebarAdaptable) does not automatically become an iPad-style Sidebar as a result.

This does not mean the tab sidebar opt-in API introduced by UIKit in iOS 27 has no value. Rather, it shows that a “wide iPhone window” and an “iPad navigation environment” are not the same concept.

In other words: a wide-window iPhone is still an adaptive iPhone presentation, not a full iPad product interface.

Given my app’s own scenarios, I found that Apple’s 2024 idea that “Tab Bar and Sidebar are different presentations of the same navigation hierarchy” fits the project very well.

So I defined the following strategy for the app:

• Use geometry to determine whether the current environment has entered a wide-screen state.
• On an iPhone host in wide-screen mode, show a custom Sidebar and hide the Tab Bar.
• Buttons in the Sidebar still drive Tab switching through state.
• On iPadOS, do not enable this iPhone-specific logic; instead, prioritize allowing system components to adapt according to their own traits and geometry.
• On macOS, remove the Tab structure entirely and use Sidebar navigation directly.

The Era of the Fixed Canvas Is Over

In the future, what developers can express will be more about preferences, rather than absolute control over the interface.

For example:

• Use UISceneSizeRestrictions to express a scene’s preferred minimum size.
• In SwiftUI, use windowResizability(_:) and the content’s minimum size to express window size preferences.
• Use prefersInterfaceOrientationLocked to express temporary orientation lock needs.
• Observe scene geometry changes through windowScene(_:didUpdateEffectiveGeometry:).
• Use UIWindowSceneGeometry.isInteractivelyResizing or SwiftUI’s onInteractiveResizeChange(_:) to distinguish between the interactive resizing process and the final state.

Users now have the final say over how an app is presented, while developers need to consider more possible presentation forms in advance. Although more and more system components now have strong adaptive capabilities, and SwiftUI has significantly lowered the barrier to building responsive interfaces, the number of scenarios developers need to handle has in fact increased.

The era of the fixed canvas is coming to an end, while the era of building interfaces around available space has only just begun.