Apple lists these containers as fully adaptive across all poses:
NavigationSplitView/UISplitViewControllerTabView/UITabBarController
Columns collapse when the device is closed, and tile or overlay when it is open. Sheets, popovers, context menus, and alerts adapt automatically too.
Why this is worth the migration
A custom navigation container written for a single-screen iPhone now has to handle: two displays with different size classes, four or more poses, Split View multitasking at arbitrary widths, and a hinge that appears and disappears. That is a large matrix to get right and to keep right.
The system containers already handle it, and will handle whatever ships next. If you have been carrying a custom container for historical reasons, this is the strongest argument in years for retiring it.
NavigationSplitView {
SidebarView()
} detail: {
DetailView()
}The sidebar is the point
The inner display is regular-width and Apple specifically notes it leaves room for sidebars. An app that already has an iPad layout can usually reuse it directly; an iPhone-only app gets a genuinely better layout for the first time here.
Presentation still adapts
You do not need to change how you present sheets, popovers, alerts, or context menus — those adapt on their own. The work is in the container, not the presentation.
How to verify
Navigate your primary flows in every pose and on both displays. Any place you have written if folded or if width > inside navigation code is a candidate for deletion.