“LLDB crash”

iOS App terminated by Watchdog (Signal 9) in Background state despite reporting call Description I have successfully implemented VoIP pushes for the Killed state, where CallKit triggers correctly. However, when the app is in the Background state (suspended), it consistently crashes with an NSInternalInconsistencyException. The app process is killed by the iOS Watchdog because it fails to satisfy the requirement of posting an incoming call in the same run loop as the push receipt, or the completion handler is not being released fast enough by the JS bridge. Environment React Native Version: .78 React Native CallKeep Version: 4.3.14 React Native VoIP Push Notification Version: 3.3.3 iOS Version: 18.x Device: Physical iPhone [iphone 13 pro] The Issue When a VoIP push arrives while the app is in the Background: pushRegistry:didReceiveIncomingPushWithPayload: is called. RNCallKeep.reportNewIncomingCall is triggered on the Main Thread. The app is terminated by the system before the CallKit UI is fully esta

Hello, I have a iOS app I was looking at porting to Mac. I'm having an issue with both the Mac (Designed for iPad) and Mac Catalyst Destinations. I can't test Mac due to too many build issues. I'm trying to assign a new NSManagedObject into a NSPersistentStore. let object = MyObject(context: context) context.assign(object, to: nsPersistentStore) This works fine for iOS/iOS Simulator/iPhone/iPad. But on the Mac it's crashing with FAULT: NSInvalidArgumentException: Can't assign an object to a store that does not contain the object's entity.; { Thread 1: Can't assign an object to a store that does not contain the object's entity.

I have started from here: Apple's guide on the sharing core data objects between iCloud users and I have created a sample project that has Collections and Items. Everything works great while I stay on Swift 5, like with the initial project. I would like to migrate to Swift 6 (Default Actor Isolaton @MainActor, Approachable Concurrency: Yes) on the project and I am stuck at extension CDCollection: Transferable { ... }. When compiling with Swift 5, there is a warning: Conformance of 'NSManagedObject' to 'Sendable' is unavailable in iOS; this is an error in the Swift 6 language mode. After resolving almost all compile-time warnings I'm left with: Conformance of 'CDCollection' to protocol 'Transferable' crosses into main actor-isolated code and can cause data races. Which I don't think will work, because of the warning shown above. It can be worked around like: nonisolated extension CDCollection: Transferable, @unchecked Sendable Then there are errors: let persistentContainer = PersistenceController.shared.persis

When rendering an equirectangular video on a sphere using VideoMaterial and MeshResource.generateSphere(), there is a visible black seam line running vertically on the sphere. This appears to be at the UV seam where the texture coordinates wrap from 1.0 back to 0.0. The same video file plays without any visible seam in other 360° video players on Vision Pro, so the issue is not with the video content itself. Here is the relevant code: private func createVideoSphere(content: RealityViewContent, player: AVPlayer) { let sphere = MeshResource.generateSphere(radius: 1000) let material = VideoMaterial(avPlayer: player) let entity = ModelEntity(mesh: sphere, materials: [material]) entity.scale *= .init(x: -1, y: 1, z: 1) // Flip to render on inside content.add(entity) player.play() } The setup is straightforward: MeshResource.generateSphere(radius: 1000) generates the sphere mesh VideoMaterial(avPlayer:) provides the video texture X scale is flipped to -1 so the texture renders on the inside of the sphere The video

So I'm reworking couple things in my app. And I noticed I had this old code that does the following: Creates a temporary directory. Writes a file in the temporary directory. After the file is written moves the file out of the temporary location and places it in its final destination. Okay so I was not creating the temporary directory using the recommended API. I was simply doing something like this: NSURL *tempDirectory = [NSURL fileURLWithPath:[NSTemporaryDirectory() stringByAppendingPathComponent:[NSProcessInfo processInfo].globallyUniqueString]]; // Create tempDirectory and write files inside it. Now I just changed the code to use the recommended API which takes the the volume of the target destination into account: -URLForDirectory:inDomain:appropriateForURL:create:error:) and I pass in NSItemReplacementDirectory and a url to appropriateForURL so the destination volume is taken into account. Now I have external storage mounted and I use the recommended approach. I discovered NSFileManager simply writes a

I'm experiencing consistent memory crashes in iOS 26.3 (23D127) when using @AppStorage with view transitions. Environment: Device: iPhone 17 Pro Max iOS: 26.3 (23D127) Xcode: 26.2 (17C52) Issue: App crashes with Terminated due to memory issue when: Using @AppStorage to manage state Calling UserDefaults.set() in completion handler Transitioning to new view based on changed state Workaround: Using @State instead of @AppStorage prevents crash. Feedback: FB############ (your number) Has anyone else experienced this? Is this a known issue in iOS 26?

Hi there, I’ve been having ongoing issues with my Apple Watch. Last week I updated it to watchOS 26.3. The next day it accidentally ran out of battery, and since then it has been randomly restarting, showing an overheating message. I suspected it might be related to the update, so I researched online and on the official Apple forums. People recommended resetting the Apple Watch and unpairing it from my iPhone. I did both procedures, but the problem persists, even when the watch is in a cool environment. I’ve been using it normally, but it still restarts multiple times a day. Yesterday I even updated to the public beta of watchOS 26.4 hoping it would fix the issue, but it didn’t help — the random restarting continues. Today I also unpaired and paired it again with my iPhone, and the problem is still happening. This has been very disruptive and frustrating. I’m following up on my previous message because I’ve found additional diagnostic information that may help identify the cause of the issue. I accessed the A

I'm facing an issue with Xcode Cloud. Every branch I push to my GitLab repository is not appearing as selectable when I try to create a build with my workflow. Additionally, if I try to update the workflow from Xcode, it crashes every time I save the changes. Any help would be appreciated. Translated Report (Full Report Below) ------------------------------------- Process: Xcode [32110] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 26.2 (24553) Build Info: IDEApplication-24553000000000000~2 (17C52) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.apple.dt.Xcode [58945] User ID: 501 Date/Time: 2026-02-19 13:11:54.9987 -0600 Launch Time: 2026-02-19 13:03:37.7725 -0600 Hardware Model: Mac16,5 OS Version: macOS 26.2 (25C56) Release Type: User Crash Reporter Key: 61D7E2DA-E724-EFE2-6A01-25079BFCA2D1 Incident Identifier: B3D4A277-7CB5-4696-A00F-057929659F41 Sleep/Wake UUID: 2D4F6C41-716C-4B47-8D40-27FD2D74A8AE Time

Hi everyone, On macOS 26.4 beta (with Xcode 26.4 beta), I’m seeing the following console messages in a brand new SwiftData + CloudKit template project (no custom logic added, fresh CloudKit container): updateTaskRequest called for a pre-running task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 updateTaskRequest called for an already running/updated task com.apple.coredata.cloudkit.activity.export.F9EE783D-7521-4EC2-B42C-9FD1F29BA5C4 Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=8 (null) These messages appear: When CloudKit is enabled Occasionally on app launch Often when bringing the app back to the foreground (Cmd-Tab away and back) Even with zero additional SwiftData logic They do not appear when CloudKit is disabled. This behavior is reproducible on a completely new project with a fresh CloudKit container. Questions: What exactly do these messages indicate? Is BGSystemTaskScheduler Code=8 expected in this context? Are these sa