Since the introduction of the Mac, Apple has waged a steadily escalating war against the file system. While the ability to organize files hierarchically has been a mainstay of operating systems for as long as there have been operating systems, the fine folks from Cupertino have constantly pushed away from that approach with each iteration of Apple’s products, starting with the introduction of Packages and culminating, arguably, with iOS’s complete lack of a user-facing interface for manipulating the file system.
That’s not to say that the file system itself has disappeared from your iPhone or iPad: Underneath iOS’s glossy user interface and cloud-based document storage, files and directories continue to provide the basic structure in which data is organized.
Apple’s decision to move from a file-centric user experience to one that revolves strictly around the concept of a document shifts the responsibility for organizing files from the users to their apps. And a key side effect of Apple’s new approach is that it confines each app to working within a restricted sandbox where it has complete control over its files.
Good-bye files, hello documents
Reaction to iOS’s lack of a user-accessible file system is mixed. iOS implements a highly compartmentalized environment in which each app lives in its own sandbox, and the document-centric approach works reasonably well—helped in no small part by the fact that Apple was able to tailor the user experience to this model in detail: Since iOS was built from scratch for a brand-new class of devices, its developers didn’t have to worry about supporting the paradigms of a legacy operating system.
From a technical point of view, there are a number of advantages that come with this approach. The first is that each app is directly responsible for managing its own content; this gives developers a high degree of control over things like, for example, deciding which data should be cached, backed up, and synchronized to iCloud, minimizing the app’s storage footprint.
Along the same lines, confining an app to its own sandbox limits the impact that it has on the overall file system. In a traditional environment, software tends to leave all sorts of “digital droppings” in various directories on a hard drive, and data like preferences, shared frameworks, and the like have a bad habit of lingering long after the user has attempted to remove the app from their computer. With everything neatly jailed in its own container in iOS, getting rid of an app and its detritus is a much simpler affair.
Sandboxing is for computers, not humans
The flip side of these technical advantages is that they sometimes ignore the actual needs of the average user. For example, sandboxing often leads to duplication on iOS: Since an app can access only files that belong in its allotted disk space, the only real way for two pieces of software to share data is to use the infamous “send to” functionality, which creates a copy of the document to hand off from one app to the other.
As many have noted, this approach makes it very difficult to create complex workflows, and tends to cause the same document to appear in multiple places—and in varying states of completion.
Now, this is not necessarily a bad thing; an interesting side effect of associating the ownership of a document with a specific app is that the latter takes full responsibility for managing it. On a desktop operating system, we have learned to subconsciously think of documents in terms of the kind of data they contain, and demand that apps be able to interoperate with file types that they do not directly own.
If you have ever tried to, say, open a Word document in Pages, only to find out that half your formatting was lost in the conversion, you know exactly what I mean. It would be impossible for Apple to be privy to every last nuance of a file format that Microsoft owns entirely, or for Microsoft to have to worry about the mistakes that a third party could make while attempting to read data that has been saved according to its proprietary scheme.
Despite its flaws, iOS’s send-to functionality forces developers to come to grips with the fact that they are not merely “saving” a document, but passing it to another app. That in turn gives developers an opportunity to choose a neutral format that doesn’t force the receiving app to make guesses about what the data means—and, in the process, enables the developers to explain to the user what, if any, features will be lost in the process.
Still, unless your needs are very simple, iOS’s balkanized approach to document storage ends up causing the very same problems that it attempts to solve.
Thinking like people
This problem boils down to a simple issue: While the sandboxing model makes sense from a technical perspective and introduces a large number of advantages, it doesn’t reflect the way people work.
If I think about the way I work, it’s obvious that my activities revolve around the concept of projects. A project could be something as simple as this article, which consists of some text and a few images, or (at least in OS X) something as complex as an Xcode program, which may involve data generated by half a dozen apps.
Either way, it’s a rare project that involves the use of a single app, particularly given that so many apps are becoming more and more specialized. At the same time, almost nothing that I do directly requires a file system. On a large project, I may use folders to compartmentalize data—say, to put all images in one place—but I do so only for convenience reasons, and would much rather leave that task to the operating system.
For this reason, it seems to me that a project-based model like this would work well if it became part of iOS itself. The operating system could allow users to create “workspaces” in which multiple apps can then store their respective data. Internally, the workspace would still be sandboxed so that each app retains exclusive access to its files, but it would also contain a “common” area from which apps are free to read each other’s information.
For example, an app like Photoshop could use its sandboxed area of a workspace to store a proprietary PSD file that contains the editable version of an image, with its filters, layers, and other Adobe-specific functionality intact and safe from outside interference. At the same time, the app could store a read-only version of the image in a commonly understood format like JPEG or PNG in the common area of the workspace, thus making it easy for other apps to use it without compromising the integrity of the original. If the user then added, for example, a Pages document to the workspace, the image would be readily available, and would update automatically every time the original was modified.
A Finder for the ages
This approach keeps the data together in one place, making it easy to divide it up in a way that makes sense to a human being, rather than a computer. And, although it relies on a traditional file system internally, it doesn’t expose any of its complexity to the end user, satisfying Apple’s mission of simplicity and usability.
To make things even neater, the workspaces themselves could be managed by a specialized app provided by Apple itself, whose only job is to “own” the workspaces and help the user organize them and sync them to iCloud—a Finder for the post-PC era that deals with a higher level of data than just today’s files and directories.
This would make it easier to transplant this approach to OS X, where the limitations of today’s sandbox are even more evident, and where 30 years of legacy based on unfettered access to the file system cannot simply be swept under the carpet.
Of course, I have no way of knowing if this is the direction in which Apple is headed (although I certainly hope so). But I’m fairly sure that today’s sandboxing is merely a stepping stone to something better, if for no other reason than the current approach forces users to deal with some significant limitations.
