Open Radar

 
Summary:

Sometimes it would be really useful for an app to get read-only access to another app's documents. Imagine an app that allowed students to submit assignments online to their professors. We'll call it "Submit-It.app". Assume the student creates some digital artwork in some third-party editing app. Currently, Submit-It.app has no way to get at the artwork. As a result, it has to register as a viewer for all sorts of file types, then hope that the editing app uses a UIDocumentInteractionController. Then it has to instruct the user to go to the other app, find the UIDocumentInteractionController button, and share it with Submit-It.

Not a great user experience, to say the least. It would be much better if Submit-It could get a list of documents being shared by other apps, and open a copy of any shared document.

In fact, there's already a mechanism for allowing document sharing: the UIFileSharingEnabled key in an app's Info.plist allows an app's documents to be shared... with iTunes. This has always been a weird model of interaction, since users generally don't expect to drag arbitrary documents into iTunes. In the "cut the cord" world of iOS 5, it makes even less sense. 

I'd like to request a new view controller, similar to UIImagePickerController. Rather than showing photos in albums, though, it would show shared documents in other apps. Selecting a document in another app would allow the current app access to that document. Some use cases, such as the Submit-It app, would only require read-only access to the documents. Some apps might want to allow write access to their documents folders in the same way that the existing file sharing mechanism allows iTunes to modify an app's documents.

This single new controller object would open up a much more natural mechanism of collaboration between applications, without exposing the underlying file system. It's opt-in, so it doesn't break existing sandboxing. It doesn't allow arbitrary access; the user has to explicitly select a document. Basically, it maintains all the user control while at the same time enabling some cool stuff.


-- Update --

Of course, there could be problems if an app attempted to open a file of some proprietary format that it didn't know how to handle. Core Data SQLite stores, for example, are essentially unusable unless the receiving app has access to the schema. But maybe the receiving app comes from the same company, and DOES have access to it. So you don't want to limit shared documents to just a few document types.

Requiring the receiving app to handle arbitrary file types could be problematic, as it requires all developers to implement graceful failure on unknown types. That's not likely to happen.

But there's already a built-in solution to this problem in iOS. UIDocumentInteractionController allows a user to open files in other apps, but only if those apps have declared themselves as viewers for that UTI. This new controller could use the same mechanism -- it would only show a shared document if the receiving app was registered as a viewer for that UTI. An app that knew how to handle only pdfs would only see pdfs. An app that knew how to handle certain data stores would have access to those. An app that just wanted to upload raw data to a web service could register as a viewer of public.data, and have access to all files.