I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator:
- Before navigation: offset 754.67, container height 733, bottom inset 107
- During pop: offset 705.67, container height 782, bottom inset 58
- After pop: offset 754.67, container height 733, bottom inset 107
The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state:
- Adding more bottom spacing
- Disabling scroll content offset adjustment in the navigation path transaction
- Saving and restoring ScrollPosition after the pop
- .defaultScrollAnchor(.top, for: .sizeChanges)
- Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned
The workaround that has been reliable is:
- Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing.
- Measure the Tab Bar's effective occupancy from public geometry:
root ScrollView bottom inset
- window bottom safe-area inset
- the app's normal trailing scroll margin
- While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView.
- When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled.
With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?