Hacker News new | past | comments | ask | show | jobs | submit login
The Deprecation of iCloud Core Data (mjtsai.com)
50 points by ingve on June 18, 2016 | hide | past | favorite | 15 comments

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/

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.

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.

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

the word the author is looking for is CloudKit.

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

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

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.

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

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

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.

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.

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.

So CloudKit stays while iCloud core data is no longer usable?

Sounds like 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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact