Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

Reply to Safari App Extension fails to connect to CloudKit daemon (cloudd) with XPC communication errors -- CKErrorDomain Code=6 / NSCocoaErrorDomain Code=4099 – Unable to connect to CloudKit daemon
This topic is discussed in the following technote section: Avoid synchronizing a store with multiple persistent containers. The technote is about NSPersistentCloudKitContainer. As of today, SwiftData (DefaultStore) + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Basically, the use case of sharing a CloudKit-back store between a main app and its extension and synchronizing with NSPersistentCloudKitContainer isn't quite supported, and so you might consider avoiding do that. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Aug ’25
NSPersistentCloudKitContainer - Import failed with error: Error Domain=NSCocoaErrorDomain Code=4864
The NSPersistentCloudKitContainer synchronization between core data and iCloud was working fine with phone 15.1. Connected a new iPhone iOS 15.5, it gives error: CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2504): : Observed context save: - 2022-12-05 13:32:28.377000-0600 r2nr[340:6373] [error] error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _importFinishedWithResult:importer:](1245): : Import failed with error: Error Domain=NSCocoaErrorDomain Code=4864 *** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61) UserInfo={NSDebugDescription=*** -[NSKeyedUnarchiver _initForReadingFromData:error:throwLegacyExceptions:]: incomprehensible archive (0x53, 0x6f, 0x6d, 0x65, 0x20, 0x65, 0x78, 0x61)} CoreData: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _importFinishedWithResult:importer:](1245): : Import failed with error: Error Domain=NSCocoaErro
2
0
1.1k
Aug ’25
Reply to CoreData in Swift Packages
This was helpful, I wasn't able to find much this failure. The formatting of your code block didn't work, lets see if I can paste your snippet and get the formatting better: let bundle = Bundle.module let modelURL = bundle.url(forResource: ModelName, withExtension: .momd)! let model = NSManagedObjectModel(contentsOf: modelURL)! let container = NSPersistentCloudKitContainer(name: ModelName, managedObjectModel: model) My situation was a little different, a test case target that wasn't finding the model for some reason, and Bundle.main wasn't right, that was some test runner process embedded in Xcode.app, . To find the right one I have to dive into allBundles with let bundle = Bundle.allBundles.first(where: { $0.bundleURL.pathExtension == xctest }): guard let bundle = Bundle.allBundles.first(where: { $0.bundleURL.pathExtension == xctest }) else { fatalError(can't find test bundle containing model) } guard let modelURL = bundle.url(forResource: Storage, withExtension: .momd) else { fatalError(can't find
Jul ’25
Reply to CloudKit Sharing Not Working with Other Apple IDs (SwiftData + SwiftUI)
Thanks a lot, Ziqiao, for your quick response. You’re absolutely right – I now realize that .shared CloudKit containers are not yet supported with SwiftData. In my implementation, I attempted to use a SwiftData model with a ModelContainer(for:sharing:) configuration and used UICloudSharingController to manage sharing between Apple IDs. The ModelContainer was configured like this: @main struct FoodGuardApp: App { var body: some Scene { WindowGroup { ContentView() } .modelContainer(for: FoodItem.self, configurations: [ ModelConfiguration(Default, cloudKitDatabase: .shared) ]) } } The sharing worked locally (between users in the same Apple ID), but failed when another Apple ID accepted the share, producing this error: CKError: Bad Container (5/1014) Couldn't get container configuration from the server for container iCloud.com.de.seki.FoodGuard Based on your reply and DTS confirmation, I now plan to migrate my project to Core Data + CloudKit, using NSPersistentCloudKitContainer and UICloudSharingControll
Jul ’25
Widget error upon restore iPhone: The file "Name.sqlite" couldn't be opened
I have an app that uses NSPersistentCloudKitContainer stored in a shared location via App Groups so my widget can fetch data to display. It works. But if you reset your iPhone and restore it from a backup, an error occurs: The file Name.sqlite couldn't be opened. I suspect this happens because the widget is created before the app's data is restored. Restarting the iPhone is the only way to fix it though, opening the app and reloading timelines does not. Anything I can do to fix that to not require turning it off and on again?
12
0
256
Jul ’25
Reply to Widget error upon restore iPhone: The file "Name.sqlite" couldn't be opened
I'm sorry, I thought I'd already replied to this... destroyPersistentStore isn't the right API that deletes the data lol Can you clarify what you mean by destroy those CoreData objects? What I mean by destroy here is get rid of your reference to the read/write NSPersistentCloudKitContainer object. That will then: Free up some memory (minor benefit). Ensure that you can't accidentally get a read/write object reference, since your app won't have a reference to the object that COULD have given you one. (major benefit). In code level terms, this would mean either NULL out a var reference or having the let go out of scope. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
Jun ’25
iCloud sync issues using NSPersistentCloudKitContainer for Core Data + CloudKit sync.
I have tried to set up iCloud sync. Despite fully isolating and resetting my development environment, the app fails with: NSCocoaErrorDomain Code=134060 (PersistentStoreIncompatibleVersionHashError) What I’ve done: Created a brand new CloudKit container Created a new bundle ID and app target Renamed the Core Data model file itself Set a new model version Used a new .sqlite store path Created a new .entitlements file with the correct container ID Verified that the CloudKit dashboard shows no records Deleted and reinstalled the app on a real device Also tested with “Automatically manage signing” and without Despite this, the error persists. I am very inexperienced and am not sure what my next step is to even attempt to fix this. Any guidance is apprecitated.
1
0
181
Jun ’25
NSPersistentCloudKitContainer causes crash on watchOS when device is offline
Hi. I'm hoping someone might be able to help us with an issue that's been affecting our standalone watchOS app for some time now. We've encountered consistent crashes on Apple Watch devices when the app enters the background while the device is offline (i.e., no Bluetooth and no Wi-Fi connection). Through extensive testing, we've isolated the problem to the use of NSPersistentCloudKitContainer. When we switch to NSPersistentContainer, the crashes no longer occur. Interestingly, this issue only affects our watchOS app. The same CloudKit-based persistence setup works reliably on our iOS and macOS apps, even when offline. This leads us to believe the issue may be specific to how NSPersistentCloudKitContainer behaves on watchOS when the device is disconnected from the network. We're targeting watchOS 10 and above. We're unsure if this is a misconfiguration on our end or a potential system-level issue, and we would greatly appreciate any insight or guidance.
2
0
127
Jun ’25
Reply to NSPersistentCloudKitContainer causes crash on watchOS when device is offline
Hi, and thank you for the quick response. It's greatly appreciated! Unfortunately, this crash does not appear to generate a crash log. However, we're able to reproduce it consistently on two separate Apple Watch devices. When using NSPersistentCloudKitContainer and the device is offline (no Wi-Fi and no Bluetooth), the app crashes when entering the background. If we switch to NSPersistentContainer, no crash occurs under the same conditions. If the device is online, no crash occurs, even when using NSPersistentCloudKitContainer and allowing the app to enter the background. If we keep the app in the foreground (e.g., by continuously tapping the screen), the app also does not crash, even when offline and using NSPersistentCloudKitContainer. So in summary, the crash consistently occurs under the following three conditions: Using NSPersistentCloudKitContainer Device is offline (no Wi-Fi, no Bluetooth) App transitions to the background. We would appreciate any insight, particular
Jun ’25
Reply to Widget error upon restore iPhone: The file "Name.sqlite" couldn't be opened
Thank you, this is very helpful. To confirm we're aligned: Open the database in read-only mode If loadPersistentStores fails, try it again in read-write mode If that succeeds destroy those CoreData object and do a read-only open again If that fails show an error message to the user destroy those CoreData object Is that accomplished via container.persistentStoreCoordinator.destroyPersistentStore, so all together like so? let container = NSPersistentCloudKitContainer(name: AppName) let sharedStoreURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: group.com.domain.appname)!.appendingPathComponent((container.name).sqlite) guard FileManager.default.fileExists(atPath: sharedStoreURL.path) else { // Show error to user return } let description = container.persistentStoreDescriptions.first! description.url = sharedStoreURL description.isReadOnly = true container.loadPersistentStores { description, error in if let error { container.persistentStoreDescriptions.first?.isReadOnly = fals
Jun ’25
Reply to Widget error upon restore iPhone: The file "Name.sqlite" couldn't be opened
It's interesting huh! One option would be to simply delete the file and let CoreData pull the data from the cloud … you might want to consider just excluding the file from the backup entirely I think this is not an option because the user can turn off iCloud and NSPersistentCloudKitContainer still works to store data without syncing to iCloud. So not all users can get this data back from iCloud, it may only exist in their backup. What does your app actually do and, most importantly, what if any background modes/work does it use? You can think of it as a very simple todo app where you create a todo, it shows up in the widget, and tapping a button marks it complete (via the main app process). Note the widget's access to the database is read-only and cloudKitContainerOptions is not set so the widget extension process does not sync with iCloud (only the main app process does). The only background modes/work used in the app is the remote notifications capability that allows CloudKit to silently notify the
Jun ’25
Reply to Old CloudKit Data Repopulating after a Local Reset
SwiftData + CloudKit doesn't expose any CloudKit data structure, and so you will need to purge the data with your own code. Given that today's SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, I'd consider the following flow: Set up an NSPersistentCloudKitContainer instance and use it to load the SwiftData store. Fetch an object from the store, and retrieve the CloudKit record ID using recordIDForManagedObjectID:. From there, you can grab the record's zoneID. Call purgeObjectsAndRecordsInZoneWithID:inPersistentStore:completion: with the record zone ID to purge the local and remote data. Release all the Core Data objects. With that, you should be able to get an empty store, use it to set up a new SwiftData model container, and start your app from the beginning. Best, —— Ziqiao Chen  Worldwide Developer Relations.
Jun ’25
Reply to Widget error upon restore iPhone: The file "Name.sqlite" couldn't be opened
Do you check if the store URL you pass to NSPersistentCloudKitContainer is valid in the failure case, and if the URL is exactly the same as the one in the successful case (after you restart your iPhone)? I am wondering if the system returns you the right root path of the App Group container after you restore from backup... Best, —— Ziqiao Chen  Worldwide Developer Relations.
Jun ’25
NSPersistentCloudkitContainer Memory Leak -> Crash? (iOS 15 beta 4 & 5)
Background I have an established app in the App Store which has been using NSPersistentCloudkitContainer since iOS 13 without any issues. I've been running my app normally on an iOS device running the iOS 15 betas, mainly to see problems arise before my users see them. Ever since iOS 15 (beta 4) my app has failed to sync changes - no matter how small the change. An upload 'starts' but never completes. After a minute or so the app quits to the Home Screen and no useful information can be gleaned from crash reports. Until now I've had no idea what's going on. Possible Bug in the API? I've managed to replicate this behaviour on the simulator and on another device when building my app with Xcode 13 (beta 5) on iOS 15 (beta 5). It appears that NSPersistentCloudkitContainer has a memory leak and keeps ramping up the RAM consumption (and CPU at 100%) until the operating system kills the app. No code of mine is running. I'm not really an expert on these things and I tried to use Instruments to see i
25
0
13k
Jun ’25