SwiftData Configurations for Private and Public CloudKit

I did manage to save my Entities to CloudKit with SwiftData but the default database is the private database. I need to store some Entities in the private and other Entities in the public CloudKit database. How do I manage that with SwiftData? With CoreData I always used different configurations for both private and public and added the entities to one or the other.

Accepted Reply

ModelConfiguration so far lacks an NSPersistentCloudKitContainerOptions.databaseScope equivalent. Even if you were to divide data into two stores, it seems that the automatic CloudKit sync would still default to .private for both.

There is some discussion of coexistence between Core Data and SwiftData, with both accessing the same store. It might be possible to setup the Core Data side to perform the public database sync and the SwiftData side to operate as a reader of that store.

  • You are absolutely right. I digged deeper into this and found a message on slack from an Apple engineer that suggested to use Core Data for the config and SwiftData for accessing the container. There is a new tutorial video about migrating from Core Data to SwiftData which should also contain some information on how to implement this. Really disappointed to see that Apple is not pushing the shared and public database with this release. I hope for an enhancement release soon...

  • Disappointing, but not entirely unexpected, I guess. If you remember, the CloudKit Core Data sync rollout also started with Private only and then added Public and Shared over the next two years.

  • But given that they have solved this for CloudKit with CoreData and SwiftData, under the hood, is most likely calling through to those APIs, surely an additional attribute of "databaseScope: CKDatabase.Scope = .private" on the ModelConfiguration would solve the issue? Then we can use different ModelContainers for the different scopes. That allows us as developers to choose which container to use for which scope. I'm going to log this via Feedback as an enhancement before too many betas come out

Replies

Maybe using several ModelConfiguration objects and specifying a CloudKit container identifier for those:

https://developer.apple.com/documentation/swiftdata/modelconfiguration/init(_:schema:url:readonly:cloudkitcontaineridentifier:)

  • I can see the option to set a container. But I need to set the public or private option for this container like this… Apple docs

Add a Comment

So is the suggestion to initialize one CloudKit container as punlic and initialize another CloudKit container as private and then manage the data‘s destination accordingly? I mean, I guess this sounds ok. But is it a good approach? What might be some of the pitfalls?

ModelConfiguration so far lacks an NSPersistentCloudKitContainerOptions.databaseScope equivalent. Even if you were to divide data into two stores, it seems that the automatic CloudKit sync would still default to .private for both.

There is some discussion of coexistence between Core Data and SwiftData, with both accessing the same store. It might be possible to setup the Core Data side to perform the public database sync and the SwiftData side to operate as a reader of that store.

  • You are absolutely right. I digged deeper into this and found a message on slack from an Apple engineer that suggested to use Core Data for the config and SwiftData for accessing the container. There is a new tutorial video about migrating from Core Data to SwiftData which should also contain some information on how to implement this. Really disappointed to see that Apple is not pushing the shared and public database with this release. I hope for an enhancement release soon...

  • Disappointing, but not entirely unexpected, I guess. If you remember, the CloudKit Core Data sync rollout also started with Private only and then added Public and Shared over the next two years.

  • But given that they have solved this for CloudKit with CoreData and SwiftData, under the hood, is most likely calling through to those APIs, surely an additional attribute of "databaseScope: CKDatabase.Scope = .private" on the ModelConfiguration would solve the issue? Then we can use different ModelContainers for the different scopes. That allows us as developers to choose which container to use for which scope. I'm going to log this via Feedback as an enhancement before too many betas come out

Can someone from Apple say whether or not SwiftData will support private, public, and shared databases when it goes live with iOS 17? Or any information regarding when it will have support in the future?

I don't see the value in migrating "some" of my CoreData code to SwiftData as it just means I have two different APIs to worry about, and others on my team will have to learn both in order to support persistence.

Thanks.

Hi all. Any updates to this thread or new information anyone can add.