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.
Post not yet marked as solved
I was able to remove the warnings by registering a new value transformer. I'm persisting a CLLocation, which conforms to NSSecureCoding.
import Foundation
import CoreLocation
@objc(CLLocationValueTransformer)
final class CLLocationValueTransformer: NSSecureUnarchiveFromDataTransformer {
static let name = NSValueTransformerName(rawValue: String(describing: CLLocationValueTransformer.self))
override static var allowedTopLevelClasses: [AnyClass] {
return [CLLocation.self]
}
public static func register() {
let transformer = CLLocationValueTransformer()
ValueTransformer.setValueTransformer(transformer, forName: name)
}
}
Adding CLLocationValueTransformer as the transformer name works without warnings. The value is synced properly via NSPersistentCloudKitContainer, verified on multiple devices.
NSPersistentCloudKitContainer only syncs to a private database, according to the published docs. No mention of public or shared CKDatabase.
The docs specificly mention accessing the CKRecord for use with Sharing.https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/reading_cloudkit_records_for_core_data?language=objc
Post not yet marked as solved
I've also run into this issue. In looking over the code for the sample app, the Used with CloudKit checkbox in the Model's Default configuration is unchecked.https://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_cloud?language=objcIf you check the checkbox, errors on Binary, UUID and Transformable fields are generated, as well as complaining about several default values. Perhaps then the errors in Xcode are just not finely tuned at this point? I'm going forward with the assumption the checkbox isn't actually needed unless there is more than one configuration.
