“NSPersistentCloudKitContainer”

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

You need to create a custom Core Data class and inject it into ContentView() I don‘t have a default file at hand but you can inject it like below let context = PersistentCloudKitContainer.persistentContainer.viewContext tt ContentView().environment(.managedObjectContext, context) Below my CloudKitContainer but you can simply change that to a regular PersistentContainer class import CoreData public class PersistentCloudKitContainer { tt tt// MARK: - Define Constants / Variables ttpublic static var context: NSManagedObjectContext { ttttreturn persistentContainer.viewContext tt} tt tt// MARK: - Initializer ttprivate init() {} tt tt// MARK: - Core Data stack ttpublic static var persistentContainer: NSPersistentCloudKitContainer = { tt ttttlet container = NSPersistentCloudKitContainer(name: Container_Name) ttttcontainer.loadPersistentStores(completionHandler: { (storeDescription, error) in ttttttif let error = error as NSError? { ttttttt ttttttttfatalError(Unresolved error (error), (error.userInf

Ziqiao are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? In past we were told it could be used in all cases with history on, even if user was not allowing cloudkit. This was true until iOS 18 it seems now if that initializes and user is not using iCloud would it delete data. I thought I was seeing people talking about that and that it does that for security. if That is true that is a huge damn change and which Apple should tell people about?!

I'll make a guess you are implementing your App struct as if it were a class and accidentally creating a new instance of NSPersistentCloudKitContainer every time SwiftUI recreates the struct. You could access the persistent container lazy property through a @UIApplicationDelegateDelegateAdaptor so it is only created once. import SwiftUI import CoreData @main struct MasterDetailApp: App { t@UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate tt ttvar body: some Scene { ttttWindowGroup { ttttttContentView().environment(.managedObjectContext, appDelegate.persistentContainer.viewContext) tttt} tt} }

An app and its extensions can share a SwiftData store located in a shared App Group container. The following Apple sample demonstrates that: Adopting SwiftData for a Core Data app The discussion in this post may help as well, if you have any data update issue. CloudKit integration adds more complexity on this topic. You can start with checking if this post helps. SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Best, —— Ziqiao Chen  Worldwide Developer Relations.

If you are trying to use an App Group container to share a database between your iOS app and an WatchKit extension, that won't work because the iOS app runs on iPhone and the WatchKit extension runs on the paired watch, and an app ground container can't be cross devices. You will have to synchronize the data across the devices with your own code. As Nick points out, you can try with NSPersistentCloudKitContainer, you can also use CloudKit directly to synchronize the data you need. WatchConnectivity is not recommended if you want your watch app to be standalone.

hi, since you are using NSPersistentCloudKitContainer, you might want to take a look at Apple's page on Linking Data Between Two Core Data Stores. this provides a mechanism so that you can load up what i think you are calling base values in a local store, separate from the store that is mirrored to iCloud. this would solve the problem of loading base values on one machine, moving them into the cloud, and then trying to figure out on a second device how to prevent them from being reloaded from iCloud. hope that helps, DMG

Why don't you use `if #available` ? lazy var persistentContainer: NSPersistentContainer = { if #available(iOS 13.0, *) { let container = NSPersistentCloudKitContainer(name: Shopping_App) container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } }) return container } else { let container = NSPersistentContainer(name: Shopping_App) container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } }) return container } }()

Well something changed since we switched to iOS 18 SDK and it definitely did not work this way in earlier versions of iOS. At some point after iOS 15 SDK something changed and the cleaning process you mentioned is literally wiping users data and if it was never in iCloud in the first place it is totally gone now?! We have always used an NSPersistentCloudKitContainer since we first implemented it years back regardless of if the person enabled iCloud (in our App or not). This was based on statements Apple Engineers made in the past that you could always use NSPersistentCloudKitContainer since it was subclass of nspersistentcontainer and with History on but options set to nil for NOT ALLOWED. But now it seems that users running iOS 18 and who did not allow us to use iCloud (are getting data wiped). It is not clear if they are entirely logged out of iCloud or just have iCloud Drive off or what, but something is different in iOS 18. I really need a way to zero in on what is going on. This is one

How important is user privacy? How important is security? How are you planning to pay for cloud services like FireBase or AppWrite? I choose CloudKit (and CoreData), time and again, because, user data is private and secure by default, the capability to share between users is built in on top of that privacy and security, and users pay for their own cloud storage, not me. In 2019, Apple introduced a sync system between the CloudKit and CoreData, called NSPersistentCloudKitContainer, which might server you well. If you want more control, check out CloudCore. And for Android, check out cloudkit_flutter. fwiw

Adding a CKAsset field for a Core Data String attribute is as designed. It is because the size of a CloudKit record (not counting assets) is limited to 1MB, while a Core Data attribute has no size limit. What ChatGPT said is basically right – When the size of a Core Data String attribute exceeds a certain value, NSPersistentCloudKitContainer converts it to a CKAsset object in the data transformation process. Whether the value is about 1KB or not is not formally documented though. Best, —— Ziqiao Chen  Worldwide Developer Relations.

This thread provides an example of a SwiftUI + Core Data setup: https://developer.apple.com/forums/thread/650876 To clarify some terms: Core Data is a framework for local persistence and CloudKit can be seen as a transport technology that deals with storing data in iCloud. If you want to store objects from Core Data in iCloud, you can implement the syncing behavior on your own or make use of NSPersistentCloudKitContainer, a class that automatically mirrors changes in a local Core Data container to iCloud and keeps each device up-to-date.

Yeah, if you are using NSPersistentCloudKitContainer, NSPersistentCloudKitContainer.Event is the API that provides you the activity status. If you are using the CloudKit framework, a CloudKit operation triggers its completion handler, and so you can get the status from there. Note that the status you get from the mentioned APIs doesn't tell whether your local cache is synchronized with the server or not, because it is perfectly possible that a new change has been made on the server version immediately before you get notified that an activity / operation is completed. Best, —— Ziqiao Chen  Worldwide Developer Relations.

OK so it turns out that setting my store descriptions to be added asyncrounsly was the issue. I was hoping it would parallelize the adding of multiple stores within a larger synchronous operation, but the implications are wider. The entire loadPersistentStores method becomes asynchronous, in my experience.It did create two scemas. One in each iCloud container. The problem is that schema designer, isn't capable of supporting multiple iCloud container configurations. And that makes sense because there is nowhere in the schema designer to set the iCloud container IDs. So it will simply complain that CloudKit backed configurations need to have the same entities in them. You'll see a lot of errors like this...xcdatamodel: error: CloudKit Integration: Container.children destination entity ContainerRelation is missing from these configurations: Appture, CloudDataKit.Both configurations Appture, and CloudDataKit have CloudKit enabled for each, and each only has a single entity in it, with zero relations.So it's proba