.nbUseNavigationStack(.whenAvailable)) In UIHostingController cause Infinite loop

[SouHanaQiao]

This is a nice library. I am using it in a development privacy SDK framework with SwiftUI. The UIKit main app will call it. So, I was using UIHostingController.
This is a Infinite loop code.
UIHostingController(rootView: NBNavigationStack(root: { Text("") }).nbUseNavigationStack(.whenAvailable))

[ilendemli]

We noticed the same issue but it's very inconsistent. Running directly from Xcode does not cause any issues. Compiling a release build on our servers using Xcode 14.3.1 causes this issue. Happens on iOS 16.0 and 16.3.1 (we have no devices in between). No issues on iOS 16.4 or never.

[ClementCardonnel]

Same here! One of our QA testers running on 16.1 noticed it. This can actually be reproduced in the simulator. I've tried it on both 16.1 and 16.2.

I resorted in downgrading the library to the 0.8 version.

A memory leak of some kind could be involved. I've captured a screenshot of the memory report tool:

The leak occurs after presenting a NBNavigationStack, setting a breakpoint in the SwiftUI code shows the loop in action.

[johnpatrickmorgan]

Thanks for the extra info @ClementCardonnel. Can I ask if appending .nbUseNavigationStack(.never) to the NBNavigationStack resolves the issue?

[johnpatrickmorgan]

I'm also having some trouble reproducing this, so if you're able to share a minimal repro case, that would be really helpful.

[ClementCardonnel]

I tried writing a sample project, but I couldn't reproduce the issue as well outside of my project (which I cannot share)…

However, I've tried setting .nbUseNavigationStack(.never) and it solved the issue for the screen I was testing. 🙂

[timlittlelabs]

We also experience issues with using .nbUseNavigationStack(.whenAvailable) but it's very inconsistent. The issue surfaces depending on the implementation of what view we're navigating to, and is also inconsistent across iOS 16 versions. We are also resorting to .never for now, but this is definitely a confirmed problem on our end.

Also confirming that the fix in 0.9.4 for issue #47 does not resolve this issue @johnpatrickmorgan