No one really fully knows WTF is going with iCloud - documentation is basically nonexistent, support unavailable, implementation broken in trivial ways, and error messages inscrutable. I was at an Mac/iOS conference recently where the Core Data iCloud talk morphed from a standard talk into a "here's the mic, anybody have any idea what's going on with this thing" affair. Helpful, but indicative of the state of things.

IMO, from having studied this for many, many hours over many moons, is that what Apple is trying to do is fundamentally hard, if not entirely unfeasible. They're trying to replace a smart server with one that's dumb as a doorstop. More specifically, they're trying to emulate a CRUD web service with a file sync engine.

Conflict resolution is left up to individual clients, since the server doesn't do any "thinking". Likewise, there is no canonical, authoritative state of the store, since the server doesn't "think", only the clients do. Apple was hoping that by shoving a bunch of diffs of your database onto the server, that clients can reliably reconstruct a sane database by playing them back - except that multiple clients are updating the diffs simultaneously and there is no server-side conflict resolution.

Oh, and if stuff fails, there are no regular snapshot states to fall back to, because iCloud is a file store, not a database engine. Your whole store is now corrupt. Enjoy.

Oh, and there's no way to nuke the database and start over - there are metadata files that are undocumented or that we don't even have sandbox access to, that interfere with completely destroying the database.

At this point you might think "Fine! I'll go to my Settings -> iCloud -> Manage Storage menu and delete everything associated with that app and start it off on a clean slate!"

And then you find out that, even today, in iOS 6.1.3 land, there is a bug from iOS 5.0 where if you delete an app's iCloud bucket it can never be created by that app, on that account, ever again. I wish I were exaggerating. In perpetuity. Presumably some state gets fucked and now this app is forever more unable to store anything on iCloud.

To make even the most trivial experiment on the iCloud API involves creating a brand new app.

iCloud (in so far as it relates to Core Data and document storage) isn't just buggy, isn't just poorly implemented - it's non-functional.

As a user though I have absolutely no idea what is going in with Apple syncing. My wife has an iphone / mac syncing explosion that I simply can't fix. I just don't have any idea where the data is or why everything is duplicated in her iphoto collection. Or what's going to happen in when you remove something from one place.

Most of all I cannot for the life of me explain to my wife why it is that when she lost her phone and restored a previous backup to a new one it DELETED ALL HER RECENT PHOTOS from off her mac without warning. Gone, forever. I watched it happen before my very eyes and it's made me want to never buy another apple product again.

Let me tell you it's not exactly happy land for us consumers either. Apple's "cloud" is a mess. And don't even get me going about the "new" and "improved" iTunes. Frankly I pity developers, cause Apple's mess is giving them a bad name.

I can't think of 1 icloud enabled app (on Windows or Mac) that I've used that worked well. The apps themselves are fine, it's the cloud integration that fails. I mean just look at Apple's own forums.

After 10 years as a Mac user, I'm actually considering moving back to Windows. I'm just over it. It's like every new OS (or app) something goes missing. I'm tired of spending hours searching for replacements for features Apple has removed. And I'm tired of being force-fed services and apps (that Apple's PR states is "gonna change my life") still in beta.

Ok ok //end rant

I spare you the finder, sftp-integration and the keyboard-layout bitching.

Apple has a long story of half-finished features they try to force onto developers and users. And if that doesn't work the technology gets killed off.

The only downside of not using shiny but questionable new features is that your app won't get featured in the App Store.

This is a pretty huge downside. The App Store is a huge mess - there is effectively no web frontend for it, it's tied deeply into a desktop application, and it's obtuse. This makes marketing nigh impossible and results in Apple having an enormous, and disproportionate, ability to pick winners and losers.

Being featured is a Big Deal(tm).

I was a little shocked when the switched to the 'card UI.' On a mobile device where there is very little real estate, they completely nerfed the amount of app information on the discover screens. Added so much physical effort and time it takes for the user to peruse a like number of apps compared to the former UI.

Of course, if this isn't fixed soon...

The fact that anyone, anywhere (including Apple), actually expected Core Data to work as a distributed object store is totally beyond my comprehension.

> I have no experience with iCloud, but I'm pleased with Core Data for managing a persistent object graph. It automatically handles version migrations, undo, and faulting, and some interfaces can be populating with almost no code via bindings. I'm happy with it. Still, I'll be very interested to watch the Core Data presentations at WWDC.

It requires a lot of discipline, and we rely on a lot of learning-through-pain since the documentation beyond the most basic implementation is mostly non-existent.

Core Data is pretty simple if you do all of your work on the main thread, but then your'e also blocking your main execution loop for operations that can take a long time. A large save will easily reach into >200ms land on an iOS device, and your app will feel like crap.

Thread safety in NSManagedObjectContexts is somewhat documented, but has a lot of quirkiness to it. There is some general knowledge around what is and isn't thread-safe, but almost nothing surrounding how to build a multithreaded app and not be murdered by Core Data. Much of this is trial and error and observing what open source projects are doing.

Once you settle into a decent threading scheme that won't kill you (probably with multiple NSManagedObjectContexts) you have to worry about communicating changes across multiple contexts - then you delve into parent-child contexts, where the document gets even more bare. Then you get into propagation delays when crossing context boundaries.

Keeping your code clean through all of this is also a challenge. There are also runtime issues - our implementation in Core Data experiences unbounded growth in memory usage on iOS5, but not in iOS6, forcing us to manually mitigate memory use (which Core Data is supposed to take care of), creating even more thread-safety concerns.

All in all, it's a pain, but it's also the only realistic object store/graph on the platform.

Can you give an order of magnitude at this would happen? I usually only have 50-200 entities in my database in total, saving maybe half of them at the same time. Yet libraries like RestKit insist on a two-context setup to avoid the saving delay you mention. I'm not sure if I should fight the libraries and go back to a single-threaded setup (that I understand) or just go with the parent/child context flow.

Could you name some of those open source projects? Thanks.

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.

2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

5) Fud. Write a wrapper, use existing wrappers.

6) Agree.

I am actually kinda curious what problems you've gotten into recently. I've seen Core Data be improved ever since I started using it in 4. I wish it had Cocoa bindings on iOS... but ah well. I've never had any concerns here.

I don't use it for complex stuff. Ironically I didn't use it for a graph though I was told it would be a perfect fit, i wasn't really sure how to traverse without pulling everything into memory. So ended up just using NSObjects and keyedarchiver. But I would be curious to see if someone more familiar with Core Data would have solved it with CD.

I touched on this in a peer comment, but it ties your hands in terms of doing rather normal things that would make for a better model API.

> 2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

Using an immutable model makes concurrency far, far easier (among other things).

> 3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

Like I said in reply to your other comment -- The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> 4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

I think you're confusing what I mean by in-memory model and on-disk model.

The way one defines and represents on-disk storage is very different than in-memory storage: the data is persistent, it must remain accessible over time, the model must be versioned, and changes to the actual model definition must be applied as migrations between versions.

In-memory models, however, live only for the lifetime of a particular run of that application, may be modified freely, require no versioning, and require no migrations other than code refactoring.

By tightly binding these things together, Core Data creates the worst of both worlds: all the complexity and downsides of on-disk models with almost none of the flexibility and simplicity of in-memory models.

> 5) Fud. Write a wrapper, use existing wrappers.

That involves quite a bit more work than defining a simple class. Tools such as mogenerator are big, complicated, and a hassle. The point of Core Data is to save effort, but it generates more work and complexity.

> 6) Agree.

Well, at least we agree about something :)

This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model.

Compare to SQLite, where one can simply open and commit a transaction synchronously on any thread.

And yes, you can still not use a persistent store manage context on multiple queues.

Please stop using the word thread and use the word queue :)

The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> Please stop using the word thread and use the word queue :)

Why? Queues are M:N mapped to threads, so they are still threads. Additionally, not all work is always done on queues, especially when working with legacy APIs.

What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects.

Core Data does solve a few tough problems well. Faulting, uniquing, and cross-context change merging are probably the top three. Yes, it can be much simpler to just query SQLite, but I've never seen somebody do that and abstract away updating stale copies of objects.

Well, keep scrolling :~)

Especially 'Custom Instance Variables' and 'Custom Accessor Methods' and 'Validation Methods'. I don't think it's controversial that defining derived instance variables, accessor methods, or other derived state on model classes is an unusual or unwarranted desire, yet doing so with Core Data requires considerably more effort and complexity than a simple model object.

What problems have you had?

Well, they are; they inherit NSManagedObject, which descends from NSObject. It's true that model objects need to follow a bunch of conventions, but that's by design.

> Core Data merges the concepts of your on-disk model with your in-memory model

That's a feature. I rather like how it forces you into rethinking your design.

From your other points it sounds (mind you, sounds, I am not judging) like your app was the wrong fit for Core Data. It's not a replacement for a full-fledged SQL RDBMS and was never intended to be. Core Data works swell for its intended scope.

All you're doing in this post is phrasing problems that are fundamental to data storage in core-data specific verbage, and calling them a grievance against Core Data. But they're not. There's no other magical solution that somebody could write that does it any better.

For example:

> Since the abnormal objects are spread throughout your code, and they're tied to non-thread-safe NSManagedObjectContexts, concurrency becomes rather difficult.

Concurrency is difficult independently of how you go about it!. The fact that concurrency continues to be hard is not Core Data's problem. The question is, is it easier or harder to use Core Data's primitives to achieve concurrency than it would be doing everything from scratch? I think it's easier. But Core Data against magic is not a fair comparison; a fair fight is between [hard problem with off-the shelf tool] against [hard problem without any tools].

Or this one:

> Since Core Data objects are abnormal objects, one must produce a considerable amount of boilerplate just to define new model objects.

Again, the choice is not between [boilerplate] and [no boilerplate]. As you've correctly pointed out, the mapping between on-disk and in-memory is a hard problem, and the solution will involve writing code that bridges the two worlds. The question is, is [boilerplate that's defined over 10 years of Cocoa convention] superior to [boilerplate that I invented from scratch to solve my problem]? I'm going to claim, 90+% of the time, that you want door A. Perhaps you really do want door B occasionally. But there is no door C with a boilerplate-free existence.

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

And as a person who has worked on probably over two dozen Core Data applications, I would not touch any codebase that had this philosophy with a ten-foot pole. Concurrency, boilerplate, memory/disk impedance mismatch are the same problems wherever you go. It is perfectly fine to say "I don't like using CD syntax to solve these problems" as a personal preference. But it is another thing entirely to say that CoreData is "broken" because one is either unable or unwilling to solve these same problems we solve every other day of the week in a slightly different syntax than one is used to, particularly when that syntax is generally accepted as a platform standard.

To use an analogy, it would be very poor form to try a Ruby project or two and conclude that ActiveRecord is terrible and that it "falls over" once you step outside "simple use-cases" and that you would never do another Ruby project unless you were emitting postgres queries by hand. There are not a lot of Ruby developers who would sign up to work on that project.

Having dug through iCloud's underlying structure, I can tell you what they're doing is very close to what Microsoft's Sync Framework does - right down to the naming of some of the columns in the underlying database.

In fact, if I didn't know better, I would think it was a peer implementation of the Sync Framework (which considering the iCloud server is hosted on Microsoft Azure which has native support for Sync Framework built into hosted SQL Server, isn't too far fetched).

The difference is that Microsoft's Sync Framework seems to work.

"Distributed Databases are Hard" has been a mantra for many decades, probably getting close to a half century. We have known, basically forever, that this is hard on a fundamental level. (Google "Two Generals" problem.)

> Apple was hoping that by shoving a bunch of diffs of your database onto the server, that clients can reliably reconstruct a sane database by playing them back

This is called a variety of things. One of the terms is "transactional replication." It can get very very sticky when there is more than one party originating write transactions, though.

I just change the topic to a different backing store when the client wants "cloud persistance" and says "iCloud" without understanding the pain they're asking for.

I agree, completely non-functional

I know it's fashionable to hate on Java, for a lot of good reasons, but I think it's naive to dismiss the power of the platform itself.

We may all have (completely valid) complaints about the outdated and verbose syntax of the language, but the actual JVM itself is fantastic. There are more scalable, fault-tolerant, high performance Java systems out there than the rest of the implementations on all other platforms, combined.

Yes, I know. The problem is not Java directly. Reread what I wrote

Google has the infrastructure and resources to make Java work for them at their size. Because they have whole teams dedicated to build their infrastructure (FS, storage, etc)

Apple has to optimize their resources. They're not going to rebuild what Google did and I'm not seeing them using, I don't know: Cassandra, Hadoop, etc

What I'm saying is that Apple is probably trying to reinvent the wheel. With their resources, they should go with Scala, Clojure or use helper technologies.

Apart from that, in Google most (core) jobs are software related, in Apple not so much (there's hardware, design, logistics, manufacturing specialists - even if the bulk is @ Foxconn and similar contractors).

Even if we consider software jobs only, I believe the bulk @ Apple is working in OSX/iOS, not to mention iWork, Final Cut, etc and not directly in Cloud infrastructure.

Not that it matters a whole lot, but, as the website says that's just the US number.

The total number of employees in retail according to Apple's last 10-K filing in October 2012

( http://files.shareholder.com/downloads/AAPL/2393147114x0xS11... )

was 42,400.

" Employees As of September 29, 2012, the Company had approximately 72,800 full-time equivalent employees and an additional 3,300 full-time equivalent temporary employees and contractors. Approximately 42,400 of the total full-time equivalent employees worked in the Company’s Retail segment. "

It's true that Apple is highly focused, and they probably have half, if not a quarter of the products that Google has.

There is a non-zero amount of irony in your bashing of Java then picking out two projects that apple isn't using, but you apparently think they should but using, which are both written in Java.

I am saying is that probably Apple has a NIH mentality with regards to infrastructure and thus are trying to reinvent things like that. And of course, reinventing these in pure Java takes more time than using Go, for example.

And Go being so early in its life obviously lacks the wide array of third party libraries that Java does.

And this NIH mentality you've invented is simply not true. You are just confused and probably need to lie down for a bit.

Yes, sometimes I miss out on really neat developments. iCloud is one of those cases where I am glad for being a slow adopter. My mental red flags went up as soon as iCloud came out. Not one of my apps uses it.

On the end-user front iCloud is also an absolute mess. I probably have a dozen i-devices on the same account (testing, etc.). Crap appears and disappears from devices seemingly at random. The worst of it was what is happening with my wive's iPhone and mined. We share an iPad at home. Now contacts are getting deleted from her phone and mine at random and so are notes. It's at the point where she is not using notes any more because --her words-- they disappear within a hour or two of writing them.

Of course, turning off iCloud is the solution. The problem is that this isn't as simple as throwing the switch. If you turn off iCloud on your device it might actually delete things that it shoved into the iCloud service. And then it deletes the info from your other devices. And it does this in some amazingly weird ways. Without telling you what it is about to delete.

For example, I have never explicitly stored contact information on iCloud. Never. I type new or updated contact information into the phone. That's where it belongs. In fact, I never even use my iPad for this. Yet, some contact information for some strange fucking reason is sent over to iCloud. The first time I turned off iCloud piles of contact data evaporated from my phone. I had to turn the damn thing on again to get it back.

I haven't had the time to research how to fully disable iCloud on ALL of my devices while, at the same time, keeping or merging the state of my data on that particular device. As a developer I managed to avoid iCloud. As a user I was not that fortunate, I succumbed to the new shinny thing on the shelf. Now I want nothing to do with it. Thank you Apple.

Any ideas on how to do this?

Can anyone else chime in? Does this sound reasonable? I've had everything on my iPhone synced up to Google services for about 4 years now and it's never caused any issues.

Frankly, I'm just thinking of writing an app to export everything to a MySQL database on one of my servers and do my own version controlled backup. Not sure Apple would ever approve such an app, but I can certainly write it and use it internally.

A long time ago I learned there is nothing more important than ensuring your data is safe. I learned this the hard way in college when a drive failure evaporated six months of hard coding...and I had zero backups. You don't do something like that twice.

With iCloud Apple has given us a tool that is so badly done it has the potential to evaporate our data. Amazing.

There's a reason Microsoft code runs the IT infrastructures of small, medium and massive corporations. They get it. They don't engage in making petulant adolescent choices for their users. Crap like removing "Save As" from applications and forcing duplication --and even storage-- of files on iCloud from your desktop.

I've been using Apple products since the first Mac. I could not see any way to trust Apple with enterprise data. No way.

I really don't know what Apple is about any more.

RSS and CalDAV are examples of web data formats which do work. I'd like to see more formats like that, or perhaps an ability to fall back to export data as files from web services.

Those 3 things are broken as well. Lost all my data twice.

And then last month, syncing my iPhone with iTunes inexplicably deleted the 40GB of my music from my iPhone. I hadn't done anything differently from the hundreds (?) of other times I've synced. I just had to go one-by-one and re-check all the playlists I sync, and wait a few hours for all the music to be re-copied. But still.

As easy as Apple products are to use, I'm always afraid something is going to go horribly wrong, in a way I never was with PC's, for example -- they were harder to use, and did less, but you could at least be reasonably sure of what was going on behind the scenes.

We launched native iOS support a few weeks ago [2]. You can also access your data from JavaScript or from a REST API. Android and other platforms are in the works. We're a platform-independent service, and since you (the developer) is paying for the storage, we have the right incentives to give you maximum access to your data (unlike iCloud), and a good developer experience.

We've also put a ton of work into making it easy to learn and easy to use. See, for example, our quick tutorial [3].

If you've used Firebase as a substitute for iCloud, we'd appreciate your thoughts in the comments!

1. https://www.firebase.com/docs/transactions.html

2. https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sd...

3. https://www.firebase.com/tutorial/

Much of the iOS community still creates software by the seat-of-your-pants model (i.e., write code, boot it up, does it look like it works? ship it). Engineering rigor is still a concept relatively foreign to iOS, and it shows. Apple has little-to-no built in support for anything that smells like TDD.

When you're talking to your server-side peers who have good test coverage, good regression testing, and more generally just sound engineering processes, you can't help but get bit jealous.

That leaves us with bug classes like: multithreaded Core Data misuse, "UI can be broken by using three fingers exactly like this", popping a navigation controller as a reaction to a network operation while it is currently being pushed (based on network latency), networking code that does not properly handle session extensions while multiple concurrent threads are in progress, labels use the wrong font, code uses UIKit on the main thread, ...

Good luck writing tests for that and being more cost-effective than code reviews & manual testing.

Part of it just comes down to the way the GUI framework (whether it's Cocoa or Android) cuts across all aspects of the application, making it difficult to isolate individual components to test. Add to that a bunch of asynchronous code (which is almost always necessary when you start dealing with the database/network/filesystem) and you have something quite tricky to automate testing for.

Most of the server-side code I've dealt with has been an order of magnitude easier to test, but I think a lot of that comes down to the nature of their respective domains.

I seldom see TDD, unit testing, continous integration and so on outside the startup world.

Most of the projects I do in the enterprise start agile and slowly evolve to a mix of agile and waterfall. When stress for delivery raises, many entrerprise project managers just kill unit testing related tasks.

    And just for the record I have a few flagship apps in the app store with millions of active users

     because your toolset is from yesterday and their's is from tomorrow

Oprah Magazine (1M+ subscribers): https://itunes.apple.com/us/app/o-oprah-magazine-archive-dec...

Esquire Magazine (1M+ subscribers): https://itunes.apple.com/us/app/esquire-magazine/id433020707...

Those are just two that I have built. I have an enterprise platform that I architected from the ground up that companies like pfizer use for it's whole workforce. I have ones written for Disney, Hearst, GE, MaryKay, Hallmark, Sesame Street, etc, etc. The one I'm building now is ready to scale to ~5M users right out of the gate and I believe we will succeed.

Now put your apps up and let me pick through them and tell you why you're wrong because I just don't believe your work is credible.

Having started working on Android recently, if Android is tomorrow, the future sure is dystopian.

That's not to say that the iOS testing tools are great, but I've never had a particularly pleasant time testing GUI code on any platform.

And Apple's WWDC session about acceptance tests using Instruments UI Automation specifically handles UIAlertView.

I think the problem is that iOS apps are getting dumber and dumber while their UI bling gets more complicated/asynchronous. The value of tests is too low for The One Widely Accepted Testing Framework to emerge.

And what would that "toolset of tomorrow" be? Surely not Android's joke offerings, or Windows 8 same old...

I've worked with both and I can say this is just a case of "the grass is greener".

Nothing "exciting" about HTML5 and the Web for people well versed in a mobile framework. The most interesting things are re-inventions of the wheel, only more hacky and less performant.

Plus, since you can use web views in your native mobile app, there's literary nothing (technologically-wise) you can achieve with HTML5 that you cannot achieve with a native framework. The inverse is not true. Anything that requires extensive collaboration with the underlying machine, low latency, ad-hoc connections to interfaces etc is not possible (you cannot write Garageband with HTML for example. And Flipboard or even Clear would have been noticeably slower).

(Except the distribution method of course -- but then again, nowadays people still debate if it's all about native or it's all about the web, so that's like 50-50.)

Mainly the pain points are on the API and the legacy nature of it, and the surrounding crappy tools. I see cool IDEs, testing frameworks, scaffolding/bootstrapping sets and I can only be a little jealous. Sure we have our share, but it's a small slice of where the majority of effort is in the web world.

My hope, crossing fingers, is that one day HTML apps will truly be able to compete across all facets and access native functionality with the same performance as native platforms. Will this ever be the case? I can only hope.

ObjC does have a legacy nature, but I think the community is doing a great job of making life easier.

"If you turn off Documents and Data, all documents stored in iCloud will be deleted from this Mac"

Let's get past the jaw-to-the-floor, how-dare-you, !!!$$%#$## moment. They are morons and don't respect your data.

So, how do you figure out just what is in iCloud? I don't see an easy iCloud viewing option in Finder.

Doing some digging this is what I found:

  - Open Finder
  - Fire-up "Go To Tolder"
  - Enter ~/Library/
  - Go into "Mobile Documents"

If you delete anything there it will be deleted from all of your sync'ed devices, including your local Mac. It will also end-up in the trash folder.

You could copy it all to a USB drive, memory stick, or, better yet, Dropbox. Then you can completely disable iCloud knowing your data is safe and iCloud will never cause you further grief.

1 - http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golde...

This was also when I learned that Google's process for restoring lost two-factor credentials ultimately ends in an email form which sends to higgins-prod-lost-hard-landing@google.com which been bouncing since 2011. Thank FSM I had some some backup codes printed…

iCloud would be worse if apps /couldn't/ opt out.

The scary thing is that you hope your apps can handle the case where they have local data but no authenticated user for it. Some of them just treat no authenticated user the same as a first start and reinit the local data.

Things that are marked as kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly are never included in this backup file. Google's GTMOAuth library uses this value for its keychain records.

I've also never heard of them until now. Perhaps they should show up to said conferences, or at least keep tabs on Core Data-related talks at conferences and give the organizations/speakers a heads up.

As I understand it Simperium observes changes to the Core Data models you specify, maps those changes to operation transforms, and distributes the transforms across whichever clients have subscribed to the service. That's great if all your app needs is simple data replication to multiple clients. Unfortunately operational transforms are not necessarily snapshots of database transactions and conflict resolution strategies do not guarantee a valid database.

Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients. Conflict resolution is then performed between operations rather than transactions. Simperium can probably take steps to minimize that case but as long as I can construct transactions which cannot be expressed as a single operation this will happen.

Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules. For example two clients can each add a child object to a "has one" association. Both "create" operations can be applied without conflict but the parent object no longer passes the application's validation rules.

This doesn't make operational transform based synchronization untenable but it does imply a new set of constraints on how applications should model their data in order to successfully apply operations from other clients. That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail. Otherwise I fear such a service is another iCloud like trap which will eventually (though perhaps less frequently) hit catastrophic edge cases from which there is little hope of recovery.

Interesting; I've implemented OT myself, and this is not a fundamental failing of the concept: in fact, even fairly simple implementations like ShareJS do not succumb to this fate (the easy way to model it is that you end up with larger macro-operations that are capable of transforming eachother's components, while still having to be played back one macro-op at a time; you also just stop playback while a transaction is in progress). I am totally willing to believe that Simperium's implementation (which I believe thinks about the separate objects as separately transformable documents) may have issues here, though.

> Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules.

This is certainly true, but is endemic to the entire idea of offline synchronization and has nothing to do with operational transforms: you simply can't do this without accepting "a new set of constraints on how applications should model their data in order to successfully apply operations from other clients"; this is clear from CAP (as rather than become unavailable when the network is offline/partitioned, we have to lose some consistency).

> That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail.

This is totally fair. (I can entirely appreciate it as well, as it reminds me of all of my complaints regarding how seldom you would hear companies like Parse and StackMob attempt to drill in how important security should be while using their services, at best leaving it as an appendix in their documentation. I believe they have at least been getting somewhat better about this since my talk on the subject at last year's 360|iDev.)

It's like Game Center, Apple doesn't bother with any apps that really use it so there's many, many problems reported on a consistent basis, and they don't seem to use iCloud for anything involving Core Data so they're not dog fooding and having engineers swear at code. No swearing means no one is motivated to go back and try improve it.

They, understandably, thought there was no way that something so heavily promoted by Apple could be such a lemon. And in spite of having heard mumblings of iCloud bugs, we wrote it off as amateur iOS developers.

We ultimately abandoned iCloud prior to release (going with simple Python based server for data storage) -- reading the other posts I'm glad we didn't try to convince ourselves that the 'almost stable' behavior was just a quirk of our devices having been used in development mode.

My hope is that now that one person (Jonathan Ive) has been put in charge of product development, things might get better.

It's a different game played by different rules.

Interestingly, I'd like to watch and see how Google does moving into the physical goods space.

For one, Windows Azure is a pretty big deal. Secondly, XBox Live is a pretty big deal. Third, Bing might be struggling to gain traction but it most certainly works.

So can you point me to a Microsoft web property or service that is as wonky as iCloud at all?

At Microsoft's size they aren't really looking for "pretty big deal" successes.

Bing is probably around 15% market share. A home run for most but not (yet) for MS.

I can't really comment on Windows Azure. I'll take your word for it but I think Amazon is eating Google and Microsoft's lunch here.

This isn't a fight for second place.....

I was implying that Apple and Microsoft don't do as well building web services. I wouldn't argue that Azure can't scale but the overall approach seems to be a little bit "unfinished".

Let me explain, the only true cloud computing environment that really solves 90% of any companies needs is AWS. Somehow Amazon understands what the developer community needs. I'm really perplexed by Google not getting this right.

Apple doesn't and I don't believe Microsoft does either.

I don't think this is about technical chops. It's something else that I can't put my finger on.

Similar to how I don't understand how Amazon crushed Best Buy so quickly.

Windows Azure is a big enough deal, and working well enough, that Brent Simmons of Black Pixel (and well known indie Mac developer) has been recruited to do tutorials on the Mobile Data Services component for iOS.

http://www.windowsazure.com/en-us/develop/mobile/ios/

How can the richest computing company not answer questions put by thousands of users who have banged their head in the same bug? It's insulting to have this circus happening on their doorstop.

I've never gotten this before.

And no, she can't use the phone as it was advertised. She has multiple apps that use iCloud for storage, and every time this happens, she just stops using the apps, as it can literally take hours of trying before she can successfully sign into iCloud.

Sounds like more than one. She needs to quit using the phone with "old" IDs, she's confusing herself and the device.

Get logged into https://appleid.apple.com/ and get it sorted out there. If you can't log into that, get on phone with Apple support until you can. As long as you didn't two step auth it, the phone support can and will help.

I'm not trying to debate, btw, I'm trying to legitimately help. Like most of us here, we end up being the support person for our family's devices, and I have seen people get themselves in a jam w/ the ID before. Clearly defining the Primary Apple ID won't be resolved until it's clearly resolved in the web interface.

So if the corner case of swapping user IDs for purchased items is enough to dump a phone, she's going to be desperately unhappy with the other alternatives out there which currently have countless more normal user UX annoyances.

Here's one for a new user: Let's say I'm looking at apps on my home screen, swipe left or right to see more apps. Great. I install something new. Not on the home screen. Swipe left or right. Not there either. This is an actual problem for normal users.

I also don't like having to pull out the battery every few weeks because the phone is frozen when I picked it up off the dock. This can happen from any background app. In the most recent case, turns out it was the foreground app, a clock called "Alarm" that I had coming up when docked in the landscape dock. Switched to Daydream, that problem went away, at least. But having to unplug the battery before I can make a call, definitely an annoyance. Glad it has a removable battery though, disassembling and reassembling the battery saves me having to press Home + Power for 10 seconds.

Ha, here's another one, as I'm writing this.

I just took a picture to talk about the UX of finding and sending that picture, but when I went into Apps and swiped left to look for Gallery (seriously, we can't just call it Photos?), the phone froze. Now I'm looking at the first page of icons half off the left of the screen, above a dimmed set of the second page icons. It's still stuck there as I type this. But the phone isn't frozen, I was able to take a screenshot of the built-in Apps browser being stuck halfway between two pages:

https://www.dropbox.com/s/z04qqbn4a93sxlb/Screenshot_2013-03...

As I'm finishing this paragraph, it's still stuck. By contrast, I haven't seen an iOS device crash swiping between the app icon pages.

While finishing describing the above, the phone dimmed, and then locked, as it should. I unlocked using face recognition, and was looking at home screen. Tapped to browse apps, and ... still frozen halfway between two apps pages.

This is native core functionality, simply not working. And like now, these things happen when trying to do something useful. That's a user experience annoyance.

Also the Play Store has a default option called "auto add widget"[1] that adds a shortcut to your home screen of any newly installed app, I personally hate that default behavior and always uncheck that option.

Is that all you could come up with for UX annoyances?

I personally think the experience on Android and Jellybean in particular is first class, if you just take things like the notification shade, the intents system and widgets, the UX on Android is unmatched.

[1]http://howto.cnet.com/8301-11310_39-57471256-285/how-to-stop...

Nope, but I refuse to be trolled by someone suggesting there aren't any. Just because YOU may not be annoyed, does not mean there isn't consensus that it still has a ways to go.

My phone didn't freeze when swiping the apps pages. Only the UI for swiping the apps pages froze. The rest of the phone, and all other running apps, are fine. That's not a defective phone. That's defective software.

Note that I never said Android Jellybean wasn't first class. I said if the woman is ready to dump a phone over trying to use an old account ID, she's going to have bigger problems with other operating systems which are not yet as polished.

“... A related issue is that the iOS interface is simply cleaner and more user-friendly than any Android interface I'd yet to see. One of Apple's slogans is "It just works." Well, actually sometimes it doesn't work. iTunes, for example, has been annoying me for years now. But, when it comes to device interfaces, iOS does just work. Android implementations, far too often, doesn't.“

“So, yes, Android does more today than Apple's iOS promises to do tomorrow, but that's only part of the story. The full story includes that iOS is very polished and very closed, while Android is somewhat messy and very open.”

— http://www.zdnet.com/blog/open-source/android-already-offers...

If you cannot imagine any UX annoyances, then most likely you fall into the “Android fans can be blind to its faults just as much as the most besotted Apple fan” camp.

Sometime last year I gave up waiting and started working on PouchDB (http://pouchdb.com/), its based on CouchDB's syncing model (and syncs with CouchDB) and works anywhere that Javascript runs (the browser + node), there is an iOS / OSX equivalent (https://github.com/couchbaselabs/TouchDB-iOS).

PouchDB isnt quite ready for production but its getting close, I would love any feedback on it, although I expect most people commenting on this would be more interested in TouchDB

How about the initial replication of larger databases? Do you roll out an initial version directly in your app or do you have some file based download of a snapshot?

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

We are renaming TouchDB to Couchbase Lite (still 100% open source), and have a bunch more tools for it:

Couchbase Lite container for PhoneGap: https://github.com/couchbaselabs/LiteGap

Couchbase Lite for iOS: https://github.com/couchbase/couchbase-lite-ios

Community mailing list: https://groups.google.com/forum/#!forum/mobile-couchbase

We are 100% serious about building the best damn database for mobile. Bonus points that it will seamlessly interact with other projects like PouchDB and friends via the sync protocol originally written as part of Apache CouchDB.

https://github.com/couchbaselabs/TouchDB-iOS

Of course, you would need to support some form of CouchDB server for this to work, deal with authentication, etc.

Reading documents from the local TouchDB store would block the main thread until the upstream CouchDB server would reply with the document's current revision, even if the local store already has an existing version of the document. Using GCD to wrap around these document transactions was still clunky at best and resulted in a poor overall UX.

YMMV, perhaps these issues could have been worked around if I had had a more realistic deadline and stayed in touch with the community. The maintainer, Jens Alfke, is very active.

Dropbox does not come close as alternative. Dropbox as of now is file-based sync. Core Data iCloud sync is trying to sync an always opened SQLite3 database file, they do it through database log files. Possible alternatives are TouchDB, Simperium, Firebase but then you have to change your app from not using Core Data. Or rewrite your app to use file based storage as what 1password did. The key is offline sync. File based cloud sync is solved problem. So maybe the way to go is persistent store of client app has to use files.

Edit: regarding offline sync (which I didn't address) something like AFIncremental store is a good example of how a local persistent store can be maintained in tandem with the online store.

(But, as you say, non- trivial and hard to get right.)

https://github.com/stackmob/stackmob-ios-sdk/blob/master/Cor...

And once you discover that you can't fix all the problems that Apple is struggling with, you have dug yourself into a VERY deep hole :)

It "just works" (if it actually worked).

With Dropbox, either you are storing everything for all of your users (and paying for it), or you integrate into the user's Dropbox account - which would necessitate a fancy ol' login/authentication system. Far from seamless, and relies on your users subscribing to something that is popular but far from ubiquitous.

So... either pay through the nose for all your users' storage, or force them to jump through some circus hoops on their own. Neither are great.

For apps that get a fair bit of off-line data creation this is a nice feature.

There's no way for a third party library to do this (at least not through iOS 6.1.3 SDK).

I haven't seen many complaints about iCloud's file syncing features, which are what Dropbox is the direct competitor to.

1) Google Drive - took my a long time before I even tried it, but it works about as flawless as dropbox for my needs. I actually like it a lot as I use Google Docs heavily, so it makes it easier to use those tools.

2) SkyDrive - offers the most base storage than the other. Has nice support for MS Office products.

3) AeroFS[1] - While it's still in beta, it looks promising (it has limited (android) to non-existant (iphone) support). [1] https://aerofs.com/

[1]http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-...

In my experience, it truly does "just work".

For developers, it's fundamentally broken as potatolicious describes https://news.ycombinator.com/item?id=5454729

If I have many apps that do the same thing, I'd have to go through each one to remember where I saved something. No, just no.

There are other places where Dropbox has advantages over iCloud (like doucments being shared between applications, even though the dropbox api seem to move away from that and on to sandboxed application folders), but for the points made in the original article, Dropbox provides no help at all.

Further, by pushing an app relying on Dropbox, you're telling your users to sign up for an extra service to use your app. That's bad.

I'd never use it for a large team, but for a couple of collaborators, or syncing a repository between multiple computers for a single developer, it's a nice and easy solution.