
The Deprecation of iCloud Core Data - ingve
http://mjtsai.com/blog/2016/06/17/the-deprecation-of-icloud-core-data/
======
erichocean
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.

[0] [http://www.ensembles.io/](http://www.ensembles.io/)

~~~
askafriend
People need to stop putting lifestyle businesses in quotes.

I mean if he's pulling in a couple million a year for just himself, that's
incredible. That's the dream.

------
zackmorris
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.

------
Razengan
Hopefully it's just the API that's being deprecated, to be replaced by a newer
one, and not the service itself, no?

------
chillaxtian
the word the author is looking for is CloudKit.

~~~
MBCook
Are you sure? CloudKit is the thing that replaced iCloud Core Data.

~~~
chillaxtian
and the article is titled 'The Deprecation of iCloud Core Data'

~~~
madeofpalk
iCloud Core Data and CloudKit are completely different APIs and technologies.

~~~
chillaxtian
solving the same problem: synchronizing application data between user devices.

~~~
MBCook
Not really, they're very different.

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.

~~~
bsaul
I think that's the point : it's much simpler ( but requires you to do more
manualy) and thus has more chances to work.

In the end, as op mentionned, the goal is the same : save something on a
server to fetch it later when you need it.

