Will iCloud Be Easy for Developers?

The general trend since the late 90s and early 2000s has been to move computing away from native software and into the browser. Note that I used the term “browser,” and not the word “cloud.” They’re not the same thing.

The early days of the mainstream Internet were dominated by native software interacting with online content. Think AOL, Compuserve, and Prodigy. As the Internet evolved, though, and as web browsers became more mature, they eventually rendered those native programs irrelevant. Browsers provided universal access to everything the Internet had to offer. If you were a content provider, it became much more attractive to just put your content on the web where everyone could find it, rather than host specific content on one or more of the different proprietary networks.

The trend toward the browser as the primary gateway to the Internet continued unabated for almost 15 years (depending on when you start counting), until the iPhone App Store ushered in a renaissance of native software development. Today, it’s native mobile apps that are leading the way in terms of innovative interaction design, social integration, or new business models. Think Flipboard or Instagram or The Daily. But in a way, these mobile apps can be thought of as being in the tradition of the (shudder) AOL Windows app inasmuch as they provide a native interface to rich online content.

Steve Jobs laid out his vision for this future as far back as 2007 during a joint interview with Bill Gates at the All Things D conference. The interview took place after the unveiling of the original iPhone in January, but before it was available for sale in June.

Walt Mossberg asked Jobs and Gates specifically about the industry trend toward web apps, and whether companies like Apple and Microsoft, with their legacy of building native apps, were threatened with being made irrelevant by the rush toward migrating software into the browser. Jobs says what’s obvious now but wasn’t necessarily obvious at the time: if you really want a great UI, you just can’t use the browser. While the browser is becoming more capable with time, progress is slow, and in the meantime, sophisticated native software is increasingly able to run effectively on less capable hardware. Here’s the clip:

Sync Ain’t Easy

Why has web-based software become so popular in the first place? After all, it’s not as if web developers don’t care about UI design, or weren’t frustrated by the myriad issues web apps have integrating with the user’s desktop environment, or didn’t grow tired of hacking around browser limitations.

The reason web-based software became so popular is that web software offers significant technical advantages over traditional native software.

Web apps are accessible by anyone with an Internet connection, regardless of which OS they’re using; no more herculean efforts to port code from platform to platform, Photoshop-style. With free software stacks and commodity hardware, the barrier to entry to building a web app is minimal. Developers can choose their own implementation programming language and software tools, something most developers care about deeply. Since the software runs on the web server, bug fixes and new features are made available to the user instantly. It’s much simpler to automatically detect and report bugs encountered by users, and to control the environment in which they’re running to minimize bugs. And software piracy ceases to be a meaningful problem.

For the purposes of this discussion, though, a crucial advantage of web applications is that they instantly and elegantly solve the data sync problem.

Syncing data across native apps running on different machines has been an intractable problem for decades. Joel Spolsky wrote about how former Microsoft chief software architect Ray Ozzie basically devoted his career to the sync problem and ultimately failed. Dreaming in Code tells the story of how Mitch Kapor built a team of rock star software developers and poured millions of dollars into solving sync for calendars through a distributed, peer-to-peer solution. They ultimately failed, and the problem domain was soon rendered irrelevant by Google Calendar. Closer to home for the Mac and iOS software communities, the folks at Cultured Code have invested years in a custom sync solution for their excellent Things task management app that’s only recently entered private beta.

Sync is really hard. With the web, sync just vanishes. Apple is betting they can defy history get sync right ¹.

Will iCloud Sync Be Easy for Developers?

It’s one thing for Apple to nail data sync for their operating systems and their core applications like iWork. They have the expertise and the resources to devote to getting it just right. It’s another thing entirely to develop a general framework in which your average developer can nail data sync for their own applications.

Making things easy for developers is a crucial component of success in moving adoption of any technology. iCloud is no different. Apple is trying to make it as simple and transparent as possible for app developers. We just need to see how leaky the abstraction will be in practice.

One comparison that comes to mind from a development perspective is writing multi-threaded code. Writing multi-threaded code that’s actually concurrent is extremely difficult. Most developers understand the details of how to use mutexes and semaphors and condition variables. Very few developers, however, know how to use those constructs in such a way that they’re able to write truly concurrent code. What they end up writing is almost always either buggy, or full of lock convoys and thus not very concurrent at all, or both. (I’ve also never met a developer who thinks that that developer is him, but that’s a story for another day.)

iCloud needs to be easy enough for the average developer working on, say, a todo list app or a note taking app to sync her app data without getting caught up in all the complexity that traditionally comes attached to native sync. To take just one potential scenario that jumps to mind, how do you deal with new versions of your document that may be downloaded asynchronously from iCloud in the background while the user is working on it? Does Apple allow this scenario? If that is a realistic scenario, then based on what I know about iOS and Mac development, it doesn’t seem like an obviously straightforward problem to solve ². But it needs to be.

This is just one example of a real-life use case developers will be required to handle. There will be others. If the solution to these problems is qualitatively more complicated than just, say, adding Dropbox support to an app, then it’s going to be difficult for iCloud to gain adoption among the legions of tiny development shops that make the App Store what it is today. Apple and other larger firms with the resources to invest will support iCloud. Everyone else is either not going to go through the hassle, or their implementation is going to be a buggy mess.

I do want to qualify this pessimistic outlook by saying that I have tremendous respect for Apple from an engineering perspective. Typically their technology architecture and public APIs are elegantly and thoughtfully designed. However there were a few moments in the iCloud session I attended at WWDC where I thought, “Ohhh, this might not be as easy as it appears at first glance.” That feeling is what has me wondering what else may be lurking when trying to solve real-world problems.