Why iOS Devs Should Consider Using Core Data iCloud sync

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.

> "that you shouldn't work with it "even if it worked""

I simply have not seen this attitude at all on the internet. Everybody wants the promise of CDIS. All of the anger, frustration, and vitriol is around the broken promise of it, not the concept.

> "and (this might be personal opinion) but I don't believe that they're too far from cracking it."

That remains to be seen. There is a growing sentiment in the Apple dev community that Apple's QA quality is slipping, and slipping hard, and this has a large detrimental impact on developers.

I was recently at a conference where this "joke" was made multiple times. Whenever someone commented that "X might be fixed in iOS7" someone would pipe up "Great, then we can use it when iOS8 comes out."

The upgrade rate on iOS devices far outstrips Android, but even now, on the eve of iOS7, a good 15-25% of devices are still on iOS5. There is effectively a one-year gap between Apple coming out with new API, and being able to require the use of the API in your app (unless you feel like leaving up to a quarter of your userbase out).

With things like CDIS this one-year gap is effectively lengthened to TWO years. Apple comes out with something new that's broken enough to be unusable in production. We wait another full year for them to finish baking it. And then we wait another year for the install base to be wide enough to ship an app with it.

With CDIS this is coming up to be a FOUR YEAR GAP, assuming they make it production-stable in iOS7.

There is plenty of reasonable skepticism when it comes to doubting whether CDIS will be fixed at all, or be quietly swept under the carpet as a failed technology.

> "I've only seen 3-4 people who have lost access to their data completely"

In my experience data loss has never been an issue - loss of iCloud connectivity is. Which is to say, once a conflict resolution failure occurs, that device is now an island - no changes made there will be communicated to any other device, and no changes made elsewhere makes it to that device either. And there is no way to restore this connection that anyone is aware of it.

Data loss hasn't ever been a major problem here - when a breaking conflict resolution occurs Core Data's default behavior is to go all-local rather than delete data.

The inability to repair a broken iCloud link is 100x more aggravating than simply breaking, since it means having to tell a user that they are SOL. By far the greatest frustration I've encountered re: CDIS is exactly this - that once it breaks, it's permanently broken.

> "But in any case, my plan is to compile a list of all the issues I've experienced next, and maybe some of the hacks that I'm using to work around them, and do another write-up in the near future."

I'm looking forward to it, though I remain extremely skeptical that Core Data is production-ready.

I've now, collectively, been in rooms with literally thousands of angry CDIS developers. Very smart developers who have yet to be able to ship a single CDIS-enabled app because its stability is simply atrocious. I'm wondering how it is that your experience is so different from everyone else's - where you reportedly have CDIS working in a production app with few/no issues, while others can't even get their Core Data stores to stand up straight. That's a pretty huge gap in progress.

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

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.

> "- nuke their container from Settings"

This is the part that's news to me - I've observed myself and corroborated with many other devs that nuking a container prevents the container from being recreated by that app ID ever again.

This really is the one big sticking point - if nuking containers actually worked properly the scope of the problem is greatly reduced. Sure, potential data loss, but at least your devices start talking again.

I'd be interested in seeing code, but this is definitely something outside of your app. Very curious. I was very recently in a room full of CDIS devs who complain that the above is still broken in iOS 6.1.3, and I'm at a loss as to how you've been able to achieve successful recreation of an iCloud container that has been deleted via Settings.