Can't switch between presented view controllers

[oskarek]

Description

We have noticed what we think is an issue with this library. The problem happens when using the present(item:) method to present a view controller from another, and switch to another one.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

I expect the new view controller to replace the previously presented one, when the binding driving the navigation is updated to point to the other one.

Actual behavior

Some of the times (it seems to be even most of the times), what instead happens is that the presenting view controller is closed right after the presented one, instead of switching to presenting the new one, along with a console warning about trying to present a view cotroller on top of one whose view is not in the view hierarchy.

Steps to reproduce

1. Have a view controller Root, that presents another view controller A through a present(item:).
2. View controller A then in turn presents one of two other view controllers, B and C, depending on the value of a presentation binding.
3. View controller B is presented, and while it is presented, the binding is set to C instead.
4. Now, what's expected to happen is that view controller B should be closed and C opened instead. But this only happens some of the times you try it, and at other times it instead just closes both B and A, one ofter the other, going all the way back to Root. And when that happens, there is a warning printed in the console about trying to present view controller C on view controller A whose view is not in the view hierarchy.

This repo reproduces the bug and demos the scenario in which it happens. There is also a fix-branch that uses a fork of this library with a potential fix.

Just open the app in the project, and tap "Present A", then "Present B", then "Present C".

So it seems to be some race condition happening within the navigation machinery. As you can see by looking at the fix in the fork linked above, it seems to be resolved by delaying the dismissal of view controllers with "one tick" by wrapping it in a DispatchQueue.main.async {...}, but I'm not sure it's a good solution.

SwiftUI Navigation version information

2.2.2

Destination operating system

iOS 18

Xcode version information

16.1.0

Swift Compiler version information

swift-driver version: 1.115 Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)
Target: arm64-apple-macosx15.0

[thomasdelgado]

I'm having the same problem. Is that intended?

[mbrandonw]

Hi @oskarek and @thomasdelgado, this is just a limitation of UIKit (and SwiftUI). You cannot simultaneously dismiss+navigate in UIKit, you must space them out a bit. There are even logs in the console letting you know that something is wrong:

⚠️ Attempt to present <swift_navigation_dismiss_bug.ViewControllerC: 0x1038099f0> on <swift_navigation_dismiss_bug.ViewControllerD: 0x107038600> (from <swift_navigation_dismiss_bug.ViewControllerD: 0x107038600>) whose view is not in the window hierarchy.

We don't want to try to bake fixes for UIKit/SwiftUI problems in our libraries because it always bites us in the end.

Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[milobird]

@mbrandonw I would argue that since the promise of this framework is to create a binding between view controllers and models such that the destination in a model is always in sync with the state of the UI, this certainly constitutes a bug.

Also note that at present not only is the view controller for the new destination not being presented, but also the parent view controller is dismissed, which does not correspond to the UIKit behaviour when you call present immediately after dismiss at all.