I was hired to build something like Ensembles[0] for an Apple Design-award winning iOS/Mac software developer in 2009 (and did) that needed seamless Core Data sync across a suite of iOS and Mac OS X apps.
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.
When I tried to integrate iCloud with Core Data, it was one of the most painful coding sessions I've ever experienced. I never did get the edge cases to work, for example there was a part during init that decided whether to use local data or iCloud data that I never understood (that could have been due to the example I was working from). Conflict merging was a huge PITA so I ended up just appending both datas with a human readable separator and letting the user decide which to keep.
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.
What are you talking about? iCloud Core Data has been deprecated. CloudKit, good as it is, is not a replacement for iCloud core data, and is not relevant to the article.
But we're talking about the deprecation of an API. Hence, the difference is extremely important iCloud Core Data is (supposedly) deprecated, CloudKit isn't.
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.
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.
[0] http://www.ensembles.io/