How Apple could provide direct document access in iOS 6

The Photos app has provided a centralized iOS image repository for years. A Files app would bring the same functionality to iOS documents.

For a couple of years now, before every major release of iOS, I've begged and pleaded for a native iOS documents repository. Not a file system like OS X, but something that would do for documents what Photos.app and the photo picker do for images.

Right now, even absent a file system and hierarchy, it's still too complex, confusing, and unwieldy for users to remember, find, and attach documents in iOS. iOS 6 is a chance for Apple to change that, and a Files app and documents picker are simple, consistent, convenient ways to do it.

The problem. Times iCloud.

If I have a text document in iOS, I have no way to directly access that text document. I have to go to an app and hope that I can access the document from that app. If I created a text document in Simple Note, I have to remember I created it in Simple Note because chances are I can't easily open it in Drafts, much less in Apple's Notes app. If I have a Document in the Cloud, it's the same problem only worse. I can't just see Documents in the Cloud. I have to keep a mental list of what I've created over time and their associations, which is a lot of overhead for something that's supposed to be simple.

Conversely, if I have a text document in Dropbox, I can open the Dropbox app, see a list, pick the document I want, and send it to any iOS app capable of handling it. It's not elegant, but it works, and it fills a void left by Apple.

Frankly, I'd rather Apple fill it. They already do it with Photos. They already do it with Music. They already do it with videos. Files deserve equal status under the OS. Since Apple has has already done a lot of interface work for Documents in the Cloud, the material is all there. They just have to give it a face.

Mapping Photos to Files

As I've argued before, the template for a useful Files.app and documents picker is already present in iOS with Photos.app and the image picker. On the iPhone, iPod touch, or iPad, you can launch the Photos app and see a list of Albums, one of which is your local album, Camera Roll, another of which is your iCloud album, Photo Stream, and the rest of which are any albums you've manually created and moved images into.

Tap an album and you see a scrollable grid of the photos contained inside it. Tap a photo, you see the photo. With the Action, Edit, and Trash buttons, you can perform various image management, modification, and sharing tasks.

Now imagine you could launch the Files app a see a list of Folders, one of which is your local folder, Documents, another of which is your iCloud folder, Documents in the Cloud, and the rest of which are any folders you've manually created and moved documents into.

Tap a folder and you see a scrollable grid of the documents contained inside it. Tap a document, you open it in QuickView. With the Action, Edit, and Trash buttons, you can perform various file management, modification, and sharing tasks.

Mapping image picker to document picker

Photos.app isn't the only way to access your pictures in iOS. There's also the image picture. It's an iOS controller that allows other apps, built-in and App Store apps, to access your photos. You can use it to both open images in apps, and save images from apps. It functions as a central image repository for iOS.

Launch Messages, tap the camera button, and the image picker lets you attach pictures to an iMessage or MMS. Launch Instagram, tap the pictures button, and the image picker lets you choose a photo to apply filters to and share. Launch AutoStitch, build a panorama, tap the Action button, tap Save to Camera Roll, and your composite becomes available in the image picker for any other app.

(Vexingly, while Mail.app can save images from an email, there's still no Messages-style camera button so you can add images to an email on-the-fly.)

Now imagine there was a documents picker controller that allowed other apps, built in and App Store, to access your documents. You could use it to both open documents in apps, and save documents from apps. It would function as a central document repository for iOS.

Launch Mail, tap the Files button, and the documents picker would let you attach a document to an email. (I can dream, can't I?) Launch Elements, tap the Files button, and the documents picker would let you open and edit any plaintext file on your device or in Documents in the Cloud. Launch Notes, create a document, tap Save to Files, and your document becomes available in the documents picker for any other app.

iOS already knows which files can be opened in which apps -- it shows you a list of compatible apps in the "Open In" Action (see the Dropbox cloud store example at the top). To keep things simple for users, it could only show compatible documents when the documents picker is called.

Also, it wouldn't replace the auto-save feature of apps like Notes. Those could still be saved within the and even synced the way they are now, utterly transparently. Document picker would just add the option to move a document to the central repository, the way photo editing apps can move a local image to the Camera Roll for universal access.

Mapping Photo Stream to Documents in the Cloud

With Photo Stream, if you've chosen to enable it, any photo you take or image you save to Camera Roll gets automatically copied to the Photo Stream album, stored up on iCloud, and pushed to every other iOS device on your Apple ID (for one month or until 1000 other photos have pushed it off, whichever comes first), as well as iPhoto and/or Aperture (until and unless you deleted) on OS X, and the iCloud directory on Windows.

That's incredible from a backup and accessibility standpoint.

Take a photo of your child playing soccer at the game, your family can see it near instantly at home on the Apple TV. Take a screenshot on your iPhone and almost immediately drag it from iPhoto to Photoshop on your Mac.

Documents in the Cloud already ties into iCloud, but it lacks a user accessible interface on iOS like Photo Stream has with Photos.app.

It lacks Files.app.

Conclusion

iOS has become a mature operating system with text editing, multitasking, better notifications, and more. When it comes to file access, however, it's still in its infancy. Basic, needful things like attachments are still inconsistent between built-in apps like Message and Mail. Worse, Apple desire to abstract file systems to make things simpler for users has resulted in different, rather than less, mental overhead.

A unified document repository, modeled after the existing unified image repository, rounded out with more consistent attachment options, could be the best of all worlds. Users wouldn't have to remember which folder a document was in, nor which app. They wouldn't have to jump around to edit or share. Users could simply open any app capable of editing or sharing a certain type of app and go to work.

Having everything handled by a central Files repository and document picker would also keep Apple's sandboxed security model intact, at least as intact as letting email attachments or cloud store files open in compatible apps, or having a Photos app and image picker. It isn't as open or as useful, but is more secure, that full inter-app communication. It's not even Windows Phone contracts. But is far more useful than the model we have today.

I've wanted a Files app for two years running. Hopefully third time will be the charm.

So what you're saying is, you want a visible, rudimentary file system - but this is the kind of thing Apple seems intent on avoiding.
Also, consider what it means to have that universal file management picker with access to iCloud. The way iCloud works, each app has to implement its own support for it. This isn't something automatically provided by the OS. What happens when a document created in Pages and synced with iCloud is opened in another app that doesn't support iCloud, is modified and saved, then opened again in Pages? What happens when you give apps access to other apps' documents, resulting in unintentional (or intentional) corruption of user data, and going against Apple's sandboxed design? Or do you grant apps read access to those files, but force them to save duplicates (like iPhoto) into the shared file repository? That doesn't feel helpful.
I'm not saying that I don't agree with the problem, but I'm not sure this proposed solution quite nails it - digging into it, it feels like there are significant conceptual and implementation issues.

What happens now with the photo picker is that apps have read access to those photos, but they cannot overwrite them. For example, if you open a photo in iPhoto and make edits to it, a new copy of that photo is created within iPhoto's own library. You can also create a duplicate photo in the system photo with those changes, but you cannot overwrite that original photo from any non-core apps.

That breaks the very first use case you cite:
If I created a text document in Simple Note, I have to remember I created it in Simple Note because chances are I can't easily open it in Drafts, much less in Apple's Notes app.
But if you cannot edit it in Drafts, or Apple's Notes app, then you do have to remember which app created it, because you can only edit it in Simple Note. You can open it in Notes -- but now, if you want to change it, you have to back out, find the right app, and then start that one instead, when you were already just viewing the document in the first place.
This makes the "hunt for the app" situation much worse, because now Apple has to present you with two lists (or at least different treatments on the same list) -- something that shows you not only what Apps can open a file, but what Apps can edit a file -- and that list is going to change from file to file, depending on what app initially created it.

That should say, "You can also create a duplicate photo in the system photo library..."
One of iOS's pillar design decisions was to make an OS without a visible file system. This has introduced a lot of issues. In time, some have been addressed well, some have been addressed poorly, and some have been addressed not at all.
This is obviously a big one - the ability to to share files between apps. To make modifications to a single file among a variety of apps. It's something we do every day on our Macs, and iOS to date has either not addressed it at all (documents), or has addressed it poorly (photos).
I'm certainly not trying to belittle the thinking done here, but I feel this particular solution necessitates undoing too much of iOS's fundamental architecture.

OK - if we say that apps can only make modifications to documents created by themselves, and duplicates of any documents not created by themselves, that feels like it can work today within iOS's constraints.
However, personally, I think it's quite clunky. I think iPhoto's management today is clunky. It almost feels like a placeholder for something that's coming. Something more elegant. Like you, I hope it does.

i'll agree. as much as it sucks, iOS was made to be a crippled version of OS. if an iPad was to get all the file system functionality who would still buy an airbook? the divide between iOS devices and Macs/MacBooks would narrow so much that the end user would have a tough time justifying purchasing a full device. I dono't think this is something that they want and they'll try their best to keep it that way, an iphone will never be a laptop in your pocket, neither will an ipad.

It's easy...Apple builds a file system, like Finder or Windows Explorer (which is miles ahead btw). Every file of every app is saved there and every file can be opened from the right application. The application itself won't have a different file system, but just use Apple's and save the changes back to the original file! Which means, that the files are shared...no need to save multiple versions of the same file on every different app!

In this way, there is no issue with iCloud (wow what an invention...like dropbox doesn't do the same, only better..), since Apple's file system can be set up to sync the files and folders that are needed for every app...and btw, most apps just share databases, not complete files, as far as I know.

Anyway, it is easy and it can be done...it is a must for people who use the iPad as a serious tool and not for stupid games...Apple must create a complete file system.

I wish I had a windows file system setup on my iPhone. I fell in love with my iPhone when I first bought it (4S). Now I feel that for true functionality it needs to be jail-broken (which I don't like), or it needs updates which Apple is slow to release. I have invested a lot of money into apps and such and it would be a shame to switch devices due to that but I feel the iPhone lacks some basic amenities. I also have the new iPad and it is even more evident that the device isn't functioning at its full potential. If anything honestly needs a file system it should at least be the iPad. I will wait to see what 0S6 has to offer and if the only significant change we get is widgets than I seriously might start considering other devices.

I use the same workaround but have also added OTIXO.com. They allow direct access to your Dropbox from programs such as pages and numbers using the WebDav protocol. This has been a great help. I too would like a file.app program... Perhaps a way to import TrueType fonts into my iPad the way InkPad allows me to through DropBox for that program only...

hi rene,
well written. you've been on a roll lately; i also enjoyed the one you wrote about the implications of changes to the iphone screen size.
as to your proposed changes, i notice that you mainly address usability, which is fair enough. what about, for example, the security aspect, though? i can't help but wonder if apple considers that an essential part of the iphone user experience: never having to second guess if an operation will compromise your iphone

from a security perspective (which i think is one of the reasons apple implemented the app sand box)

from a stability perscpective (apps may trip over badly implemented file formats)

from a consistency perspective ("hey, why can't this app open the file i want to edit?")

i think imore could enhance your article by addressing these considerations directly; the accessibility of documents is a sore thumb on ios and needs some serious thought. something that you evidently have been working on.
thanks for that.
cheers,
mbotta

I addressed security in passing, since this model doesn't seem any riskier than letting Mail or Dropbox "Open In" a compatible app, which they do now. It's the same one Photos app uses, and Apple seems okay with that.

one of the premises for your article appeared to be the inadequacy of the current system in which at most you can get an app to offer you an "open in" button for processing a file in another app.
i am guessing that apple hasn't provided more fine-grained controls for the reasons i listed (security, stability and consistency - apologies for the atrocious layout in my initial post). hence my suggestion to imore to enhance by addressing those concerns in addition to your excellent points on usability.

I love this idea! However, I would like to add the ability to handle files that are unknown to any app. Sometimes.I would like to be able to save a file from an email attachment for future transfer to a computer that has no internet access. And conversely I'd like to be able to transfer in a file unknown to any app to send as an email attachment.
This basic file/document handling is to me the single biggest barrier to stopping the use of other computers in the workplace.

I LOVE this idea you have presented. I think you have nailed the concept and would have loved to have this when I was taking online classes. I also agree with some of the post above, stating the lack of a files.app does prevent from full adoption in some cases.

I agree completely that iOS needs a unified file system that allows easy round tripping (I.e. opening/creating, viewing/editing, and saving) of files regardless of which app you're in. HOWEVER I definitely take exception to the idea that apps would also save separate "app local" versions of documents. That is a recipe for confusion and disaster (unless there was complete and automatic syncing of said "app local" versions with the centralized Files repository, in which case, why bother with the "app local" versions at all?)
I use Dropbox + iWork + dropDAV and it works well enough, but it's not nearly as elegant as an in-built Files repository could be.http://www.iPadAlone.com

No, we just sticky whatever the last "cover story" was for the day. Before this it was Simon's free iPad games, Leanna's photography post, etc.
I do, however, pour chocolate sauce all over mine and add a cherry before posting, which might make the extra sticky?

IMO, the basic problem is that people associate files with 'projects' not apps. When I'm thinking of a file(s), I'm wanting a bunch of related files together. They might be from a whole bunch of different apps. I don't think... now, what app did I write the document in?
Apple usually makes pretty smart moves on this kind of thing, but in how iOS deals with files, I've never been able to figure out what the heck they were thinking.

This is perfect! The only thing you left out was that this also brings up the upload file feature in safari!!
I'm a college student and I always take online courses over the summer and I have to do a lot of my work when I am on vacation or not home and I just do it on my iPad. The problem is that I can finish all of my work but I can't submit it until I get home.
Enabling file upload (through your file picker method) would be a huge plus and completely allow people to use their iPad for school withouth a computer at all!