Apple requires that applications not compete with the suite of applications that make up the
default user experience. Applications are often rejected for duplicating
functionality already supplied by Apple. This means that the market will
likely never see real competition for the iPod application, Mail, or
Safari, among others.There are many ways of looking at this policy. One non-cynical view
is that competing applications hurt the overall user experience. Instead
of building a competitor to Safari, for example, developers can provide
links that will open Safari, letting the most capable application handle
the task at hand. As another example, you can enable users to send an
email by making calls to load a URL with the mailto:// URL scheme, which is
intercepted by the Mail application. With the right arguments in the URL,
the Mail application will instantly craft a message with a subject, a
recipient address, and even a message body.
NOTE
iPhone OS 3.0 lets developers go a step further than a
mailto:// link and incorporate a standard screen for
composing and sending email messages. Apple seems to be selectively
moving functionality from applications to frameworks, giving developers
both options for performing common tasks while ensuring a consistent
user experience for those tasks.
Despite Apple’s policies, some applications with system-provided
functionality make it into the store. It seems that Apple approves a few
uses of duplication—all of them limited and minimal. The most common
features that sneak past the censors are bundled browser functionality
using WebKit and built-in SMTP support for sending
emails directly from an application designed for iPhone OS prior to
version 3.0.
The problem with the limited subsets is that users grow accustomed
to certain tools, options, and features. When viewing a web page, for
example, it’s very common to use the full Safari feature set. Users pinch
to scale, double-tap DOM elements to zoom in and out, hold links to see
the target URL in a callout bubble, rotate the device for easier reading,
bookmark pages, and email links to people. Most applications that present
a WebView to load pages offer very few of these
operations. The controls also differ with each implementation, leading to
confusion and a learning curve for a function that users see as primary to
the iPhone: browsing the Web. It’s certainly ironic that Apple allows
unpleasant implementations of duplicate features—especially given the
justification that it’s all in service to a better user experience.
Figure 1 shows the Shovel application, a client for Digg. The developers
present users with the option to open the given news story in Safari,
which is an excellent use of cooperative design.
Interestingly, if a user taps the headline of the story instead of
using the action icon, Shovel opens the web page in an internal
WebKit browser. As with other built-in browsers, the
more compelling and user-friendly features of Safari are omitted. Figure 2 shows internal browsers used in Shovel,
LinkedIn, and TED.
Internal browsers can be useful, but they can cause confusion and
frustration if familiar features are missing. If you include a browser
screen in your application, you should provide at least the most essential
functionality: next and back buttons, a reload button, and an option to
open the current page in Safari. Give your users control over the use of
limited embedded browsers through application settings.
Perhaps if Apple allowed developers to create robust alternatives to
Apple applications like mobile Safari, the pattern would prove useful
instead of being a frustrating anti-pattern. For now, however, the best
practice is to implement cooperative functionality that lets users
accomplish tasks using the tools they already know, and to focus custom
development efforts on innovative problem solving, gaming, or media
display.
