At the time, I considered building a startup around the technology, but in the end decided not to because I believed the market was too small.
It's been interesting watching the development of Core Data sync, and at least at this point, feel I made the right decision. Sync is an interesting problem, but you can nearly always build a specialized solution when you need to for your specific data model that is _much_ simpler than the "general" case, and that handles conflicts better.
Given how long Ensembles has been available (over two years), how much the developer charges for a commercial license (peanuts), and the fact that it's basically a "lifestyle" business for him, I think it's clear that there's not much of a market for object graph sync.
I mean if he's pulling in a couple million a year for just himself, that's incredible. That's the dream.
Honestly the whole thing was so gloriously bad compared with something like Firebase that I completely understand why Apple deprecated it.
The way it should have worked was as a virtual directory with a callback/event when users attempted to write data, allowing the app to accept, revise or reject the change. This could be done on either a first-come-first-served basis or consensus algorithm specified per-path. It could also be implemented as a nonblocking compare and swap (CAS) so that any contention would have to be decided live, and the user's event log would be stored locally and resume from the first conflict when the user reconnected to the internet. Unfortunately that requires a GUI working more like React that can update to reflect the current state (which most apps don't do properly, if at all). Behind the scenes, storage would work similarly to a database transaction log so it's always deterministic.
Apple should have then provided a paid service like Parse for apps that really need to deal with those callbacks in real time. Instead it feels like they swept all these details under the rug (which is impossible) so I never really trusted what iCloud Core Data was doing. I'm actually shocked that Apple went to the trouble of implemented iCloud storage without iCloud processing, but I digress.
P.S. Core Data is actually conceptually ok with its ORM and versioning. My gripes are with the needlessly complex way it interacted with iCloud.
My understanding is CloudKit is more like a file system or key/value store.
CoreData is an object graph, automatically persisted and fetched, and thus incredibly complex to manage differing versions and concurrent modifications on multiple devices.
In the end, as op mentionned, the goal is the same : save something on a server to fetch it later when you need it.
Then again all I've ever heard about iCloud Core Data is you can't use it because it isn't anywhere near reliable enough.