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 @slizeray I'm aware we have to do this merge conflict but I intentionally skipped this for my apps... But it depends on the app and the data model though. But it's a rabbit hole just to do it correctly with change tracking at every level (like they suggest in one of their old WWDC video).
@alpennec @stroughtonsmith @slizeray I'm doing record-level last modified wins (based on system clock). I know it's not technically perfect, but you're totally right it's a real rabbit hole to do something more elaborate.