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

New Issue

adam · 2025-12-29T15:30:31+01:00

adam commented

2025-12-29 15:30:31 +01:00

Originally created by @CocodingLee on GitHub (Nov 8, 2021).

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 ?

Originally created by @CocodingLee on GitHub (Nov 8, 2021). 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 ?

adam added the in progress label 2025-12-29 15:30:31 +01:00

adam commented

2025-12-29 15:30:32 +01:00

@JohnEstropia commented on GitHub (Jan 21, 2022):

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.

@JohnEstropia commented on GitHub (Jan 21, 2022): 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.

adam commented

2025-12-29 15:30:32 +01:00

@CocodingLee commented on GitHub (Jan 26, 2022):

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

Prototyping stage
Widget/Extensions storage-sharing support
CloudKit support

@CocodingLee commented on GitHub (Jan 26, 2022): So may I ask what is " CloudKit support" for which mentioned in road map section? Prototyping stage Widget/Extensions storage-sharing support CloudKit support

adam commented

2025-12-29 15:30:32 +01:00

@JohnEstropia commented on GitHub (Jan 26, 2022):

@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)

@JohnEstropia commented on GitHub (Jan 26, 2022): @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)

adam commented

2025-12-29 15:30:33 +01:00

@thebarndog commented on GitHub (Mar 7, 2022):

@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.

@thebarndog commented on GitHub (Mar 7, 2022): @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.

adam commented

2025-12-29 15:30:33 +01:00

@JohnEstropia commented on GitHub (Mar 8, 2022):

@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.

@JohnEstropia commented on GitHub (Mar 8, 2022): @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.

adam commented

2025-12-29 15:30:34 +01:00

@thebarndog commented on GitHub (Mar 8, 2022):

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.

@thebarndog commented on GitHub (Mar 8, 2022): > * 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.

adam commented

2025-12-29 15:30:35 +01:00

@JohnEstropia commented on GitHub (Mar 8, 2022):

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.

@JohnEstropia commented on GitHub (Mar 8, 2022): 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.

adam commented

2025-12-29 15:30:35 +01:00

@AzSiAz commented on GitHub (Jun 17, 2022):

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

@AzSiAz commented on GitHub (Jun 17, 2022): Interested in CloudKit too Maybe something like a [SyncKit](https://github.com/mentrena/SyncKit) adapter would be enough ?

Sign in to join this conversation.

Branches Tags

develop

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore#380