Adam Fields had an interesting post about the problems of iCloud documents. Over on ADN Dan Frakes had an interesting discussion going on the same subject. Let me address Fields comments since I think he brings up some really good points.
First at this stage I don’t think anyone will argue iCloud is good. It’s sad to say that after two years but it’s the truth. A surprising number of developers are dropping iCloud as their primary sync mechanism, presumably because of how unreliable it is.1 To me the unreliability issues are a far bigger problem than the issues Fields lays out.
Ignoring reliability issues though I think Fields raises a good point that others have before him. As is iCloud simply doesn’t offer a usable workflow. In its current form it clearly is oriented around saving application state and conceives of documents as just an other state of the application. While that’s fine for some apps it isn’t for the general case. Many iOS applications allow documents to be opened by other applications. For instance I have an app that works with Google Drive that lets the spreadsheet be opened by Number. It’s never a clean sharing though since I’m really not sharing my document at all. I’m merely copying it into the other application.
This is the real issue. There’s no way for applications to truly share data beyond the limited capabilities of contact, calendar and film role sharing.2 I’ve said here before and I’ll say it again. iCloud with 10.8 and iOS6 is the middle of a rope and it’s not clear where Apple is going.3 I think it safe to say that where ever Apple is going it’s thinking through document sharing in a profound way. iCloud seems broken simply because it is missing this key component. Even the changes to iWork, like “Duplicate” are almost certainly a slow introduction of this rethought sharing scheme.
Apple’s done robust data sharing before with OpenDoc. It didn’t turn out well for a variety of reasons. Apple knows that iOS devices will become more powerful. It also knows that trying to replicate the windowed workflow on a touch device is a lost cause. I’m honestly not sure what Apple’s solution consists of. I suspect we’ll see the following though.
1. Categories of Data. We’re part way there already. We have five special categories of data: photo/video, events, todos, mail, contacts. Presumably we could throw in location/directions, tweets, and Facebook’s things.4 I think it would be fairly easy to extend this to spreadsheets, presentations, and word processing documents and more. Dealing with documents of a similar type but different format (say Word vs. Pages) might be tricky. But the idea makes a lot of sense and could be argued is an extension of the idea of document descriptors in OSX as is.
2. Share Data Types. Once you have the type applications could register for them. Presumably Apple could extend the actions possible from a kind of read only use to outright editing. What kind of security and limits they’d put here aren’t clear. Whatever they do I suspect it’ll take a few years to evolve into something fully usable. Hopefully they’ll learn from the failings of shared documents in the 90′s without limiting themselves to the same extent that OSX Services or the sharing in Win8 and Android do.
This honestly handles most everything. It ends up allowing an extension of what we already see on OSX and iOS. OSX was already heading towards specialized apps that focused on one datatype and managed that datatype and metadata better than the Finder does. While both iPhoto and iTunes have huge limits — especially with large datasets — the fact is that allowing those apps to manage your data makes tons more sense than using the Finder (or even the more media-savvy Windows Explorer). That clearly was the direction that Apple was heading with iOS as well. Ideally you could then have different viewers for the same dataset.
In OSX Apple moved to that with Aperture and iPhoto. One wishes one could have a 3rd party “iTunes Pro” that shares data but allows different ways of manipulating it. So an OSX and iOS Podcasting app could simply use the main music stream with the podcast subtype. Data would automatically be synced between iOS and OSX. You could ideally even have multiple podcast apps, each using the same data.
It’s here the things quickly become complex. The main problem with iTunes for many users is that the data stream is optimized for small datasets. Get above about 30,000 songs and iTunes starts to falter.5 Get above 50,000 and I hear it becomes extremely frustrating. What about Pro users with more data?
Add into that database complexity the issue of metadata. iTunes has a fairly static set of metadata it supports. Yet if you have a shared data stream you’ll quickly have applications want to add custom data. How does Apple handle this in a robust fashion? I’m not sure. It’s clear their current solutions are lacking though. iPhoto and iTunes’ databases are infamous.
Still, even if there are problems, I think it’s at least reasonably clear the general direction Apple is heading. I think iTunes points the direction. That’s why I had so much hope iTunes 11 would point to a new generation of UI. I’m not sure what Apple intended with iTunes 11, but it clearly was just a slight modification to what came before. The next step is still waiting.
- Omni, for instance, is coming out with their own syncing system. When one of the preeminent Obj-C houses does that you know there’s a problem. However even apps that support iCloud often support Dropbox or other custom syncing methods. This ought be a concern for Apple. ↩
- I say limited since there’s not easy ways to add extra data to one of these documents. There are often other gotchas as well. You are left with hacks that don’t interop well. ↩
- Doubly so given the recent shake up at Apple this fall that may have changed many plans they already had. Or at least course corrected them somewhat. ↩
- I used Facebook so little I don’t know what an entry there is called. ↩
- It’s probably no coincidence that iTunes Match limits you to 25,000 songs. ↩