Sunday, June 5, 2011

iCloud Is for Developers, Too

Apple uncharacteristically let spill that a new service called iCloud would be featured in Steve Jobs’ keynote address for WWDC next week. While iCloud has been talked about as a consumer cloud service, its position as an integral part of a developer’s conference is interesting. Pictures of the banners going up in the Moscone Center prominently feature iCloud, and one of the banners even reads “Lion + iOS5 + iCloud = WWDC,” mirroring the same three points emphasized in the press release. iCloud may have as much to offer developers as it would consumers.

The wording on the banners suggests iCloud will be a subject of developer training, just like the OS X and iOS 5. There are some interesting possibilities for a system-level cloud service accessible to both Macs and iPhones, and some pitfalls as well. A big draw of cloud-based services for mobile devices is the possibility of syncing content and settings easily via an official API. The implementation, of course, isn’t without potential pitfalls.

For those who have both an iPhone and an iPad, it would be great to have access to Pages documents on both devices. Make some edits and save to the cloud on the iPhone, and then pick up the same document on your iPad and continue writing. It would also be nice to keep achievements and unlocked levels for a game in sync, so you don’t have to start over if you want to play on your iPad at home and on your iPhone while commuting. Access to a shared filesystem is required to make this happen.

But, wait! Can’t I access files on MobileMe from Pages now? Sure. The iWork apps for iPhone and iPad include support for accessing your MobileMe file storage via WebDAV. A number of apps have WebDAV support, but that’s the only way to access MobileMe files. There’s no system-wide approach or MobileMe SDK for developers to use with iOS. Right now, the SDK only supports access to local files stored on the device itself.

The filesystem on iOS devices today is “sandboxed,” so apps can only access their own files. Essentially each app gets its own little corner of the device storage to play in, but it can’t interfere with other apps and their files. One solution would be to just mirror that part of the filesystem up to iCloud. Imagine if cloud storage access were as simple as it is to allow iTunes file transfer access today. Replacing iTunes file transfer with a cloud solution would likely get developers excited, as it could make moving files between iOS devices much easier than having to resort to email or other clumsy solutions.

This approach has the benefit of being dead simple, but it creates the potential for conflicts. What does the app do if I’ve unlocked all the Classic courses for Super Stickman Golf on my iPhone, but I’ve been playing the Super courses on my iPad? I would love to merge the two settings files and unlock both sets of courses on both devices, but I’d be a tad unhappy to find that I got one and lost the other. Developers would have to manage these kinds of collisions, and Apple could probably help.

When we get into more complicated cases, like trying to share files between two different apps, it’s clear that we need a system-level solution to the problem, because it would be a nightmare for both developers and end-users if they were left to their own devices for resolving conflicts. Still, Apple provides access to shared storage from multiple apps right now via things like the on-board Photos library, so it should know a thing or two about directing traffic and regulating shared access.

Syncing settings and documents from the iPhone to iCloud opens up lots of interesting possibilities, but it also presents some real challenges due to the possibility of overwriting files or mismanaging merges. Apple is going to focus on the user experience first, and make sure that any such service works consistently across apps so that users understand what will happen with their data. That sounds like exactly the sort of thing that developers would want to hear about next week at WWDC.

No comments:

Post a Comment