“NSPersistentCloudKitContainer”

Did you get this to work? I have a similar need, that is, to offer iCloud storage and sync as a premium feature. I have CloudKit sync working but how do I switch it off? I want to disable CloudKit sync and only enable it when a customer pays for the premium version. I've tried setting the container's cloudKitContainerOptions property to nil but CloudKit sync still happens.Here's my Core Data stack:private lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: modelName) let localDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(local.sqlite, isDirectory: false)) localDescription.configuration = Local let cloudDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(cloud.sqlite, isDirectory: false)) cloudDescription.configuration = Cloud cloudDescription.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: cloudKitContainerIdentifier) cloudDescrip

When there's a crash in WidgetKit, it often goes unnoticed by developers and users because there's no clear indication within the widget itself. In contrast, a crash in the main app is more apparent because it causes the app to close suddenly. One theory, as discussed in this https://developer.apple.com/forums/thread/668649, is that the main app and the widget are attempting to perform a migration simultaneously. However, I'm skeptical of this theory because our last CoreData migration began last year. Therefore, it's surprising to see a high number of crashes after a year. Here's where fatal error occurs. It is a pretty standard CoreData stack used in widget. private static func setupNSPersistentContainer() -> NSPersistentContainer { precondition(Thread.isMainThread) let container = NSPersistentCloudKitContainer(name: xxx, managedObjectModel: NSManagedObjectModel.xxx) // Integrate AppGroup with CoreData. If we are assigning a new store description to CoreData, it is important // to finish all sto

Not an answer I’m afraid, but perhaps a related problem. They’ve definitely changed something deep at the OS level which is even affecting the CloudKit syncing of apps built with the iOS 14 SDK many months ago (ie. my app!) if run on an iOS 15 device, let alone apps built with the iOS 15 SDK! This failure of syncing started to occur when iOS 15 beta 4 was released - prior to this it was all working normally, as it did in iOS 13 & iOS 14. From beta 4 the entire structure of the console log outputs for NSPersistentCloudKitContainer changed, so something fundamental changed with CloudKit at this time. In my case, it seems it has trouble syncing Core Data relationships and NSPersistentCloudKitMirrorringDelegate gets stuck in a loop causing CPU & RAM consumption to rise uncontrollably, with the OS killing the app shortly afterwards. No syncing occurs. My Core Data structure has not changed since iOS 14 and my app synced (and still does) just fine on iOS 14 devices. Other than a reply from a ‘Frame

I've already played with the samples and was able to share one by one or a set of records. BUT, let me rephrase, I have a set of entities that I want to share ONCE between invited users with ONE sharing at the top. Could you confirm that is it possible? If Yes, there is probably one missing step or misunderstood in the following code. In my understanding, based on the samples, to do this, I'm doing : 1/ on owner and participant : configure a NSPersistentCloudKitContainer with inside a databaseScope = .private store AND a databaseScope = .shared store 2/ on owner before presenting the UICloudSharingController: 2.1/ create a shared zone-wide share ID let shareRecordID = CKRecord.ID(recordName: CKRecordNameZoneWideShare, zoneID: zoneID) 2.2/ create or get an existing CKShare with: func getOrCreateShare() async throws -> CKShare { let zoneID = CKRecordZone.ID(zoneName: sharedZoneName) // Zone-wide share ID let shareRecordID = CKRecord.ID( recordName: CKRecordNameZoneWideShare, zoneID: zoneID ) // Try

More info: I have experimented with code similar to yours to initialize two CloudKit schemas with one single request on the single NSPersistentCloudKitContainer instance. It does indeed work, however,there are limitations with the Xcode schema designer which render the results, effectively useless. The problems start when you create multiple configurations in your schema model, that are declared to be used with CloudKit. The schema designer has no knowledge of container identifiers, nevermind multiple container identifiers. I discovered that as soon as I added a new CloudKit backed configuration and added a single new entity to it with zero relationships, my project no longer compiled. Xcode told me that I had to add the entities from the other CloudKit backed configuration to this new configuration with it's single isolated entity. Bizarrely, it never instructed me to add the new isolated entity to the previous CloudKit configuration. It was complaining about relationships in the older CloudKit conf