Frustrated with iCloud, Apple’s developer community speaks up en masse

Some are turning away from iCloud altogether after bad user experiences.

Apple's iCloud is marketed to us end users as a convenient and centralized way to manage data on all of our Macs and iOS devices: sync contacts and bookmarks, re-download music and apps, back up iOS devices, and sync documents and data for third-party apps as MobileMe did. The last item, syncing of documents and data, is one of the least glossy features of iCloud, but it is one of the most important, and it should be among the most straightforward. Right?

Perhaps not. Almost a year after Apple shut down MobileMe for good in favor of iCloud, third-party developers have begun to speak out about the difficulty involved in working with Apple's cloud service. A piece published at The Verge this week highlights many of those complaints, with quotes coming from well-known developers and anonymous sources alike about the challenges faced by the developer community. From data loss and corruption to unexpected Apple ID use cases, developers have seen it all—but are stymied by the persistence of problems that prevent them from shipping products with working iCloud support.

What's the big problem, exactly? According to Bare Bones Software's Rich Siegel, there are a number of moving parts to iCloud that all affect how things come out on the other end.

"In concept, the service is pretty simple. A central iCloud server holds the truth: the canonical version of the user's data for an app. As the user manipulates an app's data, iCloud tracks and reconciles the changes into the central truth and makes sure that all copies of the data, on each computer, are brought up to date," Siegel told Ars. "In order for this to work, though, a lot has to happen behind the scenes. What we casually refer to as iCloud is many parts, each with a role to play."

Indeed, there are multiple ways in which iCloud enables the syncing of data, though both users and developers are kept in the dark when things go wrong. Siegel described scenarios in which iCloud simply declares that a file upload has timed out ("Apart from not being semantically relevant, the message is also unhelpful because it doesn't provide any information that either the user or developer can apply to diagnose and resolve the problem"), or says that corrupted baselines are causing sync problems without making the problem visible, or just plain barfs up an opaque, internal error. This has resulted not just in headaches for developers, but also in inconvenience, confusion, and even anger on the part of end users, who go on to rate applications poorly because of these symptoms.

"When it fails, there's no option to recover—all you can do is try again (and again...) until it finally works. And when it does initialize successfully, it can take an extremely long time," Siegel said. "In some cases, we've seen delays of up to 25 minutes while waiting for the iCloud stack to initialize. There's no discernible consistency or rationale for when it says no and when it finally says yes... you can just keep trying, and eventually it might just work, or not."

Opaque errors are just the beginning—developers are also frustrated with how iCloud handles a user's data if the user chooses to turn off document and data syncing. Doing this, it turns out, completely removes a user's locally stored iCloud data. And signing out of iCloud results in the system moving iCloud data outside of an application's sandbox container, making it impossible for the app to use the data any longer. The assumption here is clear: you're either using iCloud exclusively for data storage or you don't want to use that data at all.

Indeed, Core Data is one of the main parts of iCloud causing headaches for developers. Black Pixel recently mentioned its own Core Data problems in a blog post about the future of NetNewsWire's syncing capabilities. "As far as sync is concerned, we knew we would likely need an alternative to Google Reader as early as last year. At the time, the option that seemed to make the most sense was to embrace iCloud and Core Data as the new sync solution of choice. We spent a considerable amount of time on this effort, but iCloud and Core Data syncing had issues that we simply could not resolve," wrote Black Pixel's Daniel Pasco.

Another developer Michael Göbel wrote in a blog post titled "Why all my iOS Apps are on hold": "Core Data and iCloud sync are still a joke. I can’t count the number of developers and companies that all ran into the same trouble and finally gave up—meaning they dropped iCloud support completely after hundreds of thousands of users lost their data."

Siegel expanded a bit upon some of the problems Core Data presents. "This is where the rubber meets the road for database-backed applications," he said. "Core Data is the application-level database framework supplied by OS X and iOS that provides the means for applications to store items, and data about those items, in a single database."

Returning to the iCloud signout problem, he explained how his company ran into problems dealing with the limitations of Core Data and sandboxing with its product Yojimbo.

"The recovery from iCloud signout involves taking the opportunity to migrate all of your Core Data storage from 'Mobile Documents' to the private sandbox container on your Mac. We found, to our dismay, that the practical reality didn't hold up to theory—part of the problem is that you don't get notified until after the data has been made inaccessible, and once in that state, there's no choice but to use Core Data to make a copy of the data that's just been sequestered," Siegel told Ars. "And of course, given a database of sufficient size, the process of using Core Data to relocate the database ties up the application in an unresponsive state, without visible progress, for as long as it takes. (And woe betide you if something goes wrong in the middle of it.)"

These are only some of the issues iCloud has presented to third-party developers, and Apple reportedly has not been effective. Some—including Black Pixel—have begun to create their own syncing services, while others opt to rely on other solutions like Dropbox. Others still are holding out hope that Apple will hear their cries and offer some help. "We and other affected developers are continuing to iterate with Apple regarding the technical problems we've run into. However, if iCloud sync can't be made to work, perhaps another service will do the job," Siegel said.

It's one thing to merge conflicts on your own data model. You know what's right. Excuse me. You can design your system and data model so that you know what to do when merge conflicts arise.

It's another to claim you can merge changes to two relational databases that have diverged.

I'm curious about this, but I'm by no means a programmer or database expert. However, I thought we'd solved the issue of multiple connections to the same database long ago. Why don't these apps update a database in the cloud instead of local > synch? I assume it's an issue of latency and not wanting to lock an app while waiting for the database to respond that the transaction is committed?

It's one thing to merge conflicts on your own data model. You know what's right. Excuse me. You can design your system and data model so that you know what to do when merge conflicts arise.

It's another to claim you can merge changes to two relational databases that have diverged.

I'm curious about this, but I'm by no means a programmer or database expert. However, I thought we'd solved the issue of multiple connections to the same database long ago. Why don't these apps update a database in the cloud instead of local > synch? I assume it's an issue of latency and not wanting to lock an app while waiting for the database to respond that the transaction is committed?

Or you want to allow apps to run offline and then sync when they can. There are lots of reasons to want it - the problem is that Apple promised it and then it failed to work well. Honestly I am surprised they even offered it - it is a very tough problem. But it's just another software-/developer-side failure that is, as always, at odds with their user experience. Whoever runs their software division sure must know where the bodies are buried, to still have their job...

in early Feburary this year, the developers of Outbank, a popular banking application for iOS and Mac in Germany, had realized (after massive negative user feedback), that there was something terribly wrong with iCloud Sync, so they decided to publish an open letter to customers and share it with Apple. It shows the problems and issues you face as a developers when developing apps using iCloud. See full letter here: Outbank Open Letter or read the Google translation here: Outbank Open Letter (Google Translation)

Great post about Outbank and their letter to Apple.I know German and went to their website and found a great 1 minute video. The basic idea of the video is that you want your banking to work even if you are in the bath tub and your iPhone gets wet. You still want to be able to sync with your other devices, i.e. your Mac laptop and your iPad. I don't think there is an English version of this ad but the basic idea is that while shaving, the man learns that the water in his house has been turned off because he hasn't paid his water bill. Not to worry, a man appears in his bath tub and tells him about the great Outbank application. Later he becomes convinced and uses the Outbank app to do his banking via his iPhone. Then his iPhone falls in the water. Not to worry again, the Outbank app can use other devices.Also on the Outbank pages, in German, Outbank mentions their interactions with Apple, after they published the initial letter. For now, Outbank is not using iCloud to sync their application. http://vimeo.com/54520584

There target customers are the app providers rather then the end user however.

SQL Database is a "database in the cloud / database as a service" solution. It's a centrally stored database, ala something like what Runkeeper is running. This already works just fine and is not the problem developers are complaining about.

SQL Database falls down pretty fast if, for instance, you want to allow your application to run offline for any reason. This is what CoreData sync is supposed to allow and doesn't.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Other than "It's a very hard problem"? Mapping an object graph atop a database and then syncing. That's hard. Remind me who else has solved this problem. It's mostly edge cases where the problems lie. It's been frustrating for devs and users who encounter the problem, but not everyone has this problem. I haven't seen it, for instance.

And iCloud itself is not so much a problem (as this article doesn't make clear). It's iCloud <-> Core Data. That's why Pages works very nicely. They're not using Core Data.

Let's try to look at the Core Data problem by comparing it to something equivalent in the Microsoft world.

Windows NT Domains maintain a database of objects that need to be accessible from everywhere in the company. For example, the centralized user account information needed to log you on to the various computers at your company.

The Really Old WayThe way this database of information has been shared and updated has changed over time. Originally, there was only one place in the entire company, the Domain Controller, where this database was stored, could be accessed, or could be changed. If the one and only Domain Controller failed (or became inaccessible due to network trouble) you just couldn't log on till it was fixed.

The Old WayWhen Windows NT 4 came out, Microsoft decided that having a single point of failure was a problem that needed to be fixed. They developed a model where there would be more than one Domain Controller with a copy of the database.

To prevent the sorts of problems we see in Core Data, they only allowed changes to the database to happen in one place. That place was called the Primary Domain Controller. There could also be multiple copies of the database stored on one or more Backup Domain Controllers.

When you needed to make a change to the database, you contacted the Primary Domain Controller, made the change, and then the PDC would send a copy of the change to each and every BDC.

If the Primary Domain Controller was unavailable, then you just couldn't make changes to the database until the problem was fixed. However, if you just needed to access a copy of that data to log on to your computer, any of the BDC's worked fine for that.

The Current WayIn a really big company that is spread out over multiple locations, not being able to reset someone's password because the network link to the PDC is down is a problem.

Microsoft switched over to a system that is like Core Data where you allow changes to happen to the database in more than one place (Active Directory Domain Controllers) and then you attempt to keep all the information in synch.

Here's the problem. When people are making changes to the same user account in multiple locations at the same time, conflicts arise. Active Directory has to decide which version of the change "wins".

They don't so much try to make sure the "right" version of the data "wins", as they try to make sure all the databases agree as to which one "wins". If all else fails, believe it or not, Active Directory uses a random number (GUID) generated when the DC is installed to decide which change wins. (Whichever DC that made a change and has the lowest random number "wins".)

Here's the ugly truth. Some parts of the Active Directory database are so important that Active Directory doesn't even allow you to attempt to make changes to them in more than one place. (The Schema, for example) There is no way to prevent conflicts when you allow changes in multiple places, so for the most important data, they don't even try.

Only one Active Directory Domain Controller in the entire enterprise allows you to make changes to that particular part of the database because if something went wrong with it, the whole database would fail.

Active Directory is 12 years old. This problem hasn't been solved yet because it cannot be solved when communications between all copies of the database cannot be completely reliable.

Core DataCore Data is trying to do the same thing Active Directory does. Allow you to store the same databases in multiple places, make changes in any of those places, and then somehow sort out the differences.

This can't possibly always work the way the user expects it to work when you allow changes to occur in multiple places at the same time. Especially when the devices have extremely unreliable network connections.

This could be fixed by making the iCloud version of the Database the only place changes can be made, like Windows NT 4 did. (Have the copy of the database on iCloud act like a PDC) However, users would likely be pissed if they couldn't make or save changes to their data because their data connection to the cloud went down.

When you allow changes to multiple devices simultaneously, bad things are guaranteed to happen. When you are trying to do this with data for an application Apple didn't design in the first place, you are adding complications on top of complications.

The best thing that can happen (if you insist on allowing multiple changes in multiple places simultaneously) would be that Apple would help app developers show the user the conflicts that have arisen and then allow the user to decide which version of the information they prefer.

Then that choice must be propagated everywhere and the devices must come into agreement again. (FSM's noodly appendage help you if one of the devices is unreachable and the user decides to make a change to the database on that device in the mean time)

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Other than "It's a very hard problem"? Mapping an object graph atop a database and then syncing. That's hard. Remind me who else has solved this problem. It's mostly edge cases where the problems lie. It's been frustrating for devs and users who encounter the problem, but not everyone has this problem. I haven't seen it, for instance.

And iCloud itself is not so much a problem (as this article doesn't make clear). It's iCloud <-> Core Data. That's why Pages works very nicely. They're not using Core Data.

I understand it is hard, but they have been working, and failing at it for years. So either cancel the project or figure it out. And yes, others have done it. NCR is one example of a company that somehow manages to sync data and database objects across multiple devices, even if connections between devices are down. I'm sure others have figured it out as well.

Having worked with Apple devs before and having a few friends developing software for iOS (mostly games), it's kind of shocking that Apple hasn't been more responsive to this problem.

Devs are important to a platform ... they're the reason why so many apps are available. This combined with Apple's increasingly abandonment of the professional market is very troubling.

Apple simply doesn't care about developers. They make a ton of money and so why should they change? They are like Sony and the PS2 - a bitch to develop for, but the money rolled in. Hence the PS3, but when there was another game in town suddenly people didn't have to put up with their crap (and hence the new Sony brainwave of actually talking to developers).

Nothing will change at Apple because they are making money hand over fist, and devs will (and to some extent, given the size of the market, have to) struggle with whatever poop comes out of Apple...

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

No, if you were an investor, you'd want profits.

And Apple can provide them by ignoring developer complaints and telling their users that everything's OK.

That's not nice, but it is the easiest and simplest way to make large profits.

That's why developers are trying to use numbers to protect themselves - speaking out en masse means that Apple can't either ignore - or worse punish - an individual.

I don't want to start a flame-war, but isn't this the business model that Microsoft slipped into during the 00's? Just rest on your laurels, keep cranking out things that meet some demands, but don't cleanup things that were kit-bashed / band-aided together?

Maybe it's on their plate to address soon. But, seems they're sticking with their business model that made them successful ... "don't fix old tech, just invent new tech." iWatch anyone?

It's really too bad. I would love if my video games like Final Fantasy IV saved state to iCloud so I could play on both my iPad and iPhone. I was wondering why gaming companies weren't embracing storing game saves on iCloud so this article makes a lot of sense.

Some games do it rather well or, at least, it seems so. I have Clash of clans installed on both my iPhone and iPad and as soon as I open the game, GameCenter (which must be tied to icloud ou itunes account in someway) log me in and I get the game in the same state I left it on the other device, a few seconds earlier.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Other than "It's a very hard problem"? Mapping an object graph atop a database and then syncing. That's hard. Remind me who else has solved this problem. It's mostly edge cases where the problems lie. It's been frustrating for devs and users who encounter the problem, but not everyone has this problem. I haven't seen it, for instance.

And iCloud itself is not so much a problem (as this article doesn't make clear). It's iCloud <-> Core Data. That's why Pages works very nicely. They're not using Core Data.

I understand it is hard, but they have been working, and failing at it for years. So either cancel the project or figure it out. And yes, others have done it. NCR is one example of a company that somehow manages to sync data and database objects across multiple devices, even if connections between devices are down. I'm sure others have figured it out as well.

Dealing with the modern connected public hundreds of millions of individual (accounts) people changing things left and right is a hell of a lot harder, than dealing with business clients whose total numbers will never get even close to the general public.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Actually not really true... if you work at Apple as a software engineer you have to 'drink the kool aid' as part of the admission, and since some of the best engineers are outspoken, have blogs, etc... they actually don't acclimate to Apple's unique corporate culture.

Apple's strengths have never been in their software anyway, it's always been in their design, marketing, and hardware. And that's where their engineers are amongst the best. Software side frankly, has always been lacking but it's also never been as big a focus. Why spend the money on the software side when people will buy your pretty box and install Windows on it? They make the money on the hardware, so that's where they focus.

Actually not really true... if you work at Apple as a software engineer you have to 'drink the kool aid' as part of the admission, and since some of the best engineers are outspoken, have blogs, etc... they actually don't acclimate to Apple's unique corporate culture.

Apple's strengths have never been in their software anyway, it's always been in their design, marketing, and hardware. And that's where their engineers are amongst the best. Software side frankly, has always been lacking but it's also never been as big a focus. Why spend the money on the software side when people will buy your pretty box and install Windows on it? They make the money on the hardware, so that's where they focus.

My apologies. I was under the impression that Apple did have good software people as well. I don't know a lot about that end (I work for financial not-for-profit credit unions, and spend most of my time trying to encourage people not to blow their life savings at the drop of a hat ). If software was lacking at Apple, how did they make some of the fairly nice things that they did make? I used to own a Performa, and loved it! Also, my iPod which has worked perfectly for years - which means the software continues to work well.

I am by no means an Apple fanatic. I own a Samsung Galaxy SIII, and my computers at home run Windows (though I'm about to *gulp* try to set up an Ubuntu box all by myself!). Still, as a company, I always thought they had fairly smart people working there - definitely smarter than me!

I don't think that's correct. They are working on a different solution, but sync still works (more or less reliably). I am pretty sure they do use iCloud / Core Data to sync. Also I get these random data losses which supports this. Isn't that bad because the actual bookings cann still be downloaded from the banks' sites, so I only loose the labels, which is annoying, but only so much as long as it's only a few every couple of days.

The resolution is clear for developers. Simply drop iCloud and use Dropbox. I almost never have any issues with Dropbox. It just works. I, like many others, have found iCloud to be unreliable and its deletion of local data when it is turned off or disengaged is a hostile, undesirable maneuver.

Turn off iCloud as your default. Launch Terminal from your Utilities folder in the Applications folder. Once Terminal launches, type or paste the following command in:

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Other than "It's a very hard problem"? Mapping an object graph atop a database and then syncing. That's hard. Remind me who else has solved this problem. It's mostly edge cases where the problems lie. It's been frustrating for devs and users who encounter the problem, but not everyone has this problem. I haven't seen it, for instance.

And iCloud itself is not so much a problem (as this article doesn't make clear). It's iCloud <-> Core Data. That's why Pages works very nicely. They're not using Core Data.

I understand it is hard, but they have been working, and failing at it for years. So either cancel the project or figure it out. And yes, others have done it. NCR is one example of a company that somehow manages to sync data and database objects across multiple devices, even if connections between devices are down. I'm sure others have figured it out as well.

As long as you only allow changes to happen on only one copy of the database, anybody can synch multiple copies of a database perfectly. It's not a difficult problem at all.

Optionally, you can require that every instance of the database make the same change at the same time. This is the traditional SQL database way.

Notice in the Cons section they mention that once communications latency goes up, the problem can quickly become unsolvable.

We are dealing with attempting this when communications between the copies of the database don't just have latency, they have completely unreliable communications in the first place.

Replication between multi-million dollar database instances of the NCR sort you mention1) Use highly reliable, redundant network links2) Use Distributed Transactions where all copies of the database must make the same change at the same time, or none of them are allowed to make a change at all

The resolution is clear for developers. Simply drop iCloud and use Dropbox.

I hate to join the pile-on, but that's not the resolution. DropBox doesn't do what Core Data's database sync does. DropBox does file sync. So does iCloud, and it works pretty well. What iCloud doesn't do well DropBox does not even attempt.

Is anyone doing a good job with what Apple is attempting? It has alot of moving parts as said. Just pushing a button to back up a drive or files is much different than consistently backing up with multiple computers in environments.

Google?!

You have to be kidding me right?

No, the closest product Google has is Google Drive, which is a Dropbox clone. Syncing files is a totally different (and much easier) problem. As others have already pointed out, the file syncing part of iCloud works fine. It's applications that are trying to use the Core Data framework that are running into trouble.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

What I'd like to see is a comparison between platforms. As far as I can tell, what Apple are trying to do is rather more ambitious than competing platforms, in that Apple promises, to an extent not promised by Dropbox or Skydrive or suchlike, to automatically resolve conflicts (including handling issues like who performed what changes in what order).

Now one could argue that it was foolish for Apple to promise this handling before they could deliver on it, that they should have JUST offered up the equivalent of Dropbox; but putting that aside, as far as I can tell a primary reason for the difficulties is that Apple are trying here to do something beyond what has been done before. That's inevitably going to have teething problems. Add in Apple's traditional opacity, so no feedback on where the service is going and how it issue will be resolved. Add in Apple's (justified or not) ultra-aggressive sandboxing, and all that implies for data-sharing within and across apps, across users, and for debugging. And you have basically all the ingredients for a perfect storm of anger from both developers and users.

I'm not justifying Apple here, I'm answering your question about how this happened even given a (presumably) high quality of engineering. There are going to be a huge number of responses that boil down to "I hate Apple" and "I hate sandboxes" --- useless noise. What I hope is that there are ALSO a few responses that have something to say about the reality of multi-source sync via Dropbox and SkyDrive, and what would be the consequences if Apple were, for example, to give up on its current ambitions and revert to such a simpler model.

So, apparently keeping complex data structures in sync across multiple nodes is a tough technical problem which Apple failed to solve. Nothing wrong with that. However, I wonder why they claimed (by releasing iCloud) that they solved it? Is it a technical incompetency (inability to validate their software) or managerial zealousness? Apple being known for both it's hard to tell.

It's worth repeating that iCloud Document Sync works perfectly fine. This is the same type of service as Dropbox.

Yes, and most probably it's even based on standards (WebDAV + sync-collection from rfc6578).

countcracula wrote:

iCloud CoreData Sync == There is no similar service to this, it's not interchangeable with Dropbox or G.Drive

Yes, but AFAIK it is built on top of the "dropbox"-like service. The latter syncs DB transaction logs from all devices, and a client side mechanism tries to magically consolidate all the changes. Apparently, this mechanism is not working correctly and hard to debug because it's complex and mostly opaque.

But what I wonder is why devs don't just use the iCloud document sync to transfer their app specific transaction logs, and implement app specific sync on top of that. That's not much different from what is needed to sync via DropBox or GDrive, but without the hassles for end users to authorize a third party storage.

Of course, it's still disappointing to realize that Apple couldn't fulfill their promise to automagically solve multi-device database sync (but for anyone who has ever seriously worked on DB sync, no surprise).

As a consumer I just don't understand what iCloud even does. My wife has owned an iPhone for 3 years and asked me if she should sync to iCloud instead of her computer. My answer is consistently I have no idea, because I don't really understand the limits (she has like 15 GB of music, 15GB of photos, and then 10+ of movies) and don't know if it's just better to sync with her laptop.

And then of course I tell her just to back up the laptop often, but surely that's not as freeing as the cloud, but it sounds like it doesn't work right anyway.

Have you never used Safari across multiple devices? THAT is (part of) the iCloud vision, at least the interesting part that is being discussed here. It's extremely nice, late at night, to pick up an iPad and read some tabs that were left open on an iMac during the day because the article was too long to read at the time.

If you try to do this today, you'll also see the limitations in the vision; most obviously that you can't "swipe" the item, in the list of remote tabs open, to have it shut down on your iMac. That may come with iOS7/OSX10.9

Consider now two cases where this DOESN'T happen. One is passwords. Wouldn't it be nice if your keychain were somehow (SAFELY!) in the cloud, so that when I move to a new iPhone I don't have to, one site after another, enter all my passwords? Or I dojn't have to sync my password across five devices when I change it for one site?

Second is shared state in Maps. Again something I do frequently is plan a route on, say, my iPad. Then, when I go to Maps on the iPhone I expect search to auto-populate the list of options as I type with the places I was looking up on the iPad. But right now this is not done --- Maps does not share state between devices. But again it probably will in iOS7.

The VISION Apple has in mind is that you can buy a selection of Apple devices, in a range of form factors, from watch (hah!) to phone to tablet to laptop to desktop; and they can all be optimized to do some things well, not everything poorly, because they will all work together. To get this to work, however, synching has to work well, and it has to be easy for both developers and users. Apple have arguably pushed parts of this vision too fast (as others have said, perhaps they should have limited themselves to key-valud and document sync, at least for now); but to argue that this is all the result of stupidity, or inability to copy Google, or marketing madness or anything else, reflects ignorance. What Apple are trying to do here is beyond what any other company is trying to do; and you should at least understand the goals and why they make sense before criticizing them.

But honestly, when a dev says that a web service hangs their app for 15-20 seconds?

Multithread? Asynchronous? I dunno about iOS programming, but EVERY other modern OS has that ability.

Expect a webservice to be slow...

Okay, imagine you have an API call that is "allow me access to my application's data". I can multithread the heck out of my app, but all I'm going to be able to do with my other threads is show a gorgeous 3-d glass reflective spinning wait animation, maybe play the Final Jeopardy theme music, do a Star Wars-style scroll of text begging the user not to be too pissed off, because I'm not going to be able to do anything that the user actually _wants_ until that thing returns.

_That_ is the situation here.

Again, I don't do iOS dev, but every client side API I've ever used?

They document the fact that it is ASYNCHRONOUS.

Launch a thread, await a response, throw a gif, whatever. In all honesty, if a dev ever says 'I called function X and my app hung for 10 seconds' then they are seriously lazy.

Seriously, even if it wasn't a callout to a web service, if you see 'HEY! THIS API CALL IS SLOW' then freaking multitask it.

Like I said. I *hate* Apple. Sure, they could do more, but I don't believe dev's when they claim that their app hangs on external code. They can mitigate it. Easily.

And the thing you don't get, which makes you look like a complete idiot, is that they ARE calling these things asynchronously. But if the data you depend on to make your application work doesn't come, there isn't anything you can do but WAIT. Multitask all you want, that still isn't going to help anyone.

Clearly you are the one that doesn't even program.

OK on that I call you at fault.

Call it asynch, then either launch a loading icon, or process other data.

If your program HANGS on that call, then you are NOT calling it ASYNC. Or if you are, then you are NOT doing it properly.

Put, say, a 10s timeout, put up a loading icon, callback to remove the icon and display the data, on timeout or other error display could not connect to server...

THAT IS NOT A HANG! A hang is when it just does nothing. For an indertiminate length of time. THAT is why I'm saying these dev's need to handle it properly.

What you seem to not be understanding is that there are apps where, without getting data back from iCloud, there is literally nothing you can do besides show a constant loading screen / error in an endless cycle. It's a horrid user experience, yet is Apple's issue, not the developer.

The application cannot run without the CoreData database. Apple has the database but cannot deliver it. What do you do? You're fucked unless you have a local cache to work from, which will still just irritate the user because it's not the latest version of what they are expecting.

Name such an app.Because the apps I have used with this problem suffer because they ARE poorly written.Take, for example, a travel app like Kayak or TripIt. Both of these appear to hang when you launch them, apparently because they are trying to sync their data store. In both cases (especially when you are in a foreign country with no wireless connectivity) they hang until they time out. In both cases this is technically avoidable, and stupid UI. From the UI point of view, the common case is that the user wants to view what is already stored on the device; synching is not an essential issue. The synch should run in the background. And if there is an important fear that the device will be displaying out-of-date material (a fear that is largely imaginary, but whatever), then display data in some sort of "preview" mode while you wait for the synched data to come in --- use a grey font rather than black, or change the background color to purple, or slap a bar across the top of the screen with 'PREVIEW --- DATA SYNCHING IN PROGRESS" across the top of the screen, or whatever.

The common case is NOT "this app is useless until the very latest data comes in". The common case is "there is a substantial store of data locally --- email, web pages, travel data, articles to read, whatever your apps does; and the user can usefully interact with that stored data until the synch is complete". I defy you to give me one app for which the model I have described is not more useful than your "block and do NOTHING useful until the synch is complete" model.

It's one thing to merge conflicts on your own data model. You know what's right. Excuse me. You can design your system and data model so that you know what to do when merge conflicts arise.

It's another to claim you can merge changes to two relational databases that have diverged.

I'm curious about this, but I'm by no means a programmer or database expert. However, I thought we'd solved the issue of multiple connections to the same database long ago. Why don't these apps update a database in the cloud instead of local > synch? I assume it's an issue of latency and not wanting to lock an app while waiting for the database to respond that the transaction is committed?

AND you want your apps to run when there is no network connectivity. You may live in the same land that many Ars-ians appear to when you claim this doesn't matter to you, But Apple takes this very seriously.And even when there is network connectivity, you want your app to use limited resources --- limited cell bandwidth, limited radio power --- which means sensible batching, rather than an ongoing connection with the database with constant data back-and-forth.

This has nothing to do with dropbox, or file sync.... But has everything to do with Apple just doing it wrong. As I stated before there are many organizations doing this, and doing it well... MS has been for a while in one way or another (AD, sharepoint, etc.). Google also has deep roots in sync/async database structures as evident by their Google docs environments, as well as their entire platform, everything works on super massive databases.

Apple thought it could make it easy for developers to not have to front the expensive infrastructure and handle their database needs, and they can not. Apple took something that works (a relational database) and then tried to make it work in a way it was never designed (asynchronous). There is no way to make this work well, and when things break with databases you have MAJOR issues. File sync is easy - everyone does it, backup systems have been in place since computers have been around, so the idea is solid and works well. There also is very little magic with syncing files where you are the only one touching them

But things get complicated when you need to be able handle database operations in environments where connectivity is not always guaranteed. Add to the mix the ability to make changes on multiple offline clients and then expect something good to happen when they do actually connect just adds to this mess.

Apple seriously needs to re-think this process and work out a way (as another poster mentioned) to elect how changes are made to the data, better ways to handle situations when the cloud data-store is not available, and above all keeping data in a consistent state. If a db re-initialization could take up to 25 minutes, you just lost a customer... Not to mention the fact that the data became corrupt in the first place is quite concerning.

A lot of you are talking about how mail/calendars/contacts are soo different, but in my experiences with iDevices they have the same issues as above. You would not believe how many users I see where they turn on iCloud and sync their calendars, and then enable that on another iDevice only to realize they now (somehow) have 4 copies of everything in their calendar... This all falls back to database issues. Yes apple's calendar uses iCal to sync, but iCal has NOTHING to do with how the data is stored on the back-end. Without good controls there you are left with nothing reliable.

It's really too bad. I would love if my video games like Final Fantasy IV saved state to iCloud so I could play on both my iPad and iPhone. I was wondering why gaming companies weren't embracing storing game saves on iCloud so this article makes a lot of sense.

Batman Arkham City saves to "Game Center", and I've lost my version half a dozen times. I went back to Bootcamp, bought the game (again) on Windows (for 10% of the price) and now have the maddening log-in experience of Windows Live (even on the Steam version)... but, I haven't lost a save yet.

From the UI point of view, the common case is that the user wants to view what is already stored on the device; synching is not an essential issue.

That may be a common case, but according to this article, it's not possible for applications using iCloud Core Data sync.

name99 wrote:

The synch should run in the background.

Sure, but the article says that sometimes it takes a *really* long time for that to happen, if it happens at all, and the app has no data to display (not even old crufty data) until the sync happens.

name99 wrote:

The common case is NOT "this app is useless until the very latest data comes in".

Apparently that *is* the case with iCloud Core Data sync.

name99 wrote:

The common case is "there is a substantial store of data locally --- email, web pages, travel data, articles to read, whatever your apps does; and the user can usefully interact with that stored data until the synch is complete". I defy you to give me one app for which the model I have described is not more useful than your "block and do NOTHING useful until the synch is complete" model.

You might want to go back and read the details in this piece -- the "one app" would actually be *every app* that uses iCloud Core Data sync, because your model ignores the fact that that's not how Core Data sync works. It deletes all your data when you turn off sync, and then re-downloads it when you sign back in. Are people turning off iCloud sync all the time? No. Do they do it sometimes? Yes. Does a commercial app have to support turning sync on and off? Of course it does.

"...developers are also frustrated with how iCloud handles a user's data if the user chooses to turn off document and data syncing. Doing this, it turns out, completely removes a user's locally stored iCloud data."

So, there is no locally available data store that the app can do anything with. And the app may hang for up to 25 minutes before eventually getting the iClouds stack to initialize, if it ever does. Your Mac deletes your local data when you turn off syncing. According to all the developers who've been talking about this topic, that's just how iCloud syncing works, and it seems to be one of their big complaints.

Keeping users and developers in the dark is an Apple trademark--nothing new there. IIRC, didn't Apple recently finish a 5,000-server farm in N.C. dedicated to the Apple iCloud? Maybe I read that all wrong--which is very possible. In any event, let's hope Apple isn't using OS X to run its servers. ( It would, however, explain a lot.)