Search results for

NSPersistentCloudKitContainer

589 results found

Post

Replies

Boosts

Views

Activity

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
NSPersistentCloudKitContainer - Import failed because applying the accumulated changes hit an unhandled exception
When I use NSPersistentCloudKitContainer to sync data, I receive error Code=134421/134406 Import failed because applying the accumulated changes hit an unhandled exception. iOS/iPadOS 15 beta 5 - iOS/iPadOS 15 beta 7(latest) When this error appears, data can not be import/merged from iCloud. Delete app and reinstall is not working. Same momd on macOS 12(Catalyst, with full data upgrated from macOS 11) works fine. Maybe a system bug? Merge Policy: context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy context.automaticallyMergesChangesFromParent = true Console log here: CoreData: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _requestAbortedNotInitialized:](1826): - Never successfully initialized and cannot execute request ' B7974D4D-C5DA-413E-AE3B-072C88D38D47' due to error: Error Domain=NSCocoaErrorDomain Code=134421 Import failed because applying the accumulated changes hit an unhandled exception. UserInfo={NSLocalizedFailureReason=Import failed because applying the accumulated cha
15
0
7.2k
Aug ’21
Reply to Not receiving Persistent Store Remote Change Notification.
By mistake i set the store descriptions inside if (error ! = nil) I changed that... yet no go... - (NSPersistentCloudKitContainer *)persistentContainer { // The persistent container for the application. This implementation creates and returns a container, having loaded the store for the application to it. @synchronized (self) { if (_persistentContainer == nil) { _persistentContainer = [[NSPersistentCloudKitContainer alloc] initWithName:@Expenses]; [_persistentContainer loadPersistentStoresWithCompletionHandler:^(NSPersistentStoreDescription *storeDescription, NSError *error) { if (error != nil) { #ifdef DEBUG NSLog(@Unresolved error %@, %@, error, error.userInfo); #endif abort(); } else #ifdef DEBUG NSLog(@Store successfully initialized); #endif [storeDescription setOption:[NSNumber numberWithBool:YES] forKey:@PersistentHistoryTracking]; [storeDescription setOption:[NSNumber numberWithBool:YES] forKey:@NSPersistentStoreRemoteChangeNotificationOptionKey]; }]; } } return _persistentContainer;
Aug ’22
Reply to NSPersistentCloudKitContainer with Mac Catalyst
I have this problem where your crash originates on the queue:com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export (serial)This might be the same problem you are speaking of.I reported it to Apple (no solution yet).But important point is: It seems to happen only in debug mode. I have released an app with NSPersistentCloudKitContainer and it does not crash in production.
Topic: App & System Services SubTopic: General Tags:
Apr ’20
CloudKit + NSPersistentCloudKitContainer: CKError "Service Unavailable" (6/2022); "Request failed with http status code 503"
I am developing a macOS and iOS application that uses NSPersistentCloudKitContainer to sync data across devices. For about an hour, I was able to successfully save records to the CoreData container and have them sync successfully with CloudKit. After further testing, I began receiving errors similar to the following: CoreData: error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _exportFinishedWithResult:exporter:](1347): : Export failed with error: Now any device that tries to save records to CloudKit will get this error and I am unable to continue developing my iCloud sync features. Note that I am currently in Development environment with a new iCloud container, and do not yet have any users or pushed these changes to production. I have tried the following: Reinstall the application Restart all devices Logging out and back into iCloud from devices Updating my AppleID to use a single new iCloud container identifier from the developer portal as suggested in a comment here: https://developer.apple
1
0
1.4k
May ’22
[NSPersistentCloudKitContainer][Mac Catalyst specific crash] app is constantly crashing within a minute or two
Core Data, Catalyst, CloudKIt engineers need your assistance. I have an app that uses NSPersistentCloudKitContainer. It works great on iOS, but on the mac (Catalyst), the app is constantly crashing and is unusable. The CloudKit scheduler com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export seems to be at fault. It's crashing inside a generic dispatch block, so it's impossible to debug. Found a similar thread: https://developer.apple.com/forums/thread/128131?page=1 This is on Catalina 10.15.5 (19F101). MacBook Pro (Retina, 13-inch, Early 2015) Any ideas on how to debug/solve the root cause of this issue? Here's the image of the crash report (image hosted on imgbb.com): ibb.co nQy6rwm Thread 19 Queue : com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export (serial) #0 0x00007fff73de0436 in __xpcactivitydispatchblockinvoke.109.cold.3 () #1 0x00007fff73dde82b in _xpcactivitydispatchblockinvoke.109 () #2 0x000000010040f844
1
0
925
Aug ’20
Reply to swiftUI apps with SwiftData and CloudKit crashes on iOS but works on MacOS
It seems to me that your code creates a persistent CloudKit container (NSPersistentCloudKitContainer) and a SwiftData model container (ModelContainer), and that both containers use the same model and manage the same store, which triggers a conflict. This is discussed in Avoid synchronizing a store with multiple persistent containers. Assuming that you have correctly configured CloudKit in your project, when you create a SwiftData model container with the default configuration (ModelConfiguration), SwiftData creates a NSPersistentCloudKitContainer under the hood, which automatically synchronizes the data store for you, and so you don't really need to create the persistent CloudKit container. Is there any special reason why you need a persistent CloudKit container and a SwiftData model container simultaneously? Best, —— Ziqiao Chen  Worldwide Developer Relations.
Jun ’24
Reply to CloudKit stopped syncing on WatchOS
What does a sysdiagnose from the watch tell you about your process' activity? i.e. Is it receiving push notifications? Are NSPersistentCloudKitContainer's activities being run? Reviewing this WWDC session may be helpful for interpreting the logs: https://developer.apple.com/videos/play/wwdc2022/10119/
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’23
Reply to SwiftData via CloudKit Only Syncing Upon Relaunch
There is an eventChangedNotification on NSPersistentCloudKitcontainer. You can add a notification/listener to your view/Observable class and re-fetch data like so: import CoreData import SwiftData import CloudKit @Observable class ListViewModel { var cloudkitNotificationPublisher = NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) func handleCloudkitNotification(_ notification: NotificationCenter.Publisher.Output) { if let userInfo = notification.userInfo, let event = userInfo[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { if event.type == .import { // fetch entities/models here } } } } And then in your view, you can attach an .onReceive(_:) modifier to your view, passing in the publisher var body: some View { VStack { // my list here } .onReceive(listViewModel.cloudkitNotificationPublisher) { publisher in listViewModel.handleCloudkitNotification(publisher) } } More information can be found here: ht
Jul ’24
Reply to NSPersistentCloudKitContainer losing data
I see folks implement an in-app toggle to enable / disable CloudKit synchronization when using NSPersistentCloudKitContainer. I honestly don't see that a great idea. I know this is controversial, and so would layout my reasoning here: First, the system already provides a setting (Settings > Apple ID > iCloud) that allows users to turn on / off iCloud for an app. If a user turns off iCloud for an app with the setting, the app won’t be able to synchronize with CloudKit, even the in-app toggle is on. Secondly, for the toggle to work, the app needs to release the Core Data objects currently in use, and reload the Core Data stack. In your case, you achieve that by asking the user to restart the app, which is probably not a great experience. Last but probably more importantly, CloudKit implements access control on its data: only the store owner (the user who owns the login iCloud account when the store is created) can access a store associated with a CloudKit private or shared database, and only the
Sep ’24
Reply to NSPersistentCloudKitContainer Bug
I wanted to follow up on this statement in my first post for any other readers: the root NSManagedObject's record is not being updated with the relationship linkage to the shared record. I figured out later that this is because there are 2 different ways to do shares: you share Records or Zones. The new share functionality in NSPersistentCloudKitContainer appears to be creating full Zone shares unlike the code documented on CKShare. When the Zone share is made there are no relationships created on the records in the zone because they are all made available to the Participants. In terms of the bug with local ckshare being updated, that is still an issue. I haven't tested the suggestion by Fat Xu yet and in the meantime I had to query CloudKit directly (not thru NSPersistentCloudKitContainer) for the most recent ckshare records.
Sep ’21