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?

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 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?

Hello, I am having troubles with my tracking app. The goal is for the user to start location manager updates (tracking) in the foreground and then allowing him to minimise the app and use the phone with other apps. Just letting my app in the background fetching location, analysing IMU sensors and processing the data so an overview can be presented after the tracking finishes. What I found out from beta testers is that they correctly launched the tracking in foreground, then they switched to a different app and some of them just locked their devices. The tracking stopped after around 20 minutes and the users report that the app was suspended by the system and that they are back at the login screen. How is this possible? I thought that once user starts location updates in the foreground and then goes into the background and uses other apps/locks the device, the system should never suspend the app and this shouldn't happen - ergo I should not bother implementing state restoration. Am I wrong about that? I have Background Modes - Location Updates enabled as well as these three lines: locationManager.allowsBackgroundLocationUpdates = true locationManager.pausesLocationUpdatesAutomatically = false locationManager.showsBackgroundLocationIndicator = true Does anyone have any ideas? Thank you for your time.