Looks like the CloudKit sync issue in *OS 26.4 is real (I can repro with all of my apps), and has the very distinct potential to lead to catastrophic data loss and/or sync conflicts across effectively all apps. Apps only receive changes from the cloud after being quit and relaunched.

If Apple hasn't pulled 26.4 already, it should do so immediately until there's a fixed build

https://mastodon.social/@lukaskubanek/116299581006179836

@stroughtonsmith I tend to disagree. Error handling is mandatory for an app using CloudKit and I can’t see how it could lead to “catastrophic data loss”. Remote notifications have never been reliable. This is a best effort service?
@slizeray @stroughtonsmith I also don’t see how it can lead to data loss because apps should handle duplication / conflict resolution when using CloudKit. But the current issue leads to bad user experience because apps just don’t have any idea of it and people will see their apps out of sync.
@alpennec @slizeray there's a lot of things that CloudKit developers 'should' be doing that CloudKit developers aren't doing because developing CloudKit apps is way harder than it needs to be. If you think everybody using CloudKit has robust merge conflict support, I have a bridge to sell you
@stroughtonsmith @alpennec CKSyncEngine has greatly simplified the integration with CloudKit and the error handling though. It was way more difficult before, I would say almost impossible before.
@slizeray @alpennec last I heard, people were still recommending to avoid CKSyncEngine. I just saw @bigzaphod remove it from Tapestry last week. I've long-fingered it for years myself because nobody had a glowing recommendation to give it
@stroughtonsmith @alpennec @bigzaphod oh I just see the reason. There are several issues here.
The first one is not related to CKSyncEngine but to the replay API of CloudKit.
The second one is that you have options when fetching changes to fix this issue (Scope + prioritizedZoneIds) but it is supposed you designed your schema accordingly. And it didn’t exist with CKFetchRecordZoneChangesOperation only with CKSyncEngine…
The third issue is that you can’t use ZoneOptions.desiredKeys
@stroughtonsmith @alpennec @bigzaphod So I agree, there is room for improvement with CKSyncEngine. I filed a feature request yesterday… I have no reason to think that anyone at Apple will pay attention though.
@stroughtonsmith @alpennec @bigzaphod The Feedback filed under FB22338675 asks to extend CKSyncEngine.FetchChangesOptions.Scope with a new case case allExcludingRecordTypes([CKRecord.RecordType]) so you can migrate records to new Zones and ignore the old ones…