LLDB crash

The other way was to quit by using Command+Q, then it would crash. On the next launch, the screen appearing that shows New Project or select recent would appear. This would prevent opening the previously open project.

The first crash report you posted looks to be associated with a bug in UIKit - note that your app crashed because of an uncaught ObjC exception -[__NSDictionaryM setObject:forKey:]: object cannot be nil (key: 0x20eaf0f68), and that the Last Exception Backtrace shows that -[__NSDictionaryM setObject:forKey:] was called by a chain of UIKit methods. I expect this is resolved in the latest iOS 26 beta. See here for general guidance on interpreting crash reports generated because of uncaught exceptions: https://developer.apple.com/documentation/xcode/addressing-language-exception-crashes

If your widget extension is crashing at launch, the device console should be logging something. It is also possible that it is failing to launch at all, if it looks like it is crashing before it gets to any of your code. So, what do you see in the logs after the publishing event record? I know the logs are extremely busy, but if you filter for your Bundle ID, you might see a record of an issue logged by the system.

[quote='850527022, Costique, /thread/794052?answerId=850527022#850527022, /profile/Costique'] all we have is crash reports from the App Store in Xcode. [/quote] Hmmm. This is using the Xcode organiser, right? I thought that had a way to get a JSON crash report, but I don’t have the details. I’m researching that. The reason why a JSON crash report is so helpful is that I can feed it into internal tools to look for related crashes. [quote='850527022, Costique, /thread/794052?answerId=850527022#850527022, /profile/Costique'] What surprises me a bit is Role: Non UI in all but one crash instance though the app does not use any background modes. [/quote] Well, as we say in the docs: This field is generally not helpful when you analyze a crash report. (-: Even if you don’t do anything to opt in to background execution, it’s still possible to run in the background. The most obvious case of this is that the system gives you a short amount of background execution ti

OK, let’s take a step back: What are you trying to do with signals? It’s very hard to use signals correctly. That especially true if you’re doing this in a process that uses Apple frameworks. For example, the code you posted is illegal because it calls printf from an async signal handler, and printf is not an async signal safe function. Most folks who ask about signal handlers are trying to implement a crash reporter. That’s impossible to do well. I talk about it in great depth in Implementing Your Own Crash Reporter. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are limits to how much I can help you with your third-party tooling; if you need help with those, I recommend that you raise this via the support channel for those tools. Still, I wanted to offer some insight into the overall issue here. Both of your crash reports suggest that you have a memory management issue. You’re crashing deep in Apple libraries as they try to work with Objective-C objects. I have a couple of suggestions on that front. First, you’re encountering this problem on TestFlight but it’s unlikely to be TestFlight related. I suspect that it’s actually tied to your Debug vs Release build configuration. When you test at your desk you use the Debug build configuration, but when you submit to the App Store you use the Release build configuration. It’s very common to see memory management problems like this show up only in the Release configuration. You can tease these apart using the Xcode organiser. See Isolating Code Signing Problems from Build Problems. You can also tweak

Hi Eskimo, Thank you for confirming it is not a Code Signing issue. I have spent the last few days to symbolicate a crash report. I found an open-source app MacSymbolicator that requires *.dSYM, which is available in .Net MAUI. Obviously, I no longer have it for the version I submitted to App Store. I must remember to keep it in future submissions. After creating a new build and uploading it to TestFlight, the app launches successfully. I guess my efforts to debug the app for the past two months have removed the bug. Also, I realized I cannot use xcrun to sideload the app signed using a Distribution Provisioning Profile. I must use TestFlight even though it is slow and cumbersome. The app has been successfully updated in both App Store and Mac App Store. Thank you very much. @DTS Engineer

Thank you for opening FB18299246. I'm following up on that internally — I can also reproduce the crash using your project when using Xcode 26 beta 4 and the iOS 18.4 simulator. — Ed Ford,  DTS Engineer

I'm currently working on building a custom HomeKit Accessory using the HomeKit ADK v6.3 and running the Remote.OpenSSL sample on a Raspberry Pi 4 (64-bit Ubuntu / Linux Kernel 6.1.21-v8+). I'm trying to pair the accessory via the MFi HomeKit ADK pairing process. The details of most MFi specifications are protected by NDA, so your question cannot be answered in detail on this forum. If you're an MFi licensee, then the MFi program has its own support process, the details of which you can find in the Developer Technical Support section of the MFi Licensing Handbook, which you'll find on the MFI Portal. Please submit your MFi-specific question(s) using that process. However, I will provide one hint/suggestion here: The application (Remote.OpenSSL) launches correctly, and the accessory server starts as expected, broadcasting via mDNS. However, when I attempt to initiate pairing via iOS (or simulate pairing), the following error occurs: Fault fatal error - HAPPlatformAccessorySetupLoadSetupInfo @ PAL/Linux/HAPPlatf