iCloud -- specifically the iCloud frameworks for syncing Core Data databases -- has been getting kicked around lately, and by almost all accounts, deservedly so. Back in November developers like Instacast's Vemedio and Steve Streza of Informal Protocol posted about their problems with it and its opacity, and Paul Haddad expressed similar concerns during the second episode of Debug. More so even than Siri and Game Center server issues, it felt like proof positive that Apple faced significant challenges in a future where online services were as important as native software.
As much as iOS 7 and iCloud are more important for Apple than next-generation hardware, iCloud is arguably more important than iOS 7 because, for Apple, it's an even bigger challenge.
Since then, more developers have come forward to share their frustrations with Core Data sync. In a post intended to reassure users of NetNewsWire about the app's future in a post-Google Reader world, Daniel Pasco of BlackPixel wrote:
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.
What seems to make the ongoing issues so vexing for developers is that iCloud was introduced with iOS 5 back in 2011, and while iOS 6 in 2012 was an improvement, it wasn't anywhere nearly improvement enough.
Ellis Hamburger of The Verge did a brilliant job summing up much of the reaction and reasoning, calling iCloud Core Data sync a broken promise:
Many veteran developers have learned their lesson and given up on iCloud’s Core Data syncing entirely. "Ultimately, when we looked at iCloud + Core Data for [our app], it was a total no-go as nothing would have worked," said one best-selling iPhone and Mac developer. "Some issues with iCloud Core Data are theoretically unsolvable (stemming from the fact that you’ve put an object model on top of a distributed data store) and others are just plain bugs in the implementation," he said.
One of the reasons for this is, just like with Game Center APIs, Apple has very little skin in the Core Data sync game. They're not making massive use of it, so they're not the first ones hitting pain points and problems. Their developers are, and that's a terrible, terrible thing for everyone.
Matthew Panzarino of The Next Web also pointed out that Apple conflating several distinct services all under the iCloud banner further compounds the problem developers face:
Recent criticism of Apple’s iCloud has exposed just how fractured the brand actually is behind the scenes. Developers are having problems with some of the technologies bundled together under the name and it’s causing some confusion. The truth of the matter is that there are really two iClouds, which couldn’t be more different.
Users who get their mail, contacts, or calendars synched without issue just don't understand what developers are complaining about because, for them, iCloud works, it just doesn't work in that developer's app. That leaves some users thinking developers are actually incompetent or lying.
Glassboard developer Brent Simmons, on Inessential, added that that's the risk of depending on systems you can't control:
How comfortable are you with outsourcing half your app to another company? The answer should be: not at all comfortable.
Just like services are the future for Apple, they're the future for a lot of developers. More important than hardware, arguably more important than software when that is already a core competency, iCloud is what Apple has to nail. Rather than getting kicked around, iCloud has to kick ass.
Update: Rich Siegel of Bare Bones software has weighed in with some interesting technical details on the different ways iCloud works... and doesn't work. It's not possible to pull a single quote out of his piece, so go read the whole thing on his Mistitled blog.
