After multiple testing of my solution above I ran into other issues (that occur on iOS 18.0 no matter if this fix is in place or not). A view is pushed back after I pop from it. Any help would be greatly appreciated. It might be because I am using @Environment(\.dismiss) var dismiss but the app is too big to completely break it apart just because Apple broke the navigation of SwiftUI in iOS 18.0. Guess I have to accept it and show some message to users on this specific iOS version.

It seems it has quietly been fixed in iOS 18.1 without Apple owning up to it anywhere in docs or online... For anyone that needs to support iOS 18.0 and iOS 18.0.1 (where this bug occurs) I created this snippet so you can use regular key-path bindings (more performant than creating them manually) and fall-back to manual on affected versions: private func needsNavigationWorkaround() -> Bool { guard #available(iOS 18, *) else { return false } // 17.x and older are fine let v = ProcessInfo.processInfo.operatingSystemVersion return v.majorVersion == 18 && v.minorVersion == 0 && v.patchVersion <= 1 } /// Wrap any binding you pass to `NavigationStack(path:)`. extension Binding { static func navSafe(_ base: Binding<Value>) -> Binding<Value> { if needsNavigationWorkaround() { // Disable the optimisation that's broken on 18.0 / 18.0.1 return Binding(get: { base.wrappedValue }, set: { base.wrappedValue = $0 }) } else { // Use the normal, optimised, key-path binding return base } } } Then you can use: NavigationStack(path: .navSafe($router.profilePath)) and it will use the manual binding only on the affected OS versions

What the hell is wrong with Apple? How come every single god-damned Xcode version breaks stuff that worked in the previous one. And the only support and response we get is fellow developers who painstakingly figured it out on their own. Legacy Preview Execution did the trick. I have yet to experience a product that breaks as often as Xcode.

I'm experiencing a similar problem. In my SwiftUI app, I used rootViewController?.view == hitView ? nil : hitView to create pass-through windows layered on top. However, iOS 18 has disrupted this functionality. Now, I receive two hit-tests: one correctly targeting the specific view (such as a button) returning a non-nil value, followed by an immediate second hit-test on the root view (which is unexpected, and seems like a bug).

I already managed to reproduce it with just the starting boilerplate, with no code change. Should I use the Feedback Assistant?

The project started in February 2024. I could (and now I can again) attach a debugger and print to console, which is good enough since I can just use print() statements everywhere. I never touched SIP. Thinking back about it, the debugger probably always crashed after po or a few step overs. It's possible the proper debugging has never worked and it has not changed during the lifetime of this project. Might be worth reporting as a bug?

I sincerely apologise for the delay, was stuck on other projects. The approach you suggested is not exactly solving my problem because I am creating a Finder (Quick Action) extension. Therefore I need to be able to debug it in Finder. As I mentioned, it's not even working in a fresh Apple boilerplate project. I tried the new Xcode beta, but the issue persists, so it's likely not an Xcode bug? I also tried to run sudo DevToolsSecurity -enable but that did not help. I fail to see what has changed since I was able to normally debug before. Some config? Something in my development profile (I didn't change anything). Not really sure. It it an lldb issue? Given that I am able to attach, step over a few times, but more 'heavy' stuff like po or stepping in/out, resuming execution crashes?

The correct approach is to set isReleasedWhenClosed = false on every programmatic window so that it follows ARC (Automatic Reference Counting) rules. The reason for this goes way back and a very helpful person on SO has helped me and explained it thoroughly. Check it out

Based on this post I used the pluginkit to run pluginkit -v -m -D -i <extensionBundleId> and removed the .app from all the paths it found (I had some old one lingering in an accidental .xcarchive). This allowed me to Run the extension as a normal app, choose Finder as Host and successfully attach. (I suppose this approach can serve as a 'clean slate'?). However the issue persists -> the debugger (or the extension, not sure which) crashes when I try to po something or show the Variables view. [quote='789031022, DTS Engineer, /thread/756097?answerId=789031022#789031022'] If you choose Process > Detach, does it crash? And do you get a crash report? [/quote] Yes it does. The same crash. It just turns off, debug view dissapears and I get the: "Couldn't communicate with a helper application." Not sure if I get a crash report. Don't see anything in the Console.app. Please bear in mind that this same exact scenario happens in a completely fresh new project with the Apple's boilerplate action extension code. I can run & attach but cannot debug. Should I try the approach with the dummy appex host? How exactly would I create that target inside the appex project?

Based on a post i found I tried deleting ~/Library/Preferences/com.apple.dt.Xcode.plist ~/Library/Caches/com.apple.dt.Xcode Which helped in the way that I can now Run the extension like a normal app, just choosing Finder as the host app. It hits the breakpoint but the same issue as above -> crash upon stepping over or upon usage of lldb.

I am not even sure I understand how to properly install new versions. Right now it seems I have a remnant. The extension is shown upon right-click on an item in Finder and is also visible in the Quick Actions selection menu, even though the container app is not installed in the /Applications directory and the build folder is cleaned. What is the best way to clean everything and making sure I have a clean slate? To be on the same page it is an extension that just compresses and converts an image. I tried what you said -> I built the app, moved the .app from build to the /Applications directory (to have the latest, not sure if this is the correct approach?), launched it normally via the right click/quick actions and then I tried Debug > Attach to process and selected it from the likely targets. Xcode ran it again and attached the debugger but when I try to use the lldb to po context or just to step over for example it crashes with exit code 9. @DTS Engineer

@eskimo How does one go about modifying stuff in the shared 'app grouped' plist if the defaults command does not support it? I would love to quickly modify, read & delete like I am normally used to with defaults. I found some workaround with killing cfprefsd but that's not working anymore. Direct modification in ~/Library/Group Containers/ does not work.

The content transition '.numericText(countsDown:)' that was introduced in iOS 16 does not work on iOS 16... is that a bug? Has anyone reported it? It does not matter if I wrap the value update inside a withAnimation block or not, it does not work. On iOS 17 it does, but I want backward compatibility.