Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>

There are many situations where debug breaking points are not the right tool. What I often need is a log that shows what gets called, with how much frequency, and in which order. There are so many times where I have to add print statements, re compile, re run, see that I didn't include all the print statements I needed, and repeat a couple of times. My proposal (with zero knowledge of technical feasibility), is that much like we have break points, add "print break points" for logging without modifying code. It would be nice too, if I could also, add a "timer break point", where I can tag a function definition, and every time it gets called, it's are timed. Again, no idea if this is possible, but it would be extremely helpful for me, and I'm guessing to many other devs as well. Thoughts?

I'm trying to track identified objects in realtime with bounding rects, with no 3D integration, but still has poor update performance. I'm trying to understand how to optimize frame updates. (I'm a new programmer) Using: Foundation, AVFoundation, ARKit, CoreVideo, Vision, CoreImage, CoreVideo with YOLOE-11s object detection currently throttled to 2fps. (target iOS, testing on 16pro) YOLOE-11S CoreML model detects objects with class labels + bounding boxes Labels are matched against ObjectCatalog.json for relevance Matched objects are promoted from blue (detected) to green (identified) Log warnings: ARSession <0x110afdb80>: The delegate of ARSession is retaining 13 ARFrames. The camera will stop delivering camera images if the delegate keeps holding on to too many ARFrames. This could be a threading or memory management issue in the delegate and should be fixed. Skipping integration due to poor slam at time: 619447.208339 vio_initialized(1) map_size(0) tracking_state_is_nominal(0) is_3dof(0) reinitialize_attempts(6) slam_mode(RegularSLAM)

When working on a multi-window AppKit app, how do you identify which window instance is associated with the current breakpoint? The same question applies when using LLDB. If execution stops inside an object that can exist in more than one window, such as a shared NSViewController subclass, how do you know which window’s object you are currently inspecting? Does Xcode provide a mechanism for showing the NSWindow associated with the current view, view controller or responder while debugging? My current approach is to print object identities and compare them manually. For example, if several identical windows are open, I might print the current object and its window: print(self, #function) Then I interact with one window, make a note of the printed memory addresses in the console, switch to another window and compare the output. This works, but it feels manual. I am not dealing with different window subclasses. The windows may be instances of the same class and may contain instances of the same view controller classes. I simply want an easier way to distinguish which window instance I am debugging. Is there a recommended Xcode, LLDB or AppKit workflow for this?

What are the best practices for a painless physical watchOS debugging loop in Xcode? Debugging a standalone or companion watchOS app on a physical Apple Watch is arguably the slowest feedback loop in Apple development. Every minor code change often results in Xcode getting stuck on "Installing to Apple Watch" for minutes, or throwing a "Failed to attach" LLDB error after a long timeout. The biggest bottlenecks seem to be: The initial Symbol Copying / dyld shared cache sync: This takes forever whenever watchOS gets updated. Can these symbols be pre-cached or manually downloaded on the Mac via an internet connection rather than pulling them byte-by-byte from the watch? Slow Installation over Bluetooth: The watch often defaults to a sluggish Bluetooth link with the iPhone instead of leveraging local Wi-Fi or the direct Mac-to-Watch network tunnel. Debugger Connection Timeouts: Xcode routinely loses track of the target process before the app finishes launching on the watch. My Question: What are your recommended workflows, hidden Xcode flags, build settings, or networking setups to make physical watchOS debugging as close to the simulator experience as possible? Specifically, how do we handle symbol caching and force faster deployment pipelines?