Frustrated with iCloud, Apple’s developer community speaks up

Dropbox only does document-based syncing, which iCloud does correctly.

What technology are you referring to that Apple tried to force on developers and then killed off? The only one I can recall is garbage collection, which was never forced.

The in-joke we had as Mac developers many years ago was that Macs are very user friendly. The problem is that developers aren't users.

Core Data now provides NSIncremental store, which lets you use any web API as your persistent data store. It's possible to roll your own alternative to iCloud in this way, if you choose.

I think there's a good argument for it being broken:

1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/...

2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base.

3) Since the abnormal objects are spread throughout your code, and they're tied to non-thread-safe NSManagedObjectContexts, concurrency becomes rather difficult. You have to deal with multiple managed object contexts becoming out-of-sync across threads. Most people just give up and perform expensive operations like -save on the main thread.

4) Core Data merges the concepts of your on-disk model with your in-memory model, despite the fact that the two problem domains have very different requirements in terms of API design, data longevity, relational design, etc. This leads to code that is neither a clean in-memory model, nor a clean on-disk model.

5) Since Core Data objects are abnormal objects, one must produce a considerable amount of boilerplate just to define new model objects. What time you save upfront using a GUI to design your original model, you spend 10-fold in maintaining the code to support it, and in being handicapped by the contraints Core Data places on your code.

6) NSPredicate is awful. It's a brain-dead query language that often make it impossible to cleanly normalize your data store. Aggregate operations are expensive and often require O(n) cost, the query language is poorly documented and poorly specified.

Core Data is a very poorly fit abstraction, but it probably works well enough for simple use-cases. Once you move into concurrency, complex/large models, aggregate operations/projections across your data, or have to deal with it failing, it falls over.

After using it myself for a large project and struggling with all of these issues (and more), and watching another team do the same on their own project, I'd never make use of it again. SQL (via sqlite) is a far better abstraction for managing on-disk data, especially when doing so in a highly concurrent application where one can rely on SQLite's transaction support.

The key differences between touchDB and pouchDB is that touch is written for ios and pouch is written for web browsers, if you are building for ios and not using phonegap then I suggest using touchdb. It is also the more mature of the 2 but hopefully we arent too far behind with pouch.

I used to work for Couchbase on the arm compiled couchdb mobile versions, mainly android but either way I wouldnt hugely recommend using them, they always worked against the grain of the platform, never had great performance and due to those reasons they didnt really get widely adopted and therefore I wouldnt trust their stability across a variety of platforms and use cases.

The problems with arm compiled couchdb is the reason TouchDB was made, and similiarly with PouchDB / TouchDB for android and CouchDB I hope we get to the point were there is an out of the box sync solution that works great on every platform, it doesnt feel too far away.

For large initial datasets I have tried taking a dump of the database and importing it on first load, it worked however replication has been more than sufficient for my use cases right now. Once pouch has stabilised and released there are a lot of low hanging fruit that can be done to optimise replication (and in particular for first load).