I’m stuck with repeated production crashes in my SwiftUI app and I can’t make sense of the traces on my own. The symbolicated reports show the same pattern: Crash on com.apple.CFNetwork.LoaderQ with EXC_BAD_ACCESS / PAC failure Always deep in CFNetwork, most often in URLConnectionLoader::loadWithWhatToDo(NSURLRequest*, _CFCachedURLResponse const*, long, URLConnectionLoader::WhatToDo) No frames from my code, no sign of AuthManager or tokens. What I’ve tried: Enabled Address Sanitizer, Malloc Scribble, Guard Malloc, Zombies. Set CFNETWORK_DIAGNOSTICS=3 and collected Console logs. Stress-tested the app (rapid typing, filter switching, background/foreground, poor network with Network Link Conditioner). Could not reproduce the crash locally. So far: Logs show unrelated performance faults (I/O on main thread, CLLocationManager delegate), but no obvious CFNetwork misuse. My suspicion is a URLSession lifetime or delegate/auth-challenge race, but I can’t confirm because I can’t trigger it. Since starting this investigation, I also refactored some of my singletons into @State/@ObservedObject dependencies. For example, my app root now wires up AuthManager, BackendService, and AccountManager (where API calls happen using async/await) as @State properties: @State var authManager: AuthManager @State var accountManager: AccountManager @State var backendService: BackendService init() { let authManager = AuthManager() self._authManager = .init(wrappedValue: authManager) let backendService = BackendService(authManager: authManager) self._backendService = .init(wrappedValue: backendService) self._accountManager = .init(wrappedValue: AccountManager(backendService: backendService)) } I don’t know if this refactor is related to the crash, but I am including it to be complete. Apologies that I don’t have a minimized sample project — this issue seems app-wide, and all I have are the crash logs. Request: Given the crash location (URLConnectionLoader::loadWithWhatToDo), can Apple provide guidance on known scenarios or misuses that can lead to this crash? Is there a way to get more actionable diagnostics from CFNetwork beyond CFNETWORK_DIAGNOSTICS to pinpoint whether it’s session lifetime, cached response corruption, or auth/redirect? Can you also confirm whether my dependency setup above could contribute to URLSession or backend lifetime issues? I can’t reliably reproduce the crash, and without Apple’s insight the stack trace is effectively opaque to me. Thanks for your time and help. Happy to send multiple symbolicated crash logs at request. Thanks for any help. PS. Including 2 of many similar crash logs. Can provide more if needed. Atlans-2025-07-29-154915_symbolicated (cfloader).txt Atlans-2025-08-08-124226_symbolicated (cfloader).txt

Hello everyone, I'm encountering an issue while trying to debug a macOS Action Extension. I created a completely fresh project with an Action Extension target. When I select the Action Extension scheme and run it, choosing Finder as the host app (app to launch it in), I receive the following error: Attach failed: Could not attach to pid : “647”. (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.) This is in Console.app: macOSTaskPolicy: (com.apple.debugserver) may not get the task control port of (Finder) (pid: 647): (Finder) is hardened, (Finder) doesn't have get-task-allow, (com.apple.debugserver) is a declared debugger(com.apple.debugserver) is not a declared read-only debugger. I am pretty sure it worked before on my project that I am developing. It stopped working and now it doesn't even work on a fresh new project. Any ideas? I tried cleaning derived data, restarting my mac, nothing helps. As per the documentation it should work normally using the Build & Run button.

I am trying to wrap my head around proper lifecycles of NSWindows and how to handle them properly. I have the default macOS app template with a ViewController inside a window that is inside a Window Controller. I also create a simple programatic window in applicationDidFinishLaunching like this: let dummyWindow = CustomWindow(contentRect: .init(origin: .zero, size: .init(width: 200, height: 100)), styleMask: [.titled, .closable, .resizable], backing: .buffered, defer: true) dummyWindow.title = "Code window" dummyWindow.makeKeyAndOrderFront(nil) The CustomWindow class is just: class CustomWindow: NSWindow { deinit { print("Deinitializing window...") } } When I close the programatic window (either by calling .close() or by just tapping the red close button, the app crashes with EXC_BAD_ACCESS. Even though I am not accessing the window in any way. One might think it's because of ARC but it's not. One—the window is still strongly referenced by NSApplication.shared.windows even when the local scope of applicationDidFinishLaunching ends. And two—the "Deinitializing window..." is only printed after the window is closed. Closing the Interface Builder window works without any crashes. I dug deep and played with the isReleasedWhenClosed property. It made no difference whether it was false or true for the IB window. It stopped the crashing for the programmatic window though. But this raises three questions: What is accessing the programatic window after it's closed—causing a crash because the default behaviour of NSWindow is to release it—if it's not my code? What is the difference under the hood between a normal window and a window inside a window controller that prevents these crashes? If the recommended approach for programmatic windows is to always set isReleasedWhenClosed = true then how do you actually release a programatic window so that it does not linger in memory indefinetely? If the EXC_BAD_ACCESS means that an object is double de-allocated then that would mean that .close() both releases the window (first release) and removes it from the window list which would mean last strong reference is released and ARC cleans the window out (second release). The theory is supported by me calling .orderOut() instead of close which only removes it from the application list and that does indeed release it without crash. Does this mean programmatic windows should override the close() instance method to call orderOut() instead? This seems like poor API design or I am understanding it wrong?

I have a simple main app architecture: struct ContentView: View { @State private var isSignedIn = false @AppStorage("onboardingCompleted") var onboardingCompleted: Bool = false var body: some View { Group { if onboardingCompleted && isSignedIn { MainView() } else { OnboardingView() } } .onAppear() { signIn() } } OnboardingView is a NavigationView. MainView is a TabView. I switch between these when the user finishes onboarding. However, as the user taps on the finish button in the last onboarding step, this gets written to the console: Trying to pop to a missing destination - SwiftUI/NavigationBridge_PhoneTV.swift:213 - please file a bug report. In production, this causes a crash. I looked around and it seems it is an issue when you embed TabView inside NavigationView or vice versa? But here it's not the case, they are standalone and I switch between them. Any thoughts?

Some users report random crashing when just navigating the app. The app is really simple, here is the structure (it's MVP so most of the screens are not done yet): @State private var isChatModalPresented = false @State private var selectedTab = 0 @State private var previousTab = 0 var body: some View { TabView(selection: $selectedTab) { Text("Dashboard") .tabItem { Label("Dashboard", systemImage: "house") } .tag(0) Text("Training") .tabItem { Label("Training", systemImage: "flame") } .tag(1) Text("") .tabItem { Label("Chat", systemImage: "bubble.left") } .tag(2) Text("Recovery") .tabItem { Label("Recovery", systemImage: "heart") } .tag(3) Text("Community") .tabItem { Label("Community", systemImage: "person.3") } .tag(4) } .onChange(of: selectedTab) { neco in if selectedTab == 2 { self.isChatModalPresented = true selectedTab = previousTab } else { previousTab = selectedTab } } .fullScreenCover(isPresented: $isChatModalPresented) { ChatView(isPresented: $isChatModalPresented) } } } It's supposed to be a standard tabview, except that when you tap on the middle item, it's supposed to present a view from the bottom using fullScreenCover. Is this code correct? I am supplying the crash log: Exception Subtype: KERN_PROTECTION_FAILURE at 0x0f00002a00000000 -> 0x0000002a00000000 (possible pointer authentication failure) Exception Codes: 0x0000000000000002, 0x0f00002a00000000 VM Region Info: 0x2a00000000 is in 0x1000000000-0x7000000000; bytes after start: 111669149696 bytes before end: 300647710719 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL ...(unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) UNUSED SPACE AT END Termination Reason: SIGNAL 10 Bus error: 10 Terminating Process: exc handler [25839] Triggered by Thread: 0 Thread 0 name: Thread 0 Crashed: 0 libobjc.A.dylib 0x0000000184eb98a4 lookUpImpOrForward + 72 (objc-runtime-new.mm:7331) 1 libobjc.A.dylib 0x0000000184eb4cc4 _objc_msgSend_uncached + 68 2 UIKitCore 0x000000018f01f46c -[UIViewController dealloc] + 860 (UIViewController.m:3270) 3 UIKitCore 0x000000018f0e8a88 -[UINavigationController dealloc] + 296 (UINavigationController.m:871) 4 UIKitCore 0x000000018f4ce920 -[_UISplitViewControllerColumnContents .cxx_destruct] + 44 (UISplitViewControllerPanelImpl.m:438) 5 libobjc.A.dylib 0x0000000184eb5374 object_cxxDestructFromClass(objc_object*, objc_class*) + 116 (objc-class.mm:457) 6 libobjc.A.dylib 0x0000000184eb509c objc_destructInstance + 80 (objc-runtime-new.mm:9057) 7 libobjc.A.dylib 0x0000000184eb503c _objc_rootDealloc + 80 (NSObject.mm:2153) 8 CoreFoundation 0x000000018cb51f48 cow_cleanup + 164 (NSDictionaryM.m:141) 9 CoreFoundation 0x000000018cb51e54 -[__NSDictionaryM dealloc] + 148 (NSDictionaryM.m:407) ... 36 UIKitCore 0x000000018ef9eedc UIApplicationMain + 340 (UIApplication.m:5270) 37 SwiftUI 0x00000001919b0898 closure #1 in KitRendererCommon(_:) + 176 (UIKitApp.swift:51) 38 SwiftUI 0x00000001919b06dc runApp<A>(_:) + 152 (UIKitApp.swift:14) 39 SwiftUI 0x000000019162125c static App.main() + 128 (App.swift:114) 40 REDACTED 0x00000001044243f4 static REDACTED.$main() + 52 (REDACTER.swift:0) 41 REDACTED 0x00000001044243f4 main + 64 42 dyld 0x00000001af8e2dcc start + 2240 (dyldMain.cpp:1269) It seems that something is happening under the hood regarding deallocation inside underlying UIKit views so I suspect this main navigation is the culprit?