Rene Ritchie thinks Apple should provide direct document access with iOS 6 through a dedicated Files.app:

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.

I agree with the notion that the current Open In, app-based document transfer model of iOS is broken. The simplicity brought by iOS freed average users from the complexities of the filesystem; people who like to get their daily work done with iOS devices, however, miss a unified document filing system. Paradoxically, the “simple” iOS, with its “Open In” menu and multiple copies of the same document, requires people to manually manage more.

In February, I envisioned something similar to Rene’s proposed Files.app solution:

So, I had an idea. I think the same iTunes File Sharing feature would work a lot better as a dedicated, native iCloud app for iOS devices (and maybe the Mac too). After all, if Apple is providing an iTunes-based file management utility for Mac users, why couldn’t they build an app that enabled any third-party iOS app to save and import files from iCloud? This app would be built into the system and allow users to simply collect documents, like iTunes File Sharing. Developers could easily add options to their apps to import files from “iCloud File Sharing” and export files to it. Users would have the same feature set of the existing iTunes File Sharing, only with an interface they are already familiar with, because iCloud File Sharing would resemble the existing file management workflow of iWork for iOS or iCloud.com. The only difference is that it would be integrated on a system level, work with any iOS app, and basically be an extension of the “Open In” menu that already allows apps to communicate with each other through supported file types.

After having tried the latest developer releases of Mountain Lion and putting some more thought on the matter, though, I am not so sure about the centralized repository system anymore. Namely, I am not convinced it should be a separate app.

Rene rightfully compares the possible Files.app to the existing Photos.app for iOS. Files could present document folders the same way Photos displays image albums, and it could have the same systemwide hooks to let other apps access documents from the unified repository. However, there is a difference worth noting: Photos.app gets its contents from a primary, hardware-based component of iOS – the camera. A user takes a picture, it goes into Photos. Same for videos and screenshots – the interaction is simple.

What is a file, though? Is it a text document? RTF or .txt? If so, does Files.app come with preview capabilities for those file types? Or is it about PDFs, .zip archives, folders, and .cbr files? And how do you get documents into Files.app?

Even by only slightly mimicking the Finder, Files.app could reset the past five years of “simple” iOS interactions in one big fell swoop. Photos itself, which is extremely straightforward, is criticized for its file management features. Now imagine that applied to the general concept of “files” with folders, views, sorting options, settings, and previews.

Today, I think what I wrote back in September could make for a better solution: inter-app communication.

Why can’t Apple build an invisible layer that lets Elements edit a text document from Evernote and Pages access the same file?

It turns out, a possible implementation of such layer already exists, but iOS won’t let apps communicate with it. Enter iCloud Documents & Data:

The same interface is available on OS X:

And in Mountain Lion, the standard file-saving dialog has been enhanced with the addition of an iCloud option (image via Macworld):

The design is slightly different since the first Mountain Lion Developer Preview that Macworld reviewed, but the concept has stayed the same throughout betas: Apple apps like TextEdit and Preview can “hold” documents into a special iCloud folder (located under Library/Mobile Documents/appname/Documents on OS X); these documents also show up on iOS under Documents & Data; currently, they are not available on iCloud.com, nor is Mountain Lion’s file-saving UI allowing, say, Preview to easily grab a file from TextEdit’s own iCloud “folder”. However, on Mountain Lion, Apple says that you can get your “existing documents” into iCloud by dragging them from the Finder or “other apps”.

If the system Apple has been putting in place is of any indication, I think enhancing the app-based model with better communication would actually outmatch the possible benefits of a separate Files.app. Documents & Data could become a document picker developers can enable in their apps with an API; because apps register file types they support, Apple wouldn’t have to worry about creating a Files.app capable of previewing every single format out there. GoodReader could open a PDF from Pages’ iCloud, and Pages could later access that same PDF with the changes made by GoodReader.

I am arguing that apps should become their own centralized locations that other apps can access and interact with – without creating duplicate files. Apple can’t provide the basic preview/edit functionalities of Photos for every possible format supported by Files.app, but 600,000 App Store apps might have the solution for that. Rather than creating an additional layer of management – disconnected from apps – iOS 6 could turn the interface already in place into a document picker that gives files their proper meaning: the app they belong to. Only with the addition of inter-app access and “universal save” to avoid duplicates.

Making changes to a single file with a variety of apps is something we do every day on our Macs. On OS X, there’s the Finder that acts as a glue between apps and files. By design, the technical constraints of iOS have turned non-destructive editing into a clunky and confusing experience, as we’ve seen with iPhoto. I am arguing that instead of building a “Files.app” or “Finder for iOS”, Apple could leverage the existing iCloud Documents & Data UI, and rework the iOS architecture to allow for changes to the same document from multiple apps.

The centralized Files.app idea is certainly appealing, but Apple has heavily invested in the app metaphor for the past years, and rather than replacing it with a new layer, I wouldn’t mind seeing it get smarter.