The Problem With iCloud

July 10th, 2012

The last two months, I’ve been busy working on the 1.1 update for Basil, which you’ll be hearing more about soon. I’ve also been thinking very hard about what the next big version of Basil will look like and so naturally I’ve also been thinking through how syncing should work. This seems like an easy question to answer: iCloud. If only. I wish it were that easy, but it’s not.

iCloud’s promise is a dream: your contacts, calendar, backups, songs, documents and application data are on all of your devices, whenever and wherever you need them. No need to worry about moving files from device to device on a flash drive or emailing them or any of the other crazy stuff we used to do. All of your stuff, always there when you need it. If that were completely the case, it would be a no-brainer for me. I’d implement iCloud syncing immediately, because that idea—never having to worry about where my stuff is again—is one of those ideas that makes my heart flutter with excitement.

Unfortunately, that’s not the case. The first issue is that iCloud restricts syncing, and thus your application, to iOS and OS X devices exclusively. This probably isn’t much of an issue for many, if not most, kinds of applications that will only ever be on iOS applications, but for others, choosing to use iCloud places an unscalable wall around the application’s data because iCloud offers no way to access the data it stores from the web or other, non-iOS and OS X devices, at least for now. For example, let’s say Marco Arment was building Instapaper today, and chose to use iCloud to sync articles between devices. Marco would need to build an iPhone, iPad and Mac application for users to read and add articles on all of their devices. And that little “Read Later” bookmarklet we all love so much, which allows you to add new articles to Instapaper from your browser even if the device you’re on doesn’t have Instapaper installed, wouldn’t be nearly as useful. You could have a bookmarklet, but like how Basil’s “Add to Basil” bookmarklet works, Instapaper would have to be installed on the device. Worse, when you tapped the bookmarklet, it would have to launch Instapaper. All of the applications which have “Add to Instapaper” options would have to do the same thing, too.

This bizarro-world Instapaper wouldn’t be nearly as useful a service as it is now. Social features, like the ability to follow what articles your friends like, would be impossible, and expanding the service to other platforms would be, too. Of course, that doesn’t mean iCloud is a “bad” service. Apple’s goal is clearly not to build a cross-platform syncing solution for others to build their businesses on top of. Their goal is to make their own platform better and easier to use. But those limitations are absolutely something developers have to think very hard about, because if their application could evolve into something greater than just an iOS or OS X application, they’re stuck if they choose the fork in the road labeled “iCloud.”

Even so, for a lot of uses, iCloud should be terrific. Odds are that many developers have no intention of expanding their application outside of iOS or OS X or implementing features that could require accessing data outside of them. For these developers, and for their users, iCloud syncing is perfect. It keeps all of their data in sync, nothing to worry about. Unfortunately, though, implementing iCloud is no easy task. There’s no iCloud flip to switch when creating an application. While Apple’s public description of iCloud makes it sound trivial to implement iCloud syncing, without getting too technical, there are a very large number of serious pitfalls in the service that developers have to address themselves. If they don’t, the application could crash due to the user turning iCloud off, or syncing could stop working altogether, silently. Not good. (If you’d like to read the technical details, Drew McCormack wrote an excellent series of articles on iCloud and Core Data.)1

So once developers decide to head down the iCloud road, there’s potentially a lot of maddening little gotchas they’re going to have to figure out so their users don’t lose data or don’t suffer through odd issues that crop up. Perhaps that’s to be expected; syncing data isn’t exactly an easy thing to do well. But it’s also quite different than the message Apple’s conveyed to users, which is that iCloud is a bit of magic which moves all of their stuff from device to device. With how Apple’s presented it to users, it must be a bit mystifying and, worse, frustrating for them that most applications don’t yet adopt iCloud syncing.

Both as a user and developer, I want iCloud to live up to its promise. I hope it does soon. But the reality is that right now, it isn’t there yet, and for developers, choosing between iCloud and their own custom sync service is no easy choice.

  1. I should also note that “iCloud syncing” includes two quite different things: document syncing and Core Data syncing. Document syncing, for applications like Byword or iA Writer, generally seems to work quite well. iCloud syncing for applications using Core Data (Core Data is a framework Apple provides for persisting data), though, has been very problematic for developers to implement. This is why many of the applications that do offer iCloud syncing are document-based applications. []