It seems related to encrypted fields. I can reproduce it both with CKSyncEngine and with CKDatabase.modifyRecords(…) where isAtomic is false. Still not sure what’s going on.
Has anyone seen unexpected .batchRequestFailed partial errors on non-atomic saves? Or when using CKSyncEngine, where non-atomic is the default?
#iCloud #CloudKit #CKSyncEngine #AdvancedDataProtection #E2EE
Finished migrating to #CKSyncEngine and I'm very happy with the results. This allowed me to remove some code. Also managed to fix a bug I had in how I handled record change tags.
Who's that guy reflected on the devices' screens though.
Migrating to #CKSyncEngine, one thing I can’t figure out is whether the CKServerChangeToken I currently save to keep track of what updates a particular app instance needs can be leveraged at all now that you have to save a value of type CKSyncEngine.State.Serialization.
I’m hoping that I can somehow convert the former to the latter. If I can’t do it, this would mean that the first time the app with CKSyncEngine runs it will fetch ALL changes from #iCloud when it actually has all the data.
Using #SwiftData, when I enable CloudKit in order to use #CKSyncEngine I start getting errors related to non-optional relationships in the model even though I disable automatic CloudKit syncing using ModelConfiguration(url: storeURL, cloudKitDatabase: .none).
I wouldn’t expect CloudKit to validate entities in a model container with CloudKit syncing set to none – is this expected, are there any open feedbacks?
#WWDC #WWDC23 #CloudKit #CKSyncEngine
I was curious to see the CloudKitSyncEngine presentation by @_tim______ since I recently published a related project. Did I get Sherlocked?
Looks like “no”. Design goals behind Canopy and CKSyncEngine are sufficiently different. Biggest difference being that Canopy thinks in terms of “request/response”, which is lower level than “sync”, and stateless.
I’ll write up something longer one day. Check out Canopy in the mean time.
