We're accustomed to feature-packed desktop apps—mutant word processors that are also page-layout programs, image editors, and creators of zany "word art." The history of consumer computing is, by and large, a story of ever more complex applications sprouting longer and longer feature lists. Mobile apps present a hard turn in that trend. They work with limited hardware resources, limited screen space, and perhaps most important, limited user attention. As you've seen since the first pages of this book, tapworthy apps necessarily develop an expert focus on a narrow slice of user wants and needs. In place of the all-in-one apps you find on the desktop, iPhones are packed with special-purpose apps that people juggle in various combinations to get stuff done. Friends, it takes a village.
A very smart man named David Weinberger describes the World Wide Web as a set of "small pieces loosely joined," a democratic collection of independent documents strung together by links. The same is true on the iPhone, where we have small apps loosely joined. Like web pages, it turns out that apps can also link to each other, passing tiny morsels of information along the way in the same way that web links can include Google search terms or an Amazon product id.
In fact, behind the scenes, apps use special URLs to pass control to other apps, and they happen to look very similar to familiar web URLs. To launch the Phone app and call a number, for example, a programmer tells the iPhone to "go" to a URL like tel://1-800-555-1212. The current app quits, the Phone app fires up, and the number gets dialed. iPhone users see this all the time: apps launch web pages in Safari, zoom to a specific location in Maps, or fire up a pre-addressed SMS message. In all of these cases, there are URLs at work under the hood telling the iPhone, "Launch this app and give it this message," where the message is a web link, a street address, or a phone number. It's a limited system, though, and you can't send along lots of info, just a snippet of text. But it's simple and effective, letting you pass control to another app so that people can take advantage of that app's special talents. (URLs can't pass whole documents back and forth, but starting in iPhone OS 4.0, apps have another way to do that. This is done through the built-in document preview system—the document interaction controller—used by apps like Mail to let you read received documents. When previewing a document, apps can offer an "Open In..." option to let people open it in another app.)
Be generous. Linking to other apps makes it easy for your audience to take full advantage of your own app by spinning off its data for in-depth exploration elsewhere. Let your app focus on what it does best and make referrals to other apps for the rest. If another app can do something better, or if it handles a task that complements your app, pass the baton. Teaming up is good for everyone.
You're not limited to linking only to Apple's built-in apps, either. Any app can accept links (including yours). To do it, all a developer has to do behind the scenes is claim a URL protocol for an app. Here's a quick overview: a URL protocol is the http portion of a web address, for example. When an app requests a URL using that protocol, the iPhone automatically launches the associated app and passes along the URL info. Twitterrific, for example, registered the protocol twitterrific, so that any app can launch Twitterrific and start a new tweet by requesting a URL like this: twitterrific:///post?message=Hello. (For nitty-gritty details on how custom URL schemes work, developers can check out the iPhone Application Programming Guide at http://developer.apple.com/iphone.)
Neat, right? Here's the thing: other app developers have to know about the app and its link format in order to use it. So, speaking of being neighborly, that means you've got to pick up the phone or dash off an email and actually get to know the people who make other apps. Explain how linking to your app can help their own audience and how to do it. Your to-do list app, for example, could accept links that create new tasks, letting other apps specify the task title and due date. Twitter apps, in particular, have been especially industrious about getting the word out about their custom links: lots of apps let you choose a preferred Twitter app and, when you want to tweet a message, send you over with a snippet of suggested text to edit in the comfort of your favorite app.
Figure 11-5. The Cocktails+ app links to the Twitter app of your choice to announce your potent potable. After choosing your preferred Twitter app (left), you can tap "Share via Twitter" from a recipe page, and the app launches the other app (Twitterrific, right) with some suggested tweet text.
All this linking is great for your audience, unless it takes them by surprise. It's irritating to be dumped out of one app and launched into another when you're not expecting it. A particularly common sin is offering a seemingly innocuous help button that bumps you unannounced to a web page in Safari. (In that case, at the very least, apps should throw up an alert to warn that you're about to leave the app and ask if you really want to do it.) As always, the context sets expectations. Passing control to another app is ideal when an app's primary task is complete and the user is ready to tackle a follow-up task in another app without looking back. Linking out works best as an endpoint.
On the other hand, frequent tasks that always happen in the middle of your app's typical workflow are lousy candidates for linking to other apps. Frequent switching with another app during the same session almost certainly highlights a feature that you should build into the app itself. If you don't, you'll slowly melt people's brains as they tediously and repeatedly switch back and forth between apps to get this one thing done. Staying inside your app's fences is sometimes the best option, and that's the topic of the next section.