LLDB crash

The operating system is ready It is not. Xcode barely runs on macOS as it is. Xcode is the single most crash-happy app I have. It crashes on me at least 3-4 times per day, every day. Xcode on iPad would not be a pleasant experience.

For anyone facing a similar issue, we found that the crash logs were not helpful. They were both misleading and lacked the necessary detail to diagnose the problem. To uncover the actual cause, we had to connect a user's personal device to Xcode and inspect the console directly. This revealed the true error, which was not captured in the standard crash reports. There really needs to be a better mechanism for users to securely share these logs with developers in cases like this, without requiring direct access to their device. In our case, the console logs indicated that corrupted data stored in the Keychain was causing the app to crash when accessed. Importantly, this had nothing to do with the didFinishLaunchingWithOptions method, despite what the crash logs initially suggested.

Same issue Xcode 26 (17A321), I've added FB20258577 with icon composer file and the inspector settings per layer. By blur do people mean Liquid Glass effects? Otherwise we have normal blend mode. The only way I was able to get a build uploaded today to fix my missing icon on the iPad target was to delete this file altogether. I have no idea why the iPhone target worked at all. Xcode Cloud was building for 2 hours today with no feedback. I finally archived myself and saw the validation errors with the red herring of it being in an asset catalog. So very tired but happy to have worked on betas again. I gave up on that when iOS 5 iCloud builds crashed every other launch and I had to revert three months of work. Not reverting Liquid Glass. It has issues, but it's very pretty when you give it a chance. It was inspiring to work with something beautiful amongst all the ugliness in the world these days.

Sounds good. Here is the crash report: com.myCompany.myDaemon-2025-09-15-081339.txt

Thanks for your patience. I add some log at main and -(void)load function. However, the no logs and crash reports appear in console.app. I also make a DTS request with Case-ID: 15847816 , and send the demo project and app. Would you be able to review the attachment and offer additional support?

[quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] I'm developing a macOS console application [/quote] “Console application” isn’t a term we use on Apple platforms. An application is, by definition, something the user double clicks in the Finder, shows up in the Dock, has a menu bar, and so on. I’m presuming that you’re building a command-line tool, something that the user runs from Terminal, or is run by the system as, say, a launchd daemon. Please let me know if that’s not the case. [quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] What is the recommended approach for debugging applications that need to load dynamic libraries? [/quote] There are a number of factors in play. I’ll come back to that later. But first I want to dig into your log message: [quote='800260021, danilabagroff, /thread/800260, /profile/danilabagroff'] Error Details When running the application through LLDB, I get this sandbox denial in the system log… logd_helper(587) [/quote] L

OK, that’s definitely a sysex. Thanks for confirming. Given that, you should be able to export it for direct distribution with Developer ID signing. You’ll have to carefully work through the steps in Exporting a Developer ID Network Extension. Make sure that: The code is signed with the Developer ID variants of the com.apple.developer.networking.networkextension entitlement values. That entitlement claim is authorised by a Developer ID provisioning profile. Make sure to check both the container app and the embedded sysex. I also recommend that you add a ‘first light’ log point to your sysex so you can see whether it’s code runs at all. See Debugging a Network Extension Provider for more about that. And if you don’t get that log point, make sure to check for crash reports. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='857868022, ski4funSonoma, /thread/799933?answerId=857868022#857868022, /profile/ski4funSonoma'] it seems to be the remedy to the helper/daemon crash. [/quote] That’s unlikely. Launch contraints typically cause things to fail rather than make things work. Hence the constraint. My advice here is that you remove anything you’ve done with regards launch constraints and then debug the original problem you were seeing. If that’s a crash and you post a crash report, I’d be happy to take a look. See Posting a Crash Report for advice on how to post a crash report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com