Programming the iPhone User Experience

App As OS

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 ...