Can confirm on iOS 26.0 too. Very annoying. Solved conditionally rendered view by displaying it always and instead hiding it with .opacity(condition ? 1 : 0).

What the hell is that? We cannot even rely on basic native APIs? How are you supposed to work around this?

Right, sorry. I created this extension: extension URLSession { static var `default`: URLSession { if #available(iOS 18.4, *) { let config = URLSessionConfiguration.default config.usesClassicLoadingMode = false return URLSession(configuration: config) } else { return URLSession.shared } } } And I replaced all URLSession.shared with URLSession.default. Will deploy it to production and get back to you in a few weeks to see if it helped on newer systems. Please correct me if I did something wrong.

The property you're referring to (usesClassicLoadingMode) is available on 18.4+ (wouldn't help for my users who are on iOS 17 and early 18) and it's true by default on the shared URLSession which I use throughout the entire app. I don't use any other session, no custom configurations. I just use Task a lot. Yet I still get crash reports from users on 18.6.2. Therefore I think it's safe to say it doesn't help. As per the crashlogs -> I would most certainly and happily get rid of a third party one, but it delivers more reports that Apple's own one. Perhaps I am doing something wrong but in the Organizer there's just less of them. Looking at Organizer though, the same crash report is also there and when I open the .xccrashpoint and dig in the folder structure and open any of the .crash items in the Logs directory, the same thread crashes occur: Thread 10 name: Thread 10 Crashed: 0 libdispatch.dylib 0x00000001a181de08 _dispatch_source_set_runloop_timer_4CF + 36 (source.c:1349) 1 CFNetwork 0x000000019ae29ed8 URLConnectionLoader::loadWithWhatToDo(NSURLRequest*, _CFCachedURLResponse const*, long, URLConnectionLoader::WhatToDo) + 960 (URLConnectionLoader.cpp:1778) ... Would that mean we can rule out the third party crash reporter messing up the crashes? Anyway, is there anything else I could do? The error is not going away and the crash rate is around 2% of my users. This is the only big bug causing issues in my app. I am more than happy to spend time debugging and trying solutions.

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