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.

It is often said that Apple doesn’t offer a filesystem for iOS devices. Sure enough, it is indeed not possible to manage documents and folders on an iPhone or iPad as you can on OS X. Apple does, however, offer a very basic file management system that works with iOS apps, and you’ve haven’t probably used it too many times:

Introduced with iOS 3.2 and iTunes 9.1, iTunes File Sharing allows applications to import files copied from a Mac or PC using iTunes, and export to a computer. In iTunes, all you have to do is connect an iOS device, head over the Apps tab, and choose File Sharing below the Home screen app management interface. You can copy almost any kind of file into an app’s internal directory dedicated to file sharing, and several iOS apps use this method to import or backup files and documents such as bookmarks, videos, or spreadsheets. I’ve often used this feature to import .avi files to watch on my iPad.

iTunes File Sharing doesn’t seem to get the attention other iTunes functionalities do, and I believe there are a couple of reasons behind this. First off, it’s quite cumbersome: the interface for File Sharing is buried within an iOS device’s settings in iTunes, and there are no options to, say, automate the process of importing files or setting up favorite sources for documents. Second, iTunes File Sharing only solves a partial problem, in that the majority of iOS users don’t lament the lack of a proper Mac-to-iOS file management system as much as they’re asking for an iOS-to-iOS centralized file storage solution that would also happen to sync back to a Mac.

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.

I wouldn’t call such an app “Dropbox from Apple”, as Dropbox is mainly developed as a solution to sync files between computers, running in the background all the time, whereas this would be more oriented towards giving apps a better file sharing system. In fact, I imagine Apple could go as far as indicating the apps that can receive an iCloud file as they currently do with iTunes File Sharing for better organization and to maintain the app-driven model. iCloud File Sharing would play well with this strategy, and it would offer a basic way for developers to integrate iCloud in their apps.

Apps like GoodReader have already implemented a similar system of iCloud-based file management, and some third-party developers are experimenting with providing standalone apps for file management purposes over iCloud. A default utility from Apple would have the obvious advantage of not requiring any additional download: it would be integrated as a system action in any app for iPhone, iPad (and even the Mac). Apps would still have their own iCloud libraries and synced data; the file sharing part would ditch iTunes and become iCloud-powered (iTunes File Sharing would be kept around as an option for transferring large files such as videos through USB).

You might argue that Apple is trying to eliminate the concept of the filesystem altogether by embracing the app model with data silos that are self-contained and user-friendly. As iTunes File Sharing seems to be suggest, though, I think that Apple knows the app model and iOS only solve so much when it comes to file management — Apple has to deal with the fact that many people still work with files and folders, export them, move them around, and manage them. I believe the real winning scenario for Apple would be to make the management process as lightweight and intuitive as simple by relying on iCloud. Thus, iCloud File Sharing would serve as a better solution than iTunes File Sharing, ans it would strengthen Apple’s offerings requiring no or little effort from developers, ultimately providing an accessible way to manage files atop of Apple’s existing free 5 GB of storage for every iCloud account.

Unfortunately, it doesn’t look like the upcoming iOS 5.1 will introduce such a feature, and I’m not holding my breath for a surprise announcement during the iPad 3 event. But for the next major version of iOS, if Apple doesn’t think a better way to let apps communicate with each other is needed, I believe an evolution of iTunes File Sharing towards iCloud would be a sweet stopgap solution in the PC-free era.

Back in November when I took a look at the Mac App Store release of Aptonic’s Dropzone, I was impressed by how the utility transitioned to the Mac App Store whilst keeping most of its functionalities intact. Through a simple drag & drop interface, Dropzone allows you to save time on common and oft-repeated tasks such as sharing images and bits of text, uploading files to your FTP server, or moving files from one location on your Mac to another.

With Dropzone 2.0, released today on the Mac App Store, Aptonic has been inspired by Path’s radial menu (introduced in version 2.0 of the app) and created a new drag & drop interface based on Circles, which as the name suggests are circular icons that sport pretty much the same animation seen in Path 2.0 for iPhone. I don’t know if the new Circles system is more intuitive than the old dock/menubar-based grid of icons (as a Dropzone user myself, I’ll have to see how Circles works in daily usage and if the feature doesn’t get in the way), but it sure looks very nice. Aptonic has also put together an HTML5 demo of Circles, available here.

Dropzone 2.0 comes with other features and improvements as well:

• New improved Amazon S3 support
• New task completion sound
• Added an option to choose whether to intall applications in the user or main application folder

Like I said, I’ll have to keep on using the new Dropzone to see whether the new Circles interface can grow on me. I love the custom sharing menu in Path, but I don’t know yet if the same approach can work for file management and the various shortcuts I have set up in Dropzone. To celebrate the launch of version 2.0, Dropzone will be available at $9.99 until February 5th.

Way back in 2009 I first reviewed Dropzone, a dock-based utility by Aptonic that, through a grid interface allowed users to quickly perform common but tedious actions like uploading images or sharing text with a single drag & drop. Later, I took another look at Dropzone as a way to effortlessly download Mac apps as .DMG files, and have the app automatically extract the contents of a disk image and install an application for me.

With the 1.0 release on the Mac App Store today, Aptonic had to make a few changes to Dropzone in order to be approved by Apple and sell its app on the Mac’s native digital storefront: Dropzone is now a menubar app — which you can still decide to launch on login — and gone is the dock access that was also made popular by Dropzone’s own icon and Stacks-like appearance. However, in spite of the technical changes, Dropzone 1.0 still shares the same user interface and set of actions of the previous version: for those not familiar with the concept of the app, Dropzone offers a series of built-in actions (and others that you can manually download and install) to perform tasks automatically and save precious seconds and clicks when working with your Mac. So, for instance, you can drop pictures onto Dropzone’s window and have them uploaded to Flickr, or compressed in a .zip archive and emailed to someone. You can drop files and move them to a specific destination on your Mac, or configure FTP servers and directories if you find yourself constantly uploading files via FTP every day. Dropzone aims at letting you save time with boring tasks and, at the same time, quickly share items with your friends or coworkers without going through separate clients and web upload tools.

Dropzone is very lightweight, and it’ll ultimately make your life easier through drag & drop. Version 1.0 is available at $13.99 on the Mac App Store.

Last night we detailed how it’s possible to sync documents across multiple Macs configured with the same iCloud account through a hidden folder in Lion’s Library called Mobile Documents. As I explained in the article, this folder is actually the destination and sync location for iCloud-enabled apps, such as Instacast and iWork, that have been updated by developers to officially take advantage of iCloud’s Documents & Data. But as it turns out, Mobile Documents can be used for syncing files across Macs “manually” — just drop a file or folder in there, and it’ll show up on another Mac running the same iCloud account. So whilst Mobile Documents is “officially” used for App Store apps that work with iCloud, it can also come in handy as a native “drop box” powered by iCloud.

As many were quick to point out, syncing files between Macs is nice, but “real” syncing solutions like Dropbox come with mobile apps to make sure your documents and folders aren’t simply synced between desktop machines. Since Apple isn’t offering a new version of iDisk based on iCloud — and seems to be moving away from the concept of filesystem altogether — the method I described in the article was obviously meant for owners of multiple Macs — the Mobile Documents “hack” is cool, but it’s not supported by Apple.

On the App Store, however, that are several apps that over the years have tried to re-implement the filesystem on iOS by offering access to a plethora of online sources for your files, such as FTP servers, Google Docs, Dropbox and SugarSync. These “file management” apps like iFiles and iStorage aren’t integrated on a system level, but they work as “aggregators” for documents you may have already saved in the cloud, only they bring them together in a single location.

One of such apps is GoodReader, perhaps the most popular document reader & file manager ever landed on the App Store’s virtual shelves — GoodReader comes with hundreds of features and support for multiple online services, plus it’s also a decent PDF reader with annotation functionalities and an overall good preview engine. As I was playing around with the idea of having Mobile Documents work with an iOS app, I realized one of the latest GoodReader updates introduced full iOS 5 and iCloud compatibility, meaning the app can store its documents and data in iCloud, and will show up as iCloud-enabled app in your account (to check this, open Settings->iCloud->Storage & Backup->Manage Storage on iOS, or System Preferences->iCloud->Manage… on OS X Lion). And if an iCloud-enabled app with Documents & Data shows its contents on OS X under Mobile Documents, it means GoodReader should be capable of syncing its own filesystem back to the Mac.

Indeed, you can use GoodReader to manage files and folders on iOS, and have them available on the Mac as well through iCloud and Mobile Documents. GoodReader will create its own folder inside Mobile Documents, and every change (new file, new folder) you’ll make on the iOS app will appear inside GoodReader’s “Documents” directory. Of course, you’ll have to use GoodReader’s “iCloud” folder to enjoy these syncing features; thanks to GoodReader’s file management features, you’ll be able to create folders and sub-folders, move documents around and delete them, create new text files, rename documents, and more. GoodReader has some pretty powerful features, and it’s nice to see the developers are supporting iCloud out of the box with a dedicated folder on the main “My Documents” page.

Thanks to GoodReader’s support for multiple online services, you’ll be able to, say, move files from Dropbox or Google Docs to iCloud directly from the iOS app.

In my tests, iCloud sync with GoodReader has been extremely fast and reliable. Documents imported on iOS would show up in seconds on the Mac’s Mobile Documents, and vice versa. I was able to move screenshots between my Mac, iPhone and iPad using Mobile Documents and GoodReader, but I also created folders, compressed files, imported PDFs and MP3 files. Because iCloud is based on push technology, files are pushed immediately to the cloud and downloaded on all configured clients, but I noticed that GoodReader for iOS, unlike the Mac’s Mobile Documents folder, doesn’t download a full document as soon as the data is “pushed” from iCloud. Try this: on your Mac, drag a medium-sized PDF into GoodReader’s iCloud folder. Notice how the PDF’s icon and name show up on GoodReader after your Mac has pushed the document to iCloud. But try to open the PDF from GoodReader, and you’ll see the app will require additional download time, as only the main information about the file has been pushed to iOS — if you want to read it, you’ll have to wait for the full download. I actually found this method pretty clever, as it gives me up-to-date file information in seconds, and allows me to download files when I need them. Overall, I’m impressed by iCloud and GoodReader working together to sync files across different iCloud clients.

Why should you care to have GoodReader syncing files that also happen to show up on your Mac? First off, it’s a cool trick. More importantly, iCloud’s push technology works well, and users (like me) may find it convenient to have an easy way to, say, import iOS screenshots on the desktop without using Photo Stream, while still relying on iCloud. Thanks to GoodReader’s support for audio and video, iWork and Office files, HTML archives and text files, you’ll be able to copy a variety of documents from your desktop onto iCloud, and have them synced back to iOS in seconds.

Check out how to sync files with Mobile Documents and iCloud here. GoodReader is available on the App Store for iPhone and iPad.

Hidden into Lion’s ~/Library (which can be displayed in a variety of ways as we detailed in our Lion review) there’s a Mobile Documents folder that’s capable of syncing files across Macs configured with iCloud, Mac OS X Hints reports. Sure enough, the Mobile Documents folder is the directory iCloud uses for Documents & Data, a feature available both on iOS 5 and Lion. Mobile Documents is the same folder that contains data for apps that already work with iCloud, such as Instacast, iWork, or Galaxy on Fire 2.

What’s interesting about this folder when used with two Macs under the same iCloud account is that it provides a basic “drop box” functionality for files that don’t necessarily belong to an iCloud-enabled app. As you can see in my screenshot, the Mobile Documents folder contains data and sub-folders for App Store apps that work with iCloud. In order to follow Mac OS X Hints’ suggestion, I tried to drop a few images directly in the folder — as I’d normally do with Dropbox — using my iMac. In a few seconds, those files were synced back to my MacBook Air. Both my iMac and MacBook Air use the same iCloud account, and have Documents & Data on. Clearly, those images didn’t belong to an officially-registered iCloud app (such as Instacast), but the files were synced back and forth between the two machines.

So what we have here is a cool hack to use the Mobile Documents folder as a temporary Dropbox-like solution based on iCloud. This is interesting because Apple could technically prevent files that don’t belong to a signed iCloud app from syncing across Macs, but decided not to, at least on 10.7.2. If you think about it, this could imply the company will offer some sort of iDisk replacement sometime in the future, or build a GUI for syncing documents back and forth between Macs manually. Or, it could be the foundation for an upcoming iWork for OS X update. Or then again, it could simply be a cool trick that won’t receive any official support from Apple.

If you want to try the Mobile Documents sync (Mac OS X Hints claims the system even supports conflict resolution, which was suggested by John Gruber months ago), I’d recommend you make an alias of the folder, drop it onto your Desktop, and start dropping files into it. Make sure all your Macs are configured with a single iCloud account, and do not delete the documents & data that are already in there, or you’ll lose precious app libraries, preferences, or saved states.

Finally, please note that even if files you’ll sync won’t show up in “official” iCloud apps, they’ll still count against your iCloud storage.

Update: here’s how you can use Mobile Documents with GoodReader for iOS.

Ted Landau at The Mac Observer covers an issue I’ve mentioned several times in the past, which Apple has partially fixed with the last releases of iOS: saving documents and moving them across apps. Specifically, Landau notes that the lack of a “universal save” option for documents that can be read by third-party apps (PDFs, text files, images) leads to an annoying and pretty much useless duplication of content. Apple has implemented an “Open In…” menu to send files to other apps, but the file that’s being sent is a copy. iOS apps can’t read and modify a source file from a single location.

Currently, iOS does not come close to matching the advantages of Mac OS X here. There is no way to have a unifying folder in iOS that contains related documents from different apps. There is no way to have a document easily opened in different apps, where any changes you make in one app are instantly accessible by all the compatible apps. You can come closer with Dropbox, but closer is not good enough here.

That’s annoying for me, too, as I constantly switch between apps to get my work done, and it’s not like I don’t enjoy trying new ones. This typically leads to some sort of geek frustration — why can’t Apple build an invisible layer that lets Elements edit a text document from Evernote and Pages access the same file?

For Ted and me, yes, being able to avoid file duplication and tedious exporting processes would be nice. But I do wonder how much does Apple care about such functionalities considering the underlying paradigms of iOS and the upcoming iCloud functionalities of iOS 5. For one, Apple really cares about application sandboxing: each app has its own controlled data environment and only a few items can be shared between multiple apps. Apple cares about sandboxing so much that they’re bringing it to the Mac App Store. Would iOS sandboxing allow for a source file to be edited and “saved” by multiple apps? Where does that file belong to, technically? Would iOS apps be able to write specific metadata to it? And what happens if, hypothetically, this “shared” file needs to be pushed back and forth with iCloud?

I’m no iOS developer, but I can see this proposed “universal save” model becoming an issue when on iOS, unlike the Mac, there’s no visible, centralized Finder location to write and read files from. In fact, Ted is right when he says that the convenience of a Mac is being able to create “a folder that will contain all the assorted files needed to put his column together”. That’s made easy by the Finder — but on iOS? Apple allows third-party developers to plug into the Music library or Camera Roll, yet there’s no Apple app to “create text file here” or “save webpage from Safari here”. Again, the lack of an iOS Finder would require “universal save” to work inside any app. iDisk could have been a centralized location for files — it could have even been Apple’s “answer to Dropbox” — but it’s not going to be supported by iCloud.

And then there’s the conceptual issue of an iOS device being the app that you’re using. When you use Pages on an iPad, the iPad is a word processor. When you browse the web with Safari, you’re holding the web in your hands. On a technical level, this app console model is represented by sandboxing and one-way “Open In” menus, and soon iCloud-based documents that allow multiple versions of the same app to access files. Would a “universal save” option somehow break the illusion that you’re holding an app, reminding us that we’re using a device with multiple layers of abstractions including a filesystem?

I don’t know. I believe I’d like this feature in theory, but I wonder if there would also be a considerable trade-off to accept.

LogMeIn, the powerful remote desktop sharing tool that offers a variety of other services for professionals and businesses, released a series of updates in the past week to enhance support for file management in Ignition, the iOS app we’ve reviewed here on MacStories, and bring full OS X Lion support to LogMeIn Free, Pro and Ignition desktop users. With a blog post this morning,  the company has announced a compatibility update that resolves the issues when trying to connect to a machine running Lion, rumored to be publicly released next week. I have tested the update (which can be installed by opening LogMeIn’s preferences, then About->Check for Updates) on my two Macs running OS X Lion GM and I successfully managed to log in (both via screen sharing and file manager) from my iPad, iPhone, and the web. (more…)