Full screen presented view is being dismissed when a system alert appears.

[PeterKovacs89]

Reproduction steps:

• present a view in a NavigationCoordinatable coordinator using @Route(.fullScreen) var playback = playbackView
• the presented view asks for microphone permission that triggers presenting a system alert
• in the NavigationCoordinatable class the internal func appear(_ int: Int) is getting called by this alert presentation with id -1.
• This causes a pop to root mechanism so the presented screen is being dismissed and the whole routing is broken from that point

Requesting the permission later did not help, it triggers the same mechanism. Using a dedicated Coordinator for the presented screen did not help either.

I can add more code snippets if it helps.

[micbakos]

I can attest to that. I couldn't find out what is going on until I discovered this issue. It doesn't have to be presented with fullScreen btw.

Personally,

1. I have a root view @Root var home = makeHome which navigates to a Withdraw view with the push mechanism.
2. The second view @Route(.push) var withdraw = makeWithdraw has a button that opens the address scanner screen (A screen that scans for QR codes with camera) @Route(.push) var addressScanner = makeAddressScanner.
3. When this screen appears, I request for AVCaptureDevice.requestAccess(for: .video) video permission, which, pops both address scanner view, and the withdraw view until it navigates back to the home view.
4. At this point the system's dialog is still visible, but my app's top view is home.

As @PeterKovacs89 mentions the internal func appear(_ int: Int) is called with int = -1.

[rundfunk47]

Tricky issue to fix honestly. Perhaps a way to temporarily suspend the appear-function would work? 🤔

[lonkly]

95% related to iOS16 new NavigationStack thing, getting the same symptoms with Bluetooth pairing request - it breaks the navigation, exactly when the system alert window appears.

[Charlyk]

Hello, I've got yesterday into this issue and started to debug it. I found what was causing this behavior, in my case I had a navigation drawer that was wrapping the content and inside I had a GeometryReader around the whole drawer, and when presenting alerts or keyboard is showing, that GeometryReader had to rerender it's children and thus the entire stack was popping to root each time because all the main content was inside of it. I moved the content view in the drawer out of GeometryReader and it worked as expected. In your case it might not be a GeometryReader but the idea is that when presenting default alerts or keyboard, it may trigger a rerender somewhere in the begining of stack. Another way that can help you with this is to conform views to Equatable and let SwiftUI know if the view needs to be rerendered or not, but this will not help in cases like mine because GeometryReader will rerender if something triggers it.

Hope this will help.