Do you have any plans to support CloudKit in the future （version 9.x.x?）

[CocodingLee]

at version 6.x.x delete CloudKit features , why ? and is there any plans to support it in future version , such as version 9.x.x ?

[JohnEstropia]

Just to clarify, CloudKit was never supported in Core Store. What was removed in 6.x.x was support for iCloud Storage (i.e. NSPersistentStoreUbiquitousContentNameKey and friends), which was deprecated by Apple since iOS 10.

[CocodingLee]

So may I ask what is " CloudKit support" for which mentioned in road map section?

Prototyping stage Widget/Extensions storage-sharing support CloudKit support

[JohnEstropia]

@CocodingLee Those are planned features but are in feasibility testing (thus Prototyping stage). At this point, CloudKit support is still unlikely since I am currently still playing with Widget/Extension shared stores (app groups)

[thebarndog]

@JohnEstropia I think what people are looking for, at a minimum, is the support of NSPersistentCloudKitContainer which handles all syncing to iCloud for you simply by changing from NSPersistentContainer to NSPersistentCloudKitContainer. Unfortunately, it doesn't look like CoreStore uses the more modern container api at all so that may be a big ask but it's been available since iOS 13 so it may be worth prioritizing.

[JohnEstropia]

@thebarndog Yes, I do understand that, but it's not as simple as just switching to NSPersistentCloudKitContainer:

• It's a common misconception, but remote synchronization is actually not built-in with NSPersistentCloudKitContainer. We still have to handle the synchronization of remote notifications via Persistent History Tracking.
• Persistent History Tracking's synchronization happens at the file level: persistent transactions are managed outside the app sandbox. So a common set of metadata to be designed for the broadcaster and receiver of events to follow. Basically, the broadcasters and receivers of events need to know how to handle these metadata. This is why I am prioritizing storage sharing between apps and extensions (i.e. NSPersistentHistoryTracking) before focusing on CloudKit.
• The biggest hurdle I'm having with CloudKit/NSPersistentCloudKitContainer itself is migrations, which is why we need most of our own metadata in the first place. CloudKit, and in effect NSPersistentCloudKitContainer as well, only supports lightweight migrations. CoreStore had always supported heavy custom migrations. There needs to be a separation of the two because people will misuse the existing APIs and expect them to work correctly.

Now the thing is, CoreStore's feature development had been based on the features I needed in my own projects. If CoreStore had more sponsors requesting for new features, I would have prioritized them against my other earning projects. That said, I also want this be published as soon as I can, and I actually have to plan my other projects to support CloudKit sync just to have a playground for CoreStore.

[thebarndog]

• It's a common misconception, but remote synchronization is actually not built-in with NSPersistentCloudKitContainer. We still have to handle the synchronization of remote notifications via Persistent History Tracking

I don't think that's true though. I have an app thats not using persistent history tracking, just NSPersistentCloudKitContainer and things sync just fine between multiple devices. History tracking is meant for merging and tracking changes between multiple stores and app targets IIRC.

[JohnEstropia]

I'd have to look into that again then, because there are issues like this before: https://developer.apple.com/forums/thread/120328

This may have been improved in recent iOS versions so I'll investigate again. In any case, CloudKit stores still have restrictions that will break CoreStore's existing API (ex: limited migrations, limited attribute types) and need to be separated.

[AzSiAz]

Interested in CloudKit too Maybe something like a SyncKit adapter would be enough ?