TightWind is written by Kyle Baxter. Stay Hungry. Stay Foolish.

Something I’ve been thinking a lot about lately is where iOS is going. Apple just released the sixth version of iOS, and after more than five years, iOS is significantly more powerful than when the iPhone shipped in 2007. Then, the iPhone had no GPS (or a location-finding feature at all), no copy-and-paste, no voice control, no push notifications, no third-party applications, no multitasking (except for certain applications like iPod and Safari), and just a short list of ringtones—and that was it. It’s come a long way.

iOS 6 was not a significant update for new end-user features. It brought a new Maps application, updated Siri with new capabilities, and added Passbook—significant updates, but not nearly on the scale of past updates. It’s easy to read this as a sign that iOS has matured, and Apple is simply polishing it as-is without changing much. I think that’s dead wrong.

I think that’s wrong for, among others, two reasons: remote view controllers and Siri. Both of these could make iOS a much more powerful operating system than we are used to. Let me explain why these are so significant.

Breaking Down the Sandbox

In iOS, the application model is quite simple: applications play in their own sandbox, and they can’t play in another application’s sandbox. This design is more secure because applications can’t damage other data on the device, but it is also very limiting. Applications have little ability to work together as a result.1

Earlier this month, though, Ole Begemann noticed something interesting in iOS 6: the Mail compose view, which pops up whenever users want to email something from another application, runs in a separate process from the open application. That sounds rather boring, but it’s actually very important. Here’s why.

Effectively, you can think of the Mail compose view as a mini “application” that, when the user wants to email something from an application they are using (let’s say from Basil), slides in on screen and allows them to do so. As a result, I didn’t have to write anything at all related to email for Basil, and yet my customers can email things from Basil to their heart’s content. Now imagine if I, and any other developer, could write mini applications that add functionality to other applications.

For example, Basil could declare that it handles web URLs. Then, I could build the recipe saving feature of Basil as a mini application (stored in Basil) that users can use from any other application that deals with the web. If someone who uses Basil is browsing recipe websites in Safari, they could tap a “Basil” icon in the action sheet, and my mini application would pop up, save the recipe to Basil and get out of the way—all without the user ever leaving Safari. The same could be true for Reeder (save recipes from cooking websites you subscribe to while browsing your feeds), Twitter applications, or anything else—and those developers wouldn’t have to know that Basil even exists. If their application declares that it works with web URLs and Basil declares it can handle them, users will get the functionality without any special work between me and the other developer.

As a result, applications could work together. This would make iOS a much more powerful system. But it could be even better.

Siri

Imagine if developers could not only build mini applications for use with other applications, but services without a user interface. So, for example, Tapity’s Languages application could write a service for translating words, and declare that it handles language (or some other generalized language-related function). Applications that deal heavily with text would then be able to translate into several different languages.

That’d be great. But now imagine that not only could these services be written for other applications, but could also be written for Siri using a Siri API.2 Using Languages’ theoretical service, users with the application installed on their iPhone could translate words by asking Siri, “What is ‘milk’ in Italian?”3 Or if you have a flight tracking application installed, you could ask Siri when a flight will arrive. Or if you have a news application, Siri could tell you what’s happening right now.

Those are just a few mundane examples, but the important part here is this: it would allow developers to extend Siri’s capabilities. If Apple builds a Siri API similar to this, Siri could become infinitely useful. It would truly be a new interface for all of iOS, and an interface for doing almost anything.

I want to note that while it does appear likely that Apple is building remote view controllers, my second idea—remote services along with a Siri API—is entirely speculation. I have no idea if that’s what Apple is planning. What I want to show, though, is that iOS is far from maturity. Whatever Apple decides on, we could see dramatic changes to iOS as we know it in the next few years.

1. It’s worth noting that in iOS 3.2, applications could declare that they can open certain file types. By doing so, users can “send” files from one application to another. For example, if you are emailed a PDF and tap on it, you are presented with the option to open the PDF in Goodreader (if you have it installed), because it declares itself for that file type. This feature made the sandbox model less limiting because users can now move files between applications, but that’s all it does—move them between applications. Applications still have little ability to work together. [↩]
2. This, of course, isn’t exactly trivial; the API would have to identify what the user is requesting, what functionality category it falls under, and then provide any applications which declare they can handle it with the user’s request. This alone is a very difficult problem to solve, and one I might come back to in another article. [↩]
3. This example may be difficult simply because while the service may be able to translate the word correctly, Siri may not be able to speak it in the new language correctly. But it could, of course, just show the answer on screen. [↩]