
Why iOS Devs Should Consider Using Core Data iCloud sync - zulfishah
http://zaal.tumblr.com/post/46718877130/why-you-want-to-use-core-data-icloud-sync-if-it-just
======
stevenwei

      iCloud can resolve this problem by letting your users edit data offline and 
      resolving any merge conflicts automatically (and in the case of iCloud Document
      syncing, giving you some options to get feedback from the user to help resolve 
      the merge conflicts). If this worked seamlessly, it would add great value to
      your product. 
    

_If_ it worked seamlessly, which it doesn't. Conflict resolution is very
application specific, I'm not convinced that a one-size-fits-all automated
solution will ever be able to handle the edge cases as well as the original
developer, who has intimate knowledge of the problem domain and the structure
of the data to be synced.

    
    
      App Store Features: you might get featured by Apple on the App Store for using
      their latest, greatest technologies.
    

Don't think this is relevant for iCloud anymore. Besides, Apple has featured
_tons_ of apps that do their own proprietary sync or use Dropbox for syncing.
(e.g. Evernote, Omnifocus, 1Password). The quality of the app is much more
significant than the APIs it uses.

    
    
      Future Plans to move to Android / Web: a legitimate concern. But why not wait
      till your iOS product has grown big enough to have substantial demand for
      Android and/or Web, and develop your custom back-end solution then?
    

Migrating your user's data off iCloud one year later is going to be a massive,
massive pain to deal with. And database syncing is not like file syncing, it
won't be trivial to integrate another syncing mechanism into the application.
Things will start to get quite messy if you also want to interleave iCloud in
there for backwards compatibility.

~~~
zulfishah
Good points, though I'll just say this:

\- using Apple-sanctioned technologies might improve your chances of getting
featured by Apple. Of course, well-known popular apps get featured regularly
by Apple, but this is one of the factors that goes into their calculations of
who to feature. This is not a reason per se for using iCloud, but an added
incentive (as I mention, it really didn't pan out for me!)

\- Exporting data out of iCloud shouldn't be any more complicated than
importing data into iCloud is. You can easily walk through the Core Data
object graph and do whatever you want with the data. And with
NSIncrementalStore, you can easily keep the core of your application the same
and utilize some other web service to power the data for your app.

------
jchrisa
There are a lot of alternatives to iCloud. Most of them are just backend-as-a-
service, but some of them are really sync engines. Dropbox has been around a
long time, and is really popular for iOS file sync.

My team at Couchbase has been building mobile NoSQL databases that sync[1],
for a number of years now, and our tech is used by a few apps in the app store
already.[2]

This preamble is to say that I've had plenty of conversations with developers
who would be in iCloud's target market but decided not to use it. And the big
reason they won't use it has very little to do with the reliability and user
experience problems that keep coming up in the critiques of iCloud. The big
reason they don't use it, is that they need to control their data.

It's one thing for a small game or journaling app to outsource data management
to Apple, but an entirely different thing for medical apps, enterprise sales,
or other "serious" apps to do that. Perhaps in the long term Apple will offer
an enterprise version of iCloud that you can run on your own terms. But until
that happens, most serious apps are going to want to run their own
infrastructure.

BTW all the code we write is open source, so if you are interested in sync
capable databases with offline and p2p support, join us. [3]

[1] <https://github.com/couchbase/couchbase-lite-ios> [2]
[https://github.com/couchbaselabs/TouchDB-iOS/wiki/TouchDB-
In...](https://github.com/couchbaselabs/TouchDB-iOS/wiki/TouchDB-In-The-Wild)
[3] <https://groups.google.com/forum/#!forum/mobile-couchbase>

~~~
TheTaytay
Thanks for this. When I looked at the couch offerings just a few months ago, I
was turned off by the need to run what looked like a lot of heavy Couch code
on my devices. The mobile offerings didn't look mature. Couchbase Lite looks
promising, and makes me want to look at the Couch space again.

------
potatolicious
The problems with Core Data iCloud sync are _vastly_ understated in this
article.

> _"Yes, there are various problems"_

Yes, chief among them that _it doesn't work_. I'm quite serious here. _No one_
has gotten an iCloud-based Core Data store to withstand the actual multi-
device usage it was designed for.

We're not talking about "works, but buggy". We're not even talking about
"works but is a pain in the ass". We're talking "core features do not
function". We're talking about "no known workarounds to bugs at the core of
system that prevent it from working in any way that resembles the
documentation".

And it hasn't worked since iOS 5.0, released almost two years ago. We have
been through another major yearly update and _several_ point updates, and _no_
visible progress has been made on Core Data iCloud sync. The documentation has
not improved, and with every point release developers go back and survey the
situation only to find _more_ bugs and _more and different_ obscure error
codes being emitted by the system.

Core Data iCloud sync would be bearable if it were just buggy. It would even
be bearable if there was _forward momentum_ on the vast amount of brokenness
in it. But neither have demonstrated themselves.

But enough whining, let's address some points made by the article.

> _"Or you can allow offline editing and build your own custom conflict-
> resolution solution, which I can guarantee will make YOU very unhappy...
> iCloud can resolve this problem by letting your users edit data offline and
> resolving any merge conflicts automatically"_

Yes indeed, why build your own conflict-resolution layer, which you will
probably get wrong in horrible ways, when you can rely on a working solution?

Poignant question if there _was_ a working solution. Author is describing an
iCloud _that does not exist_. Core Data iCloud Sync conflict-resolution _does
not work_ , and when it does not work, _it has failure modes which result in
the irrecoverable corruption of your entire data store_ , and in combination
with other iCloud bugs results in the _complete inability for your app to edit
its iCloud bucket ever again_.

 _Ever again_.

I wish I didn't have to use so much italics here, but the point really must be
made.

> _"even if your app has been terminated, the iCloud daemon can keep running
> and upload your data whenever it gets an opportunity"_

> _"with CDIS, data is pushed into your app when it’s ready"_

Indeed, these are the points for using iCloud over other competing cloud sync
services on iOS.

But that's a little like saying the Ford Pinto has a really nice tape deck. It
has this really neat, really useful feature _when it isn't exploding_. It's
like saying dinner service on the Titanic is great - none of this matters when
you _can't even get the boat to float_.

> _"And that they have really seasoned, very smart people working on that Core
> Data team. I can’t imagine Apple releasing something as ambitious as a
> distributed, decentralized database system without “thinking it through”."_

 _But they didn't think it through_.

Author, you've been working with CDIS for the last two years. The technology
behind it is neither mysterious nor is it secret. CDIS isn't broken because
Apple can't write code. CDIS is broken because _it is architecturally
unsound_.

Core Data iCloud Sync breaks down from a high level like this:

\- You break each transaction into your database out as a diff. You store this
diff in a directory that the iCloud daemon is syncing. Thus, all new diffs
(called transaction logs by CDIS) are replicated to all devices. So far so
good.

\- It is trivially easy for a combination of devices (or really, just two) to
generate a combination of diffs that _do not_ playback to a consistent
database state.

\- In a normal world where CRUD operations are handled by a server with some
understanding of the underlying data model, the server resolves conflicts as
_the_ authoritative data source, and thus consistency is maintained.

\- In the world of CDIS, there is no authoritative server, nor is one device
ever designated as the canonical state (this would be unrealistic, since
devices get retired and lost, nor is there anything special about a device
that makes it canonical). Instead, conflict resolution is left to each device,
the implementation of which is broken. Which is to say, your CDIS-enabled
database will work fine _until the moment two devices make conflicting
changes_. At which point it is irrecoverably corrupted.

\- The CDIS client's reaction to this is to revert your local copy of the
database to its last known good state _and cease communicating with iCloud
entirely_. This error occurs silently without either notification via UI (to
the user) or API (to the developer). There is no way to query this state, and
as of today the only visibility into this error is via console logging.

\- Because the corruption has already occurred server-side, this means _all
connected devices_ using this store are all now disconnected from iCloud when
using the app.

\- As previously mentioned, there is no simple way to detect this error state
via the API. Even if you _were_ able to figure out that this has occurred,
_there is no way to destroy your database and start over_. Due to bugs, lack
of documentation, or architectural oversights, there is enough metadata about
the database that the app cannot delete, that deletion of the store and its
associated diffs do not put iCloud back to a clean state.

 _This_ is why people are giving CDIS a lot of shit on the internet. Nobody
seriously believes Apple is incompetent at programming, but even a mild dive
into the underlying technology on which CDIS is based shows that this entire
architecture is unworkable. It's not that _Apple_ can't get it right, it's
that they've committed to an architecture that _no one_ can get right.

As someone who has spent the last few years neck-deep in iOS, who makes a
living writing iOS apps, I _want_ iCloud to work right. It is in my interest
to cheer on Apple's every move. But short of _completely_ scrapping their
existing architecture I do not see how it can be meaningfully improved (read:
made to actually work).

> _"CDIS is a really compelling technology for many iOS / Mac developers to
> adopt in their apps, and you should be seriously looking at iOS6 or iOS7 as
> the point to jump onto the CDIS train if it fits your needs"_

 _NO_. I for one would be _ecstatic_ if CDIS works as advertised in iOS7, but
_under no circumstances_ should anyone consider using CDIS on an iOS6 device.

> _"and it deserves less dismissiveness"_

Dear author. We, the iOS developer community, have not acted with
_dismissiveness_ about CDIS. In fact we raced towards it with high hopes. We
fought the scant documentation. We fought the bugs. We poured into the dev
forums in droves. We helped each other and we shared our learnings.

We are angry now because we have _tried_. Nobody dismissed CDIS out of hand -
the anger here comes from tens of thousands, if not hundreds of thousands, of
collective man hours exhausted attacking this problem from every possible
angle, and we are no further from where we were when CDIS first dropped in
iOS5.

All of the points you make are valid in a universe where the technology you're
talking about is _functional_. It would be _insanely great_ to have a cloud-
based data store that does conflict resolution for you, that updates in the
background, that removes our responsibility for hosting it, that has no
operational overhead on our part, and pushes instead of pulls. Indeed, those
are all great reasons to use such a technology - _if it existed_.

But as it is no one can make a Core Data iCloud store stand up for more than
an hour. And no one can recover a corrupt data iCloud database after it's
fallen over. So unless you've figured out the solution to the above two
problems, I'd kindly suggest that you stop treating the entire iOS developer
base like ignorant, petulant children.

That was way longer and way angrier than I intended, but the article is really
IMO nonsensical, and the author's tone that the iOS community has someone
"dismissed" the technology or somehow not given it a fair shot, bothered me
greatly.

~~~
cageface
I'm extremely unimpressed with the software engineering coming out of Apple
recently. So many of their major new iOS APIs either don't work (Core
Data/Sync), are just not well thought through (Storyboards) or seemed to have
been designed with much real world testing at all (AutoLayout).

They have a great foundation in Obj-C/Cocoa Touch but I'm very quickly losing
confidence in their ability to move the platform forward.

Android is much less mature in many ways but seems to be under much more
expert guidance lately, both architecturally and at the UI level.

~~~
thomasjoulin
I'm curious about what you think is wrong with Storyboards or AutoLayout.
Storyboards certainly lack features so not all apps can be done with them, but
nonetheless I think they're pretty solid. And AutoLayout works like magic,
haven't had any problems (the IB-adds-constraints-for-you thing is annoying,
but necessary)

~~~
cageface
Storyboards:

1\. Interact poorly with version control.

2\. Scale badly with a lot of VCs.

3\. Segues are untyped and are inadequate to express complex navigation
schemes.

AutoLayout:

1\. Excessively verbose normal syntax and excessively limited and cryptic and
untyped shorthand syntax.

2\. IB tools are woefully inadequate for editing.

3\. Small adjustments to complex layouts in IB _completely_ scramble the
constraints.

4\. Does nothing to make the 95% use case of nested grid layouts explicit and
simple.

~~~
sjtgraham
2\. Is the fundamental deal breaker. They're impossible to use in a multi-
developer environment, because of the absolutely guaranteed merge conflicts at
every turn.

~~~
cageface
I now have a one-VC per storyboard rule, which helps. I wouldn't use them all
if I could design custom table/collection cells in xibs.

------
drawkbox
I like iCloud but it is only an add-on sync option for most games we do as
they are android/ios/web/desktop. A non fully cross platform cloud sync option
just doesn't help speed up development much but it s a great low barrier sync
for iOS only customers.

For iOS it is pretty easy though, anything in Docs gets synced if logged in
and the app is setup for iCloud. It has always been a little touchy when they
added the Caches/Documents requirements. You have to setup a no backup flag to
prevent it from syncing if storing anything there which can be a problem if
you store too much.

    
    
        BOOL success = [URL setResourceValue:[NSNumber numberWithBool:YES] 
            forKey:NSURLIsExcludedFromBackupKey error:&error];

------
sk5t
Hey Apple, why don't you get to studying on good old Lotus Notes? Multimaster,
highly replicated, non-relational, conflict-reconciling, document-focused
storage for what, twenty years?

~~~
wallflower
I assume you know that Lotus Notes was basically just a sync engine. That was
its one and only core feature [1]. Apple is overextended - they have to keep
up with Android and maybe even WP8. To fix iCloud CDIS with application-
specific arbitrary data models is a very difficult task. Especially with their
dumb master approach. A true client/server solution requires a smart server to
mitigate and handle sync conflicts. As users demand more and more
functionality, including offline capabilities, iOS apps begin to morph into
client/server ptograms. So much so that what most developers end up doing is
writing their own client/server sync. iOS and Android budgets dive into the
deep end once sync requirements get baked in.

[1] [http://www.ibm.com/developerworks/lotus/library/ls-
NDHistory...](http://www.ibm.com/developerworks/lotus/library/ls-NDHistory/)

------
zulfishah
Couldn't agree more than it's just badly implemented right now. It's at a
"barely viable" stage right now. Article was meant to question the very
assumption that it's a just a fundamentally bad idea to begin with, and all
the negativity that's recently coming out in the press. Yes, it's not for
every app or every situation, but it could be a great solution for a lot of
apps (if only it worked a bit better!).

------
seivan
Again I hope people can separate Core Data and iCloud. Core Data works
perfectly fine (though I suspect some will argue with me on that point, I've
had no issues with it since 4)

But iCloud is just badly implemented for the moment. Will probably get better.
Apple doesn't call iCloud beta, and people will probably be pissed since it
doesn't work properly.

I suspect that if they did call it Beta, some might have had gone easy on it
for all the faults out there.

I gave it a try when the API was accessible, I didn't like it, never looked
back.

1)SSO can work with other form of social logins - and will also work from
other platforms/clients

2) Privacy? As a developer you have access to those files

3) This works better if it's stored on a server that has a more public API
since you probably want a web interface and etc.

------
thrush
Currently downloading the referenced app (Contacts Journal CRM) to see if the
hype is real.

~~~
thrush
So far the app is great, but I'll need to give it a real test run over the
next week or so to see if I run into any data issues. Right off the bat I'd
like to mention both something worth of appraisal yet slightly worrisome. The
iCloud sync in Contacts Journal CRM gives the user an "Identity" number
associated with their account. I don't have a lot of experience with iCloud
but I've never seen this done before. Is this provided by Apple in the iCloud
implementation? It's awesome you guys have some redundancy to protect against
Apple failing with your data, but it's also kind of an indication that theres
some likeliness to there being some issues with iCloud.

~~~
zulfishah
Thanks! The ID number is only referenced in this file: ~/Library/Mobile
Documents/BJ97GLR9R3~com~cjournal~icloud/Configuration.plist

It's just a reference to check if your current device is participating
correctly with the rest of the iCloud container, so that you can tell if
someone deleted the iCloud container behind you while the app wasn't active,
the app would be able to handle that situation. It's only exposed to the user
in case something is wrong and the user can quickly check this value from that
plist file. In practice, it hasn't proven too useful to expose this to users,
but something to build on for a future update.

------
1010011010
Perhaps the Google Drive Realtime API could be a substitute.
[https://developers.google.com/drive/realtime/reference/gapi....](https://developers.google.com/drive/realtime/reference/gapi.drive.realtime)

