LLDB crash

What could be causing our app to fail detecting iBeacon regions when terminated, while third-party apps work correctly? I don't know specifically, but I suspect there is an issue with how your app handles being launched into the background. The typical pattern here is that the system did launch the app into the background, but then the app either crashed or never actually registered with CoreLocation, so it never received the message notifying it that it's beacon was discovered. The other possibility is that there is an issue with your beacon itself. Why does our iBeacon detection start working only after another iBeacon app triggers? I don't know, but my guess is that there's something more complicated going on and the 3rd party app is only an indirect factor. Are there specific implementation requirements or best practices for reliable background iBeacon monitoring? The main one is that your app needs to be able to fully launch in the background. Could this be related to iOS background app refresh

Observed a few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. Yes, it looks like there is a bug there. More specifically, calling CXProvider.init(configuration:) kicks off an XPC connection to callservicesd on a secondary thread, the end of which eventually calls providerDidBegin(_:). If that completes before you're able to call setDelegate, then you'll see the problem you're describing. Oddly, as far as I can tell, the issue has basically been present from the beginning, so I'm not sure why I haven't heard of this before. Are you creating CXProvider on a background thread? I generally recommend using the main thread for CallKit and PushKit, and it's possible that initializing them on a background thread might make this problem more likely due to differences in thread priority. Moving to here: This issue was observed multiple times with our testing. Since there is no pro

@DTS Engineer thank you for these suggestions. I've added the full crash report from Crashlytics to this post. After enabling the launch argument you suggested, I managed to reproduce the crash in the debugger once, so that's some progress. After enabling Swift 6 and complete concurrency checking, I got some build errors in the class owning the ModelActor. Wherever I accessed the ModelActor, I got this error: Sending 'self.localStorage.some' risks causing data races. As mentioned in my original post, the ModelActor conforms to a protocol because I am using another type of storage in iOS 16 which doesn't support SwiftData. This protocol didn't require that conforming types were Actors, leading me to suspect that the class owning the ModelActor didn't treat it as an actor, because it only know about the protocol. Adding the Actor requirement to the protocol, removed the build errors in the owning class. Now, I have to ship this change to confirm that it actually fixes it, since I cannot reliab

Please post a full Apple crash report. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Do you have a full symbolicated crash report to share? You can include crash reports directly in your post using the forums attachment feature. For any random crash related to SwiftData / Core Data, I'd suggest that you add com.apple.CoreData.ConcurrencyDebug 1 as a launch argument of the app to check if there is any violation, as discussed here. Also, I guess ConsumptionSession is Sendable? Otherwise, Xcode will give you an error if you compile with Swift 6. If you haven't used Swift 6, I'd suggest that you give it a try to see if that unveils any race condition. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I had the same crash with same crashlog. In my case I used WKWebView to display PDF document. Crash used to occur when you long press to call actions menu anywhere in the area without text. If you long press on text, actions menu was displayed without crash. It was on iOS 26 beta 5, but now on iOS 26 beta 7 I can't reproduce crash in such scenario. Looks like it was fixed, but can't say for sure, since I didn't find mentions of such problem in release notes.

You’re using a third-party crash reporter and it’s undermining your ability to debug this issue. This is not uncommon. I discuss this in way too much detail in Implementing Your Own Crash Reporter. My advice is that you remove your third-party crash reporter and then wait for new Apple crash reports to arrive. To illustrate the sorts of problems I’m talking about here, let me pull apart that second crash report, starting with this: Exception Type: EXC_CRASH (SIGSEGV) Exception Codes: 0x0000000000000000, 0x0000000000000000 Triggered by Thread: 0 This shows that your process crashed due to a memory access exception. That it, it was running some code that accessed an invalid memory location. Let’s look at the backtrace of the crashing thread: Thread 0 name: Thread 0 Crashed: 0 libsystem_kernel.dylib … mach_msg2_trap + 8 (:-1) 1 libsystem_kernel.dylib … mach_msg2_internal + 76 (mach_msg.c:201) 2 libsystem_kernel.dylib … mach_msg_overwrite + 4

I have the same problem. Dis you solve that? I do not have a crash on payment, because I set IgnoreInvalidProducts with true value. But with this case i can not receive my subscriptions… I receive invalid products array with my subscription ID… I can offer you to try this: https://github.com/9khub/MAUI.StoreKit2