NSPersistentCloudKitContainer

Since Swift Playground 4.6, as you have observed, it is no longer possible to import PlaygroundSupport because the PlaygroundSupport framework provides no functionality to app playgrounds. However, starting in Swift Playground 4.6, you can conditionalize code with the SwiftPlaygrounds condition: #if SwiftPlaygrounds container = NSPersistentContainer(name: myApp, managedObjectModel: Self.createModel()) #else container = NSPersistentCloudKitContainer(name: myApp) #endif

I have done research on serial port communication using a macOS app a little bit ago but it seems like I will need to use a Command-line tool program. Is this correct? If I do go the Command-line tool route I will have to use cktool I believe. Will cktool allow me to use NSPersistentCloudKitContainer or similar command to allow a silent notification type fetch data system?

You missed his point. Data entereed after setting up NSPersistentCloudKitContainer synced. It was pre-existing data which did not sync. For a person with a core data app who wants to use CloudKit, this problem is huge. And I'll bet that the original author signed up for remote notifications. It's not that he didn't get a notification, he didn't get the data.

@micho2, to achieve CloudKit integration you should be able to change the persistentContainer property like so... var persistentContainer: NSPersistentContainer = { ttttlet container = NSPersistentCloudKitContainer(name: SampleApp) tttttt // change this line container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { ttttttttfatalError(Unresolved error (error), (error.userInfo)) } }) ttttcontainer.viewContext.automaticallyMergesChangesFromParent = truetttttttt // add this line return container }() although I've not tested this yet!

It's hard to tell if Apple uses Core Data and CloudKit, but my guess is that they do. I'm not really sure what you mean by reordering items but I can tell you that using Core Data and CloudKit is very straightforward, just search for NSPersistentCloudKitContainer for using CloudKit and for Core Data I highly recommend you to watch the following tutorials; they're great. Swiftful Thinking: https://www.youtube.com/watch?v=BPQkpxtgalY

The issue you described can be that: SwiftData + CloudKit doesn't import the change from the CloudKit server. SwiftData + CloudKit does import the change, but Query doesn't update the data. I believe these were discussed in the following posts, respectively: CoreData + CloudKit synchronization is very unstable & unreliable Swiftdata using an existing CloudKit container, how to listen to the NSPersistentCloudKitContainer's NSPersistentStoreRemoteChange event Best, —— Ziqiao Chen  Worldwide Developer Relations.

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

So I believe I am overthinking it!lazy var persistentContainer: NSPersistentCloudKitContainer = { let container = NSPersistentCloudKitContainer(name: Model) let storeLocation = URL(fileURLWithPath: /path/to/cloud.store) let storeDescription = NSPersistentStoreDescription(url: storeLocation) //Set the container options cloudStoreDescription.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: com.myCompany.myApp2) // TODO: Migrate Core Data Store to new Model Version container.loadPersitentStores... ... }()This should be enough to handle the migration from Container 1 to 2, since the data is already stored in Core Data. Then instead of hooking up a persistent container to the old CloudKit container (which would probably throw errors due to mismatched Schema), we can use CloudKit to fetch and confirm all data has already transfered properly, fix missing data, and delete the recrods in Container 1.I decided not to Migrate Containers for this, instead Im using ver

adding to Claude31, SwuiftUI's @FetchedResults, and the underlying NSFetchedResultsController, are IMHO a key reason to adopt CoreData: changes in the background at the model layer get signaled to the main thread view layer, which can then be dynamically updated. The other reason to use CoreData is enabling device-to-device synchronization (for a user with multiple devices, or data shared between users) via NSPersistentCloudKitContainer (or an open-source sync engine like CloudCore).

SwiftData + CloudKit integration doesn’t support CloudKit sharing as of today. I haven’t tried to implement SwiftData + CloudKit sharing with my own effort, but based on my understanding on the technologies, if the object graph to be shared is relatively complicated, I'd consider sticking with NSPersistentCloudKitContainer (Core Data), because NSPersistentCloudKitContainer interacts with Core Data, and using SwiftData adds another layer of complexity. If the data to be shared is quite simple, such as a small set of values without relationships, and I have built my app with SwiftData, I might consider using CloudKit API directly to implement the sharing flow. That way, I completely control the synchronization and sharing process, and can share any data type, including SwiftData. For the first option, you can start with the following sample: Sharing Core Data objects between iCloud users The second option may turn out a bit involved. You can start with the technical resources mentioned in the

... was cancelled because there is already a pending request of type 'NSCloudKitMirroringExportRequest... This message doesn't quite matter, as discussed in Execute the export. After some time the sync fails again for no obvious reason and here is the error that appears in the console for a Mac app To get to the bottom in this situation, you might still want to look into a sysdiagnose. The whole analysis process is discussed in TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Just utilizing the container doesn't enable the sync. You have to add/request the capabilities throuigh your plist file (iCloud under capabilities, may require background too, but i'm unsure). Pretty sure you need remote notifications as well. I read on a blog somewhere a step by step to get it working, but I haven't found 'Official' instructions for anything more than the class declaration yet. I 'think' I googled NSPersistentCloudKitContainer and tutorial.. or maybe getting started.

The presenter at WWDC 2019 (Nick Gillett) mentioned that Apple maintains a custom Zone in the private database (around 10:50 in the video).Since records get saved in the private database, I would think that CKShares and NSPersistentCloudKitContainer are a no-go combo.But, according to Apple's documentation, you can access the CKRecord for a specific managed object using dedicated methods, which will allow you to create CKShares: https://developer.apple.com... So I am confused.

I’ve considered turning textString into a to-many relationship by creating a Token entity but I’m unsure whether this will significantly increase overhead? I expect my database to grow very large unless I apply unique constraints on tokens and handle the CloudKit syncing myself (not using NSPersistentCloudKitContainer). Also in my app if many results are fetched (between 1000 to 100,000 matches) from the predicate I will need to perform an additional filter that can only be done in-memory, in this scenario would I need to perform both the predicate and filter in batches?

@Engineer Thanks for sharing the sample project. It shows several examples how to use CloudKit, however, it doesn't include a Widget Extension or any references to WidgetKit. Is there another project that showcases this concrete use case, updating the same Core Data objects from both a Widget and an app? @Jordan wrote in 2022: Do note they also said NSPersistentCloudKitContainer does not support multi-process sync so only your app should be attempting to sync. And even if a widget were to attempt sync, it’ll never really be able to because iOS doesn’t give it enough time to execute, and widgets don’t run in the background they’re only running when they need to get more timeline entries for example, and widgets don’t get the app’s push notifications which is what enables background syncs to be scheduled. Your app will need to try to keep the widget up to date as opposed to the widget attempting to sync and keep itself up to date. Is this (still) correct (in 2025)? If so, then any attempt to update Cor