We hit what looks like the same lifecycle double-execution discussed here, investigated it with a single-variable-per-run bisect, and filed two Feedbacks with minimal repro projects: FB24753146 — NavigationSplitView (compact/iPhone): wrapping the detail column's root in a NavigationStack causes the pushed detail to be detached and re-inserted mid-push. Its .task is cancelled; with .tag sidebar rows it re-attaches and the task runs twice, but with NavigationLink(value:) rows it never re-attaches — the view stays visible with a dead task (permanent spinner). Deleting the NavigationStack wrapper makes the identical structure clean across launch, repeated pushes, and sidebar refreshes. A bare .navigationDestination on the detail root reproduces it too. FB24753158 — NavigationSplitView (regular/iPad): changing the sidebar selection while the detail's stack has pushed content always detaches the incoming detail root once (onDisappear while visible → .task cancelled → re-run). The pop-to-root and root-swap are processed in separate beats; clearing a bound path synchronously in the selection setter does not prevent it. Reproduced on iOS 26 (latest, hardware) and the iOS 27.0 simulator. Repro project (both cases, with the one-line toggle that flips clean/broken): github.com/…/navigationsplitview-detail-detach Notably this happens with stable identity — one model init, @State preserved throughout — so it isn't the _ConditionalContent identity issue alone; the trigger is specifically the NavigationStack (or a navigationDestination) attached to the split view's detail column root. Demo repo can be found at https://github.com/zeyrie/navigationsplitview-detail-detach.git

I am facing the same issue, when no permission is provided by the user for the app, accessing the lock screen camera capture, just opens the app. Not even the perform function in the camera capture intent is called.

@DTS Engineer I am facing the same issue, please suggest a work around or clarify this issue