“LLDB crash”

Is RNVoipPushNotificationManager.addCompletionHandler causing a delay in the background run loop that triggers the Watchdog? I wouldn't think so, but it depends on what the full crash log shows. If you block inside your didReceiveIncomingPushWith delegate long enough then you can trigger this crash, but that time required is long enough that it doesn't really come up all that often. The more common problem is that an issue in your call reporting logic means that you DID in fact do this: Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push. Should completion() be called immediately in Swift for the Background state, rather than waiting for VoipPushNotification.onVoipNotificationCompleted in JS? To be honest, the completion handler is largely irrelevant. It was added in iOS 11.0 as part of adding PKPushType.fileProvider support, but it isn't actually part of the call handling process. You should call it as part of general correctness, but faili

Thank you for the project. You are correct that crashes occur in version 26.0, while the issue is resolved in version 26.2 and subsequent versions. 0x181e54814 <+296>: b 0x181f0450c ; symbol stub for: operator delete(void*) -> 0x181e54818 <+300>: brk #0x1 Although the issue has been resolved, iOS 26.0 will still experience the issue. Therefore, I have two recommendations: the first is to avoid using u{200C} as previously mentioned. This will prevent the line below from crashing on iOS 26.0 or prompting your customers to upgrade to iOS 26.2. //let string = u{274D}u{200C}u{1CD7}u{20DB} let string = u{274D}u{1CD7}u{20DB} Thank you again for your assistance. I apologize that the workaround may not have met your expectations. However, I am pleased to inform you that the issue has been resolved. Albert Pascual
  Worldwide Developer Relations.

It is a bit non-standard not being deployed as a System-Extension, but rather as a global daemon. This is actually pretty common. So, let me start here: My guess is, some ES_AUTH events (with deadline) arrive when Mac goes to sleep, and somehow my high-priority dispatch_queue handling them is put to sleep mid-processing them, so when the Mac wakes up - event handling continues long after the deadline passed, and MacOS decides to kick the process. No, I don't think that's what's going on, at least not in the basic case. The system that feeds events into your ES client as a kernel extension feeding events into user space and it will have kept your ES client active long enough that we cleared all syscall activity through your client before we allowed the system to sleep. There are lots of places where things can go wrong, but I don't think the core event delivery system is the issue. That leads back to here: Hi, I develop an ES client applying rule-engine evaluating ES events (mostly File-system events). What do

Hi, Thank you for your reply. It is important work within the exact same environment. I am currently using Xcode 26.2 with the iOS 26.0 simulator iPhone 17 or iPhone17 pro (should happen of any of them), and I was able to reproduce the issue on other MacBooks as well with same environment. During our investigation of crash reports, we found that this issue occurs in production on certain iOS versions. Reproducing it locally in the simulator has been the only reliable way to validate the behavior. I would greatly appreciate your assistance with this matter. The problem does not appear to be related to UIKit. I can reproduce it in SwiftUI using Text as well. Unfortunately, the stack trace is not very informative. The crash also occurs when simply passing this specific character to Safari within the simulator. In most cases, the crash can be reproduced by adding the character to a project and building it with the iOS 26.0 simulator using iPhone 17. When running the same project on iOS

Thank you for your post. I have been unable to reproduce the issue by simply copying and pasting your code. I am interested in understanding the issue further, as it appears to be related to UIKit. If you connected the label to a storyboard, could you please provide me with a focused sample that I can download and test? If you're not familiar with preparing a test project, take a look at Creating a test project. However if it crashes, this is a very specific and concerning crash. Looking at the code I tried as well to play on the characters a little, however I’m not connecting to a storyboard or SwiftUI. let problematicString = u{274D}u{200C}u{1CD7}u{20DB} let safeString = problematicString.replacingOccurrences(of: u{200C}, with: ) label.text = safeString Looking forward to your focused sample! Albert Pascual
  Worldwide Developer Relations.

Another crash log added to the bug, in case it helps.