Why Apple should open up the iOS sandbox

In the world of smartphone punditry, the idea of sandboxing—restricting software to dealing only with the files or capabilities it absolute needs to—tends to be a polarizing concept. On the one hand, power users chafe at the way it limits their ability to use their computers and mobile devices the way they want; on the other, it’s hard to argue against the success that Apple has had with the philosophy—particularly in the mobile market, in which the company has created a computing platform that is both secure and popular.

Yet sandboxing is also starting to show its age. While the capabilities of iOS devices are rapidly approaching the territory of their desktop counterparts, the ability of iOS apps to communicate with each other is stuck in the 2007 era. It’s time for a change.

Sandcastles and security

Sandboxing is most often touted as a technology whose primary job is security and control. By enforcing a very strict set of rules on which apps can be installed on a device and exactly what they can do, Apple claims—rightly so, for the most part—that it can provide its users with a safe computing environment in which they can operate without having to worry about their data and personal information being stolen.

At a deeper level, however, sandboxing has also helped the company deliver on its promise of an innovative mobile experience that can rival the performance delivered by desktop computers.

The first few generations of iPhones and iPads were, essentially, big screens strapped to big batteries. As such, they suffered from severe limitations in both performance and power that, left unchecked, would have severely hampered the kind of interaction that Apple wanted its users to enjoy: It’s hard to provide consistently smooth scrolling or all-day battery life when the user could be running dozens of apps in the background, each of which is parasitically consuming CPU cycles and power.

With sandboxing in place, Apple was able to establish and enforce a set of compromises through which it could ensure that every user, no matter how experienced or daring, would always enjoy the power that the company promised.

Fools of us all

Times, however, change, and today’s average mobile device is much less constrained by hardware than its ancestors. Apple’s own marketing materials, which typically eschew technical talk, now say that iPhones and iPads pack “desktop class” hardware beneath their screens.

Sandboxing, unfortunately, has failed to keep up with these changes. Sure, some of the early restrictions have been lifted: Third-party software can now run in the background under some circumstances, for example, and apps can exchange files either directly, if prompted by the user, or through a system clipboard.

But the ability of apps to communicate directly with each other is still limited to the idea of custom URLs. This system lets one app send data to another by asking the OS to “open” a specially-crafted address—similar to the ones we use to access a website—that’s registered by the second app when it’s installed. But while a lot can be done with these custom URL schemes, they still only scratch the surface of what’s possible. 

This limitation on inter-app communication is all the more galling when you consider both iOS’s own heritage and its marketplace.

One big pipe

In the UNIX world of terminals and command lines, users have long enjoyed the power of “piping,” a technique that makes it possible to chain multiple commands together in a variety of ways. By piping the output of one command into the input of the next, the savvy user can build surprisingly complex apps simply by gluing together a set of building blocks.

A corollary of this setup is that individual apps in this world tend to take on a razor-like focus on a particular task, providing a very high degree of specialization that would otherwise be hard to build into large, monolithic software. Unsurprisingly, it’s easier to build a really good app whose only job is sorting data than to make it an additional bullet point in a software package that also has to offer a myriad of other functions.

Unexpectedly, perhaps, the UNIX way of software development also tends to standardize software and allow for more user customization at the same time. If you don’t like the way a particular app works, chances are that you’ll find a different one that can be used as a drop-in replacement for it in your piped expressions with only minimal changes to your workflow.

Small is beautiful

In the world of GUIs and touch interfaces, terminals and pipes may seem like the kind of esoteric technology that would only interest serious computer experts, but their underlying concepts apply quite well to today’s iOS market, where the downward pressure applied to software pricing tends to favor small apps that focus on a specific task.

If you set aside for a moment the idea that piping has traditionally been tied to a command-line interface, the idea of creating workflows that involve a chain of data from one app to another has a number of advantages for both users and developers.

More powerful devices and a cutthroat marketplace translate into customers who expect their software to be more productive even while they continue to pay bargain-basement prices for it. Unfortunately, developers are forever required to build programs that are almost completely self-sufficient, which means having to deal with a lot more code than simply that which makes their particular app unique.

Focus where it belongs

Take, for example, camera apps; it’s a category so crowded that a dollar is pretty much the high end of what developers can hope to charge for the fruits of their toils.

The problem is that even if a particular app has some unique hook, like, say, being able to capture numerous pictures in rapid sequence, or taking panoramic pictures, it still needs to provide all the other functionality that users have come to expect from apps of its ilk—filtering, cropping and editing, red-eye reduction, and so forth.

While iOS itself may provide some of these features, the developers have little choice but to either invest their time on code that isn’t really central to the app they’ve built, or ignore the issue altogether and hope that users will somehow manage to figure out a way to build their own manual workflow that approximates the same level of functionality.

The end result is something that benefits no one: Developers waste time on features that others have already implemented, and users end up with sub-par apps that all implement the same functionality, but with inconsistent user interfaces and varying degrees of quality. Not to mention workflows that create multiple inconsistent copies of the same documents as they’re shuffled around from app to app.

On the other hand, if apps were able to communicate with each other, the photo app in our example could focus on providing the best panoramic stitching experience, and delegate the remaining functionality to other apps, which could manipulate the original file through their own interface and then return it to the original app, giving users the best of both worlds.

From A to B to C

The presence of some kind of inter-app communication mechanism would also allow users to tie together the services offered by multiple apps into cohesive sets of steps that can be executed without user intervention, perhaps via apps that, like Automator on OS X, facilitate the creation of complex workflows with little or no technical knowledge.

I am not necessarily suggesting that Apple should bring Automator to iOS, but, if you consider how useful an app like Launch Center Pro can be—even with all the limitations currently imposed on it by iOS’s sandboxing model—it’s not hard to imagine what better inter-app communication could mean for everyone, regardless of how savvy they are in the ways of computing. Users could create complex workflows for everything from sending e-mails to setting reminders, using the kind of simple interface that we’ve come to expect from our mobile devices.