Handling Common Tasks
iPhone applications handle many common tasks in ways that may seem different to you, if your experience is with desktop or laptop computer applications. This section describes these tasks from the human interface perspective; for the technical details you need to implement these guidelines in code, see iOS Application Programming Guide.
Starting
iPhone applications should start instantly so users can begin using them without delay. When starting, iPhone applications should:
Specify the appropriate status bar style. For information about the available styles, see “The Status Bar”; to learn how to specify the style in your code, see “The Information Property List” in iOS Application Programming Guide.
Display a launch image that closely resembles the first screen of the application. This decreases the perceived launch time of your application. To learn how to create a launch image, see “Launch Images”; to learn how to specify a launch image in your code, see “Application Launch Images” in iOS Application Programming Guide.
Avoid displaying an About window, a splash screen, or providing any other type of startup experience that prevents people from using your application immediately.
By default, launch in portrait orientation. If you intend your application to be used only in landscape orientation, launch in landscape regardless of the current device orientation. Allow users to rotate the device to landscape orientation if necessary.
A landscape-only application should support both landscape orientations—that is, with the Home button on the right or on the left. If the device is already physically in a landscape orientation, a landscape-only application should launch in that orientation. Otherwise, a landscape-only application should launch in the orientation with the Home button on the right by default.
Restore state from the last time your application ran. People should not have to remember the steps they took to reach their previous location in your application.
Important: Don’t tell users to reboot or restart their devices after installing your application. If your application has memory-usage or other issues that make it difficult to run unless the system has just booted, you need to address those issues. For example, see “Using Memory Efficiently” in iOS Application Programming Guide for some guidance on developing a well-tuned application.
Stopping
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It provides feedback that reassures users that there’s nothing wrong with your application
It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can:
Describe the situation very succinctly
Supply a button that performs a corrective action
Display the alert only when users try to access the feature that isn’t functioning
As with all alerts, the less users see them, the more effective they are. For more information about creating alerts, see “Using Alerts.”
Accommodating Multitasking
Thriving in a multitasking environment hinges on achieving a harmonious coexistence with other applications on the device. At a high level, this means that all applications should:
Handle interruptions or audio from other applications gracefully
Stop and restart (that is, transition to and from the background) quickly and smoothly
Behave responsibly when not in the foreground
The following specific guidelines help your application succeed in the multitasking environment introduced in iOS 4.0:
Be prepared for interruptions, and be ready to resume. Multitasking increases the probability that a background application will interrupt your application. Other features, such as the presence of ads and faster application-switching, can also cause more frequent interruptions. The more quickly and precisely you can save the current state of your application, the faster people can relaunch it and continue from where they left off.
Make sure your UI can handle the double-high status bar. The double-high status bar appears during events such as in-progress phone calls, audio recording, and tethering. In unprepared applications the extra height of this bar can cause layout problems. For example, the UI can become pushed down or covered. In a multitasking environment, it’s especially important to be able to handle the double-high status bar properly because there are likely to be more applications that can cause it to appear. You can trigger the double-high status bar during testing to help you find and correct any views that don’t handle it well. (To learn how to do this using the Simulator, see “Manipulating the Hardware” in iOS Development Guide.)
Be ready to pause activities that require people’s attention or active participation. For example, if your application is a game or a media-viewing application, make sure your users don’t miss any content or events when they switch away from your application. When people switch back to a game or media viewer, they want to continue the experience as if they’d never left it.
Ensure that your audio behaves appropriately. Multitasking makes it more likely that other media activity is occurring while your application is running. It also makes it more likely that your audio will have to pause and resume to handle interruptions. For specific guidelines that help you make sure your audio meets people’s expectations and coexists properly with other audio on the device, see “Using Sound.”
Use local notifications sparingly. An application can arrange for local notifications to be sent at specific times, whether the application is suspended, running in the background, or not running at all. For the best user experience, avoid pestering people with too many notifications, and follow the guidelines for creating notification content, described in “Enabling Local and Push Notifications.”
When appropriate, finish user-initiated tasks in the background. When people initiate a task, they usually expect it to finish even if they switch away from your application. If your application is in the middle of performing a user-initiated task that does not require additional user interaction, you should complete it in the background before suspending.
Hosting Ads
In iOS 4.0 and later, you can allow advertisements to display within your application and you can receive revenue when users see or interact with them. It’s essential that you plan when and how to integrate ads with your UI so that people are motivated to view them without being distracted from your application.
You can host an iAd, which contains the ad content, in a specific view in your UI. When people tap an ad in this view (called a banner view), the iAd performs a preprogrammed action, such as playing a movie, displaying interactive ad content, or launching Safari to open a webpage. The action can display content that covers your UI or it might cause your application to transition to the background.
The dimensions of the banner view are:
In portrait, 320 x 50 points
In landscape, 480 x 32 points
To ensure seamless integration with banner ads and to provide the best user experience, follow these guidelines:
Place the banner view at or near the bottom of the screen. This placement differs slightly, depending on the bars that can be in the screen:
If there are no bars at the bottom of the screen, put the banner view at the bottom edge of the screen.
If there are no bars at all, put the banner view at the bottom edge of the screen.
If there is a toolbar or tab bar, put the banner view directly above the toolbar or tab bar.
Ensure that banner views appear when it makes sense in your application. Although it’s recommended that a banner view be at the bottom of a screen, you choose which screens should contain banner views. For example, you might want to choose a context that functions as a sort of interlude in the main task of your application. People are more likely to enter an iAd experience when they don’t feel like they’re interrupting their workflow to do so. This is especially important for immersive applications such as games: You don’t want to place banner views where they will conflict with gameplay.
As much as possible, display banner ads in both orientations. It’s best when users don’t have to change the orientation of the device to switch between using your application and viewing an ad. Also, supporting both orientations allows you to accept a wider range of advertisements. To learn how to make sure a banner view responds to orientation changes, see iAd Programming Guide.
While people view or interact with ads, pause application activities that require their attention or interaction. When people choose to view an ad, they don’t want to feel that they’re missing events in your application, and they don’t want your application to interrupt them. A good rule of thumb is to pause the same activities you would pause when your application transitions to the background.
Don’t stop an ad, except in rare circumstances. In general, your application continues running and receiving events while users view and interact with ads, so it’s possible that an event will occur that urgently requires their immediate attention. However, there are very few scenarios that warrant the dismissal of an in-progress ad. One possibility is with an application that provides Voice over Internet Protocol (VoIP) service. In such an application, it probably makes sense to cancel a running ad when an incoming call arrives.
Note: Canceling an ad might adversely impact the kinds of advertisements your application can receive and the revenue you can collect.
Managing Settings or Configuration Options
iPhone applications can offer settings that define preferred application behaviors or configuration options users can specify to change some functionality of the application. Settings should represent information, such as an account name, that users set once and rarely (if ever) change. Users view application-specific settings in the built-in Settings application. Configuration options are values that users might want to change frequently, such as category types displayed in a list; configuration options should be available within the application itself.
You should consider settings and options to be mutually exclusive. That is, you should not offer both settings and configuration options in your application.
It’s best when iPhone applications do not ask users to specify any settings at all. Users can begin to use these applications right away without being asked to supply set-up information. To achieve this in your application, there are a few design decisions you can make:
Focus your solution on the needs of 80 percent of your users. When you do this, the majority of users do not need to supply settings because your application is already set up to behave the way most users expect. If there is functionality that only a handful of users might want, or that most users might want only once, leave it out.
Get as much information as possible from other sources. If you can use any of the information users supply in built-in application or device settings, query the system for these values; don’t ask users to enter them again.
If you must ask for set-up information, prompt users to enter it within your application. Then, as soon as possible, store this information in your application’s settings. This way, users aren’t forced to quit your application and open Settings before they begin to benefit from your application. If users need to make changes to this information later, they can go to your application’s settings at any time.
It’s not possible for users to open the Settings application without first quitting your application, and you should not encourage them to take this action. There is no system-provided icon or control that supports this action, and it’s recommended that you avoid creating a custom icon or control that does. If you decide you must provide settings in your iPhone application, see “The Settings Bundle” in iOS Application Programming Guide to learn how to support them in your code.
Unlike settings, configuration options are likely to be changed frequently as users choose to see information from new sources or in different arrangements. You can react dynamically to changes users make to these options, because users do not leave your application to access them.
You can offer configuration options in the main user interface or on the back of a screen. To decide which technique makes sense, determine if the options represent primary functionality and how often users might want to set them.
For example, Calendar allows users to view their schedules by day, week, or month. These options could have been offered on the back of the screen, but viewing different parts of a calendar is primary functionality and users are likely to change their focus frequently.
On the other hand, the primary functionality of Weather is to display a city’s current conditions and 6-day forecast. Although it’s important to be able to choose whether temperatures are displayed in Celsius or Fahrenheit, users are not likely to change this option very often, so it would not make sense to put it in the main user interface. Offering the temperature-scale option on the back of the Weather screen makes it conveniently available, but not obtrusive.
Supporting Copy and Paste
iOS provides an edit (or pasteboard) menu that supports Cut, Copy, Paste, Select, and Select All operations in text views, web views, and image views. The commands in the menu allow people to make changes to their content and copy content from one application into another.
You can adjust some of the behaviors of the edit menu to suit your application. (For information on how to implement these behaviors in code, see “Copy and Paste Operations” in iOS Application Programming Guide.) For example, you can specify the subset of commands the menu displays and you can influence where the menu appears. You have no control over the color or shape of the menu itself.
Use commands that make sense in the current context. For example, if nothing is selected, the menu does not contain Copy or Cut because these commands act on a selection. If you support an edit menu in a custom view, you’re responsible for making sure that the commands the menu displays are appropriate for the current context. Note that you cannot specify custom commands to display in the menu.
Accommodate the menu display in your layout. UIKit displays the edit menu above or below the insertion point or selection, depending on available space, and places the menu pointer so that users can see how the menu commands relate to the content. You can programmatically determine the position of the menu before it appears, so you can prevent important parts of your UI from being obscured, if necessary.
Support both gestures people can use to invoke the menu. Although the touch and hold gesture is the primary way users reveal the edit menu, they can also double-tap a word in a text view to select it and reveal the menu at the same time. If you support the menu in a custom view, be sure to respond to both gestures. In addition, you can define the object that is selected by default when the user double taps.
Avoid creating a button in your UI that performs a command that’s available in the edit menu. For example, it’s better to allow users to perform a copy operation using the edit menu than to provide a Copy button, because users will wonder why there are two ways to do the same thing in your application.
Consider enabling the selection of static text if it’s useful to the user. For example, a user might want to copy the caption of an image, but they’re not likely to want to copy the label of a tab item or a screen title, such as Accounts. In a text view, selection by word should be the default.
Don’t make button titles selectable. A selectable button title makes it difficult for users to reveal the edit menu without activating the button. In general, elements that behave as buttons don’t need to be selectable.
Combine support for undo and redo with your copy and paste support. People often expect to able to undo recent operations if they change their minds. Because the edit menu does not require confirmation before its actions are performed, you should give users the opportunity to undo or redo these actions (to learn how to do this, see “Supporting Undo and Redo”).
Supporting Undo and Redo
iOS gives people the ability to undo and redo their typing in text views. People initiate an undo by shaking the device, which displays an alert that allows them to undo what they just typed, redo previously undone typing, or cancel the undo.
UIKit allows you to support undo in a more general way in your application (for information on how to implement this behavior in code, see Undo Architecture). You can specify:
The actions users can undo or redo
When your application should interpret a shake event as the shake to undo gesture
How many levels of undo to support
To provide a great user experience for the undo and redo capability in your application, you should:
Supply brief descriptive phrases that tell people precisely what they’re undoing or redoing. UIKit automatically supplies the strings “Undo “ and “Redo “ for the undo alert button titles, but you need to provide a word or two that describes the action users can undo or redo. (Note that the Cancel button cannot be changed.) For example, you might supply the text “Delete Name” or “Address Change,” to create buttons titles such as “Undo Delete Name” or “Redo Address Change.”
Be sure to avoid supplying text that is too long: A button title that is too long is truncated and is difficult for users to decipher. Also, because this text is in a button title, use title-style capitalization and do not add punctuation. (Briefly, title-style capitalization means to capitalize every word except articles, coordinating conjunctions, and prepositions of four or fewer letters.)
Avoid overloading the shake gesture. Even though you can programmatically set when your application interprets a shake event as shake to undo, you run the risk of confusing people if they also use shake to perform a different action.
The shake gesture is the primary way people expect to initiate undo and redo, but you can also include the system-provided Undo and Redo buttons in a navigation bar, if appropriate. You might do this if it’s essential that you display an explicit, dedicated button to perform these functions within the context of your application, but this is unusual.
Consider the context of the actions you allow to be undone or redone. In general, people expect their changes and actions to take effect immediately. As much as possible, the undo and redo capability should be clearly related to the user’s immediate context, and not to an earlier context.
Enabling Local and Push Notifications
Both local and push notifications allow you to tell people about something when your application isn’t running in the foreground. For example, you might want to let people know that:
A message has arrived
An event is about to occur
New data is available for download
The status of something has changed
Local notifications are scheduled by an application and delivered by iOS on the same device, regardless of whether the application is currently running in the foreground. For example, a calendar or to-do application can schedule a local notification to alert people of an upcoming meeting or due date.
Push notifications are sent by an application’s remote server to Apple Push Notification service, which pushes the notification to all devices that have the application installed. For example, a game that a user can play against remote opponents can update all players with the latest move.
If your application is not running in the foreground when a local or push notification arrives, you can get the user’s attention by:
Updating a badge on your application’s Home screen icon
Displaying an alert
You can also play a sound when a badge updates or an alert appears.
If your application is running in the foreground, you can still receive local and push notifications, but you pass the information to your users in an application-specific way. In Settings, people can allow or disallow badging, sounds, and alerts for push notifications from selected applications or from all applications. There is no similar mechanism for disabling local notifications, because this is something people should be able to specify within each application.
Different notification techniques might be appropriate in different situations, so you should be prepared to use both types. In general:
Use a badge when the number of new items is informative and the items are not time-critical. A badge is a good way to tell people how many items are waiting for their attention, such as unread messages, assigned tasks, or updates to a shared document. Because people don’t see badges unless they visit the Home screen, you probably don’t want to use them to deliver time-sensitive information.
You do not have any control over the appearance of the badge or its position: It’s a small red oval that appears over the upper-right corner of your Home screen icon.
A badge contains only numbers, not letters or punctuation.
Use an alert when you need to deliver important information users want to know or act upon right away. An alert is a good way to tell people about an upcoming event or a status change. Alerts interrupt the user’s workflow, so it’s best when you use them sparingly.
Follow these guidelines to create local and push notifications that users appreciate.
Keep badge contents up to date. It’s especially important to update the badge as soon as users have attended to the new information, so that they don’t think additional information has arrived.
Provide a custom message for an alert. Your custom message is displayed in the center of the alert, below your application name (which is automatically displayed at the top of the alert). As with the message in a standard alert (described in “Designing an Alert”), a local or push notification alert message should:
Focus on the information, not user actions. Avoid telling people which button to tap or describing the results of tapping a specific button.
Be short enough to display on one or two lines. If the message is too long, it might force the notification alert to scroll.
Use sentence-style capitalization and appropriate ending punctuation. When possible, use a complete sentence.
Optionally, provide a custom title for the action button. An alert can contain one or two buttons. In a two-button alert, the Close button is on the left and the action button (titled View by default) is on the right. If you specify one button, the alert displays an OK button.
Tapping the action button simultaneously dismisses the alert and launches your application. Tapping either the Close button or the OK button dismisses the alert without opening your application.
If you want to use a custom title for the action button, be sure to create a title that clearly describes the action that occurs when your application launches. For example, a game might use the title Play to indicate that tapping the button opens the application to a place where the user can take their turn. Make sure the title:
Uses title-style capitalization
Is short enough to fit in the button without truncation (be sure to test the length of localized titles, too)
Note: Your custom button title can also be displayed in the “slide to view” message people see when a notification arrives while the device is locked. When this happens, the custom title is automatically converted to lowercase and replaces the word “view” in the message.
Optionally, provide a launch image. In addition to displaying your existing launch images, you can supply a different launch image to display when people start your application in response to a notification. For example, a game might specify a launch image that’s similar to a screen within the game, instead of an image that’s similar to the opening menu screen. If you don’t supply this launch image, iOS displays either the previous snapshot or one of your other launch images. (To learn how to create a launch image, see “Launch Images.”)
If appropriate, play a sound to accompany a badge or an alert. A sound can get people’s attention when they’re not looking at the device screen. It’s best when sounds are reserved for notifications that users consider important. For example, a calendar application might play a sound with an alert that reminds people about an imminent event. Or, a collaborative task management application might play a sound with a badge update to signal that a remote colleague has completed an assignment.
You can supply a custom sound, or you can use a built-in alert sound. If you create a custom sound, be sure it is short, distinctive, and professionally produced. (To learn about the technical requirements for this sound, see “Preparing Custom Alert Sounds” in Local and Push Notification Programming Guide.) Note that you cannot programmatically force the device to vibrate when a notification is delivered, because the user has control over whether alerts are accompanied by vibration.
Making Your Application Accessible
An application is accessible when users with disabilities can use it successfully, perhaps with the help of an assistive application or device. iOS-based devices include many features that make it easier for all users, including disabled users, to use the device, such as visual voicemail, zoom, and voice control. You do not have to take any steps in your application to ensure that your users can benefit from these features.
With VoiceOver, Apple’s innovative screen-reading technology, the story is a little different. To make sure VoiceOver users can use your application to its fullest, you might need to provide some custom information about the views and controls in the user interface.
Fortunately, UIKit controls and views are accessible by default, so when you use standard elements in a completely standard way, you have little (if any) additional work to do. The more custom your user interface is, the more custom information you need to provide, so that VoiceOver can properly describe your application.
Important: The job of making your application accessible consists of giving VoiceOver the information it needs to help people use your application. The job does not include changing the visual design of the user interface to accommodate VoiceOver.
Making your iPhone application accessible to VoiceOver users is the right thing to do. It can also increase your user base and it might help you address accessibility guidelines created by various governing bodies.
Providing Search and Displaying Search Results
UIKit provides the search bar control you can use to display a consistent interface to initiate searching, but you are responsible for implementing search in your application. (To learn more about the search bar, see “Search Bars”; to learn more about handling search results in code, see UISearchDisplayController Class Reference.) To ensure that search is a useful and convenient experience users appreciate, take some time to consider how to implement the process and how to display the results.
In general, you should:
Build indexes of your data so you are always prepared for search.
Live-filter local data so you can display results as soon as users begin to type, and narrow the results as users continue typing.
When possible, also filter remote data as users type, but be sure to get the user’s permission if the response time is likely to delay the results by more than a second or two.
Display a search bar above a list or the index in a list.
Avoid using a tab for search unless it is a primary function in your application that should be featured as a distinct mode.
Although live-filtering data usually produces a superior user experience, it’s not always practical. When this is the case, you can begin the search process after the user taps the Search button in the keyboard. If you do this, be sure to provide feedback on the search’s progress so users know that the process has not stalled. One way to do this is to display textual results as soon as possible and display placeholder content for data that might take longer to retrieve.
In YouTube, for example, users initiate a search for videos by tapping the Search button. If the network connection is slow, YouTube first displays the Loading... message along with a spinning activity indicator so users know that search is proceeding. Then, YouTube displays a results list in which each row is populated with textual results, such as video title and viewer rating, and a custom image of a box with a dotted outline. As users scan the list of video titles, the video thumbnails replace the dotted boxes as they are downloaded. Displaying partial search results while additional data is still downloading gives users useful information promptly.
If you handle data that sorts naturally into different categories, you can provide a scope bar. A scope bar contains up to four scope buttons, each representing a category. For example, Mail provides a scope bar that allows users to focus their search on the From, To, or Subject fields of messages, or broaden the search to include all fields. Consider providing a scope bar if it helps users focus their search or if it significantly reduces the number of results. (To learn how to implement a scope bar in your code, see UISearchBar Class Reference.)
Using the User’s Location
Users appreciate application features that allow them to automatically tag content with their physical location, or to find friends that are currently nearby. Users also appreciate being able to disable features like these when they don’t want to share their location with others. Users can grant (or deny) system-wide access to their physical location with the Location Services setting in Settings > General.
If users turn off Location Services, and later use an application feature that requires their location, they see an alert that tells them they must change their preference before they can use the feature. The alert does not allow them to make this change within the application; instead, they must go to Settings and change their preference. This ensures that users are fully aware that they are granting system-wide permission to use their location information.
To help users understand why they might need to turn Location Services on, it’s best if they see the alert only when they attempt to use a feature that clearly needs to know their current location. For example, people can use Maps when Location Services is off, but they see the alert when they access the feature that finds and tracks their current location.
If Location Services is turned off, iOS displays the alert the first time your application tries to access location information. The Core Location framework provides a way for you to get the user’s preference so that you can avoid triggering this alert unnecessarily or inappropriately. (See Core Location Framework Reference to learn more about this programming interface.)
With knowledge of the user’s preference, you can trigger the alert as closely as possible to the feature that requires location information, or perhaps avoid it altogether.
If your application cannot perform its primary function without this information, it’s best if users see the alert as soon as they start your application. Users will not be bothered by this, because they understand that the main function of your application depends on knowing their location.
If the user’s location is not part of the essential function of your application, you might choose to simply restrict the feature that uses it. For example, when Location Services is turned off, Camera automatically turns off the feature that adds the user’s location to the photos they take. It does not prevent users from taking photos unless they change their preference, because adding location information to photos is appreciated, but not essential.
If a feature needs location information to function, be sure to avoid making any programmatic calls that trigger the alert before the user actually selects the feature. (The call that gets the user’s preference does not trigger the alert.) This way, you avoid causing users to wonder why your application wants their location information when they’re doing something that doesn’t appear to need it.
Handling Orientation Changes
Users can rotate iOS-based devices at any time, and they expect the content they’re viewing to respond appropriately. In your iPhone application, be sure to:
Be aware of accelerometer values (for more information on the accelerometer and references to accelerometer programming interfaces, see iOS Application Programming Guide). If appropriate, your application should respond to all changes in device orientation.
If there’s a part of your application’s user interface that displays in one orientation only, it’s appropriate for that area to appear in that orientation and not respond to changes in device orientation. For example, when a user selects an iPod video to view, the video displays in landscape orientation, regardless of the current device orientation. This signals the user to physically rotate the device to view the video. The important point about this example is that iPod does not provide a “rotate now” button; instead, the user knows to rotate the device because the video appears in landscape orientation.
Allow users to physically rotate the device to correctly view the parts of your application’s user interface that require a specific orientation. Avoid creating a control or defining a gesture that tells users to rotate the device.
Take advantage of the one-step orientation-change process to perform smoother, often faster rotations. However, if your screen layout is very complicated, you might choose instead to perform a cross-fade transition when an orientation-change occurs. To learn how to support the one-step process in your code, see UIViewController Class Reference.
Users often rotate their devices to landscape orientation because they want to “see more.” If you respond by merely scaling up your content, you fail to meet users’ expectations. Instead, you should respond by rewrapping lines of text and, if necessary, rearranging the layout of the user interface so that more content fits on the screen.
Using Sound
Users decide how loud sounds should be and whether they want to hear them at all. Sometimes, users expect to hear certain sounds even when their current settings indicate that they prefer silence. For example, users always expect to hear the ringtone or alarms that they have set. Essentially, users want to hear sounds they ask for, but avoid hearing sounds they don’t ask for.
To help you accommodate this, iOS provides programming interfaces you can use to:
Describe how your application’s sounds should fit in with other sounds on the device
Ensure that your application’s sounds play according to users’ expectations
Before you decide how to handle sound in your application, you need to understand how users expect applications and the device to behave when they adjust device controls and use external devices, such as headphones and headsets.
The Ring/Silent Switch—What Users Expect
Users use the Ring/Silent switch to silence their devices when they want to:
Avoid being interrupted by unexpected sounds, such as Phone ringtones and incoming message sounds.
Avoid hearing sounds that are the byproducts of user actions, such as keyboard or other feedback sounds, incidental sounds, or application startup sounds.
Avoid hearing game sounds, including incidental sounds and soundtracks, that are not essential to using the game.
For example, in a theater users switch their devices to silent to avoid bothering other people in the theater. In this situation, users still want to be able to use applications on their devices, but they don’t want to be surprised by sounds they don’t expect or explicitly request, such as ringtones or new message sounds.
However, the Ring/Silent switch does not silence sounds that result from user actions that are solely and explicitly intended to produce sound. For example:
Media playback in a media-only application is not silenced by the Ring/Silent switch because the media playback was explicitly requested by the user.
A Clock alarm is not silenced by the Ring/Silent switch because the alarm was explicitly set by the user.
A sound clip in a language-learning application is not silenced by the Ring/Silent switch because the user took explicit action to hear it.
Conversation in an audio chat application is not silenced by the Ring/Silent switch because the user started such an application for the sole purpose of having an audio chat.
This behavior follows the principle of user control because it is up to the user, not the device, to decide whether it's appropriate to hear sounds the user explicitly requests.
Volume Buttons—What Users Expect
Users use the device’s volume buttons to adjust the volume of all sounds their devices can play, including songs, application sounds, and device sounds. Users can always use the volume buttons to quiet any sound, regardless of the position of the Ring/Silent switch.
Using the volume buttons to adjust an application’s currently playing audio also adjusts the overall system volume, with the exception of the ringer volume. (Using the volume buttons when no audio is currently playing adjusts the ringer volume.)
If you need to display a volume slider, be sure to use the system-provided volume slider available when you use the MPVolumeView class. Note that when the currently active audio output device does not support volume control, the volume slider is replaced by the appropriate device name.
Sometimes, an application might need to adjust relative, independent volume levels to produce the best mix in its audio output. But the volume of the final audio output should always be governed by the system volume, whether it’s adjusted by the volume buttons or a volume slider. This means that control over the application’s audio output remains in users’ hands, where it belongs.
Headsets and Headphones—What Users Expect
Users plug in headsets and headphones to hear sounds privately and to free their hands. Users have different expectations for application behavior, depending on whether they’re plugging in or unplugging these accessories.
When users plug in a headset or headphones, they intend to continue listening to the current audio, but privately. For this reason, they expect an application that is currently playing audio to continue playing without pause.
When users unplug a headset or headphones, they don’t want to automatically share what they’ve been listening to with others. For this reason, they expect an application that is currently playing audio to pause, allowing them to explicitly restart playback when they’re ready.
Wireless Audio—What Users Expect
People use wireless headsets and headphones for the same reasons they use wired headsets and headphones: they want to hear sounds privately and they want to free their hands.
Users also have very similar expectations for the user experience of wireless headsets:
When users connect to a wireless audio device, they intend to continue listening to the current audio, but privately. In this situation, they expect the audio to continue playing without pause.
When users disconnect from a wireless device (or the device goes out of range or turns off), they don’t want to automatically share what they’ve been listening to with others. In this situation, they expect currently playing audio to pause, allowing them to explicitly restart playback when they’re ready.
Even though people don’t physically plug in or unplug a wireless audio device, they still expect to be able to choose a different audio route. To handle this, iOS automatically displays a control that allows users to pick an output audio route. (To ensure that this control can appear in your application, you need to use the MPVolumeView class.) Because choosing a different audio route is a user-initiated action, users expect currently playing audio to continue without pause.
Define the Audio Behavior of Your Application
If sound enhances or is essential to the user experience or functionality of your application, you need to decide how your audio should fit in with the audio environment of the device and how it should respond to user actions. You make this decision based, in part, on how your audio should behave when:
The device locks or is switched to silent
Other audio is currently playing
Your application needs to handle both audio input and output, either sequentially or simultaneously
To influence how your application’s audio should behave in situations such as these, use Audio Session Services or the AVAudioSession class. These programming interfaces do not produce sound; instead, they help you express how your audio should interact with audio on the device and respond to interruptions and changes in device configuration. (To learn how to use these audio programming interfaces in your code, see Audio Session Programming Guide.)
If your application produces only UI sound effects that are incidental to its functionality, you can use System Sound Services. System Sound Services is the iOS technology that produces alerts and UI sounds and invokes vibration; it is unsuitable for any other purpose and the sounds it produces are not governed by Audio Session Services. (For a sample project that demonstrates how to use this technology, see Audio UI Sounds (SysSound).)
Important: No matter what technology you use to produce audio or how you define its behavior, the phone can always interrupt the currently running application. This is because no application should prevent users from receiving an incoming call.
In Audio Session Services, the audio session functions as an intermediary for audio between your application and the system. One of the most important facets of the audio session is the category, which defines the audio behavior of your application.
To realize the benefits of Audio Session Services and provide the audio experience users expect, you need to select the category that best describes the audio behavior of your application. This is the case whether your application only plays audio in the foreground or can also play audio in the background. Follow these guidelines as you make this selection:
Select an audio session category based on its semantic meaning, not its precise set of behaviors. This ensures that your application behaves according to users’ expectations. In addition, it gives your application the best chance of working properly if the exact set of behaviors is refined in the future.
In rare cases, add a property to the audio session to modify a category’s standard behavior. A category’s standard behavior represents what most users expect, so you should consider carefully before you change that behavior. For example, you might add the
kAudioSessionProperty_OtherMixableAudioShouldDuckproperty to make sure your audio is louder than all other audio (except phone audio), if that’s what users expect from your application. (To learn more about audio session properties, see “Fine-Tuning the Category” in Audio Session Programming Guide.)Consider basing your category selection on the current audio environment of the device. This might make sense if, for example, users can use your application while listening to other audio instead of your soundtrack. If you do this, be sure to avoid forcing users to stop listening to their music or make an explicit soundtrack choice when your application starts.
In general, avoid changing categories while your application is running. The primary reason for changing the category is if your application needs to support recording and playback at different times. In this case, it can be better to switch between the Record category and the Playback category as needed, than to select the Play and Record category. This is because selecting the Record category ensures that no alerts (such as an incoming text message alert) will sound while the recording is in progress.
Regardless of your category choice, it’s important to activate your audio session only when it’s needed and deactivate it when it’s not. This helps ensure a high quality audio experience for users. For example, a VoIP app’s audio session should be active only while the app is handling a call.
Table 4-1 lists the audio session categories you can use. iOS assigns the Solo Ambient category to an audio session by default.
Note: In the interest of space, Table 4-1 displays only the last part of each category name. The actual symbol name of each category begins with AVAudioSessionCategory. In addition, the actual symbol name of the MixWithOthers property is kAudioSessionProperty_OverrideCategoryMixWithOthers.
Category | Meaning | Silenced by Ring/Silent switch and locking | Mixes with other audio | Allowed in the background |
|---|---|---|---|---|
| Sounds enhance application functionality, and should silence other audio | Yes | No | No |
| Sounds enhance application functionality, but should not silence other audio | Yes | Yes | No |
| Sounds are essential to application functionality, and might mix with other audio | No | No (default) Yes (when the | Yes |
| Audio is user-recorded | No | No | Yes |
| Sounds represent audio input and output, sequentially or simultaneously | No | No (default) Yes (when the | Yes |
| Application performs hardware-assisted audio encoding (it does not play or record) | - | No | Yes * |
* If you select the Audio Processing category and you want to perform audio processing in the background, you need to prevent your application from suspending before you’re finished. To learn how to do this, see “Executing Code in the Background”.
Here are some scenarios that illustrate how to choose the audio session category that provides an audio experience users appreciate.
Scenario 1: An educational application that helps people learn a new language. You provide:
Feedback sounds that play when users tap specific controls
Recordings of words and phrases that play when users want to hear examples of correct pronunciation
In this application, sound is essential to the primary functionality. People use this application to hear words and phrases in the language they’re learning, so the sound should play even when the Ring/Silent switch is set to silent or the device locks. Because users need to hear the sounds clearly, they expect other audio they might be playing to be silenced.
To produce the audio experience users expect for this application, you would use the Playback category. Although this category can be refined to allow mixing with other audio, this application should use the default behavior to ensure that other audio does not compete with the educational content the user has explicitly chosen to hear.
Scenario 2: A Voice over Internet Protocol (VoIP) application. You provide:
The ability to accept audio input
The ability to play audio
In this application, sound is essential to the primary functionality. People use this application to communicate with others, often while they’re currently using a different application. Users expect to be able to receive calls when the Ring/Silent switch is set to silent or the device is locked, and they expect other audio to be silent for the duration of a call. They also expect to be able to receive and continue calls when the application is in the background.
To produce the expected user experience for this application, you would use the Play and Record category. In addition, you would be sure to activate your audio session only when you need it so that users can use other audio between calls.
Scenario 3: A game that allows users to guide a character through different tasks. You provide:
Various gameplay sound effects
A musical soundtrack
In this application, sound greatly enhances the user experience, but is not essential to the main task. Also, users are likely to appreciate being able to play the game silently or while listening to songs in their music library instead of to the game soundtrack.
The best strategy is to find out if users are listening to other audio when your application starts. Don’t ask users to choose whether they want to listen to other audio or listen to your soundtrack. Instead, use the Audio Session Services function AudioSessionGetProperty to query the state of the kAudioSessionProperty_OtherAudioIsPlaying property. Based on the answer to this query, you can choose either the Ambient or Solo Ambient categories (both categories allow users to play the game silently):
If users are listening to other audio, you should assume that they’d like to continue listening and would not appreciate being forced to listen to the game soundtrack instead. In this situation, you would choose the Ambient category.
If users are not listening to any other audio when your application starts, choose the Solo Ambient category.
Scenario 4: An application that provides precise, real-time navigation instructions to the user’s destination. You provide:
Spoken directions for every step of the journey
A few feedback sounds
The ability for users to continue to listen to their own audio
In this application, the spoken navigation instructions represent the primary task, regardless of whether the application is in the background. For this reason, you would use the Playback category, which allows your audio to play when the device is locked or the Ring/Silent switch is set to silent, and while the application is in the background.
To allow people to listen to other audio while they use your application, you can add the kAudioSessionProperty_OverrideCategoryMixWithOthers property. However, you also want to make sure that users can hear the spoken instructions above the audio they’re currently playing. To do this, you can apply the kAudioSessionProperty_OtherMixableAudioShouldDuck property to the audio session. This ensures that your audio is louder than all currently playing audio (except phone audio).
Scenario 5: A blogging application that allows users to upload their text and graphics to a website. You provide:
A short startup sound file
Various short sound effects that accompany user actions (such as a sound that plays when a post has been uploaded)
An alert sound that plays when a posting fails
In this application, sound enhances the user experience, but it is incidental. The main task has nothing to do with audio and users do not need to hear any sounds to successfully use the application. In this scenario, you would use System Sound Services to produce sound. This is because the audio context of all sound in the application conforms to the intended purpose of this technology, which is to produce UI sound effects and alert sounds that obey device locking and the Ring/Silent switch as users expect.
Manage Audio Interruptions
There are times when currently playing audio is interrupted by audio from a different application. For example, an incoming phone call interrupts the current application’s audio for the duration of the call. In a multitasking environment, the frequency of such audio interruptions is likely to be greater.
To provide an audio experience users appreciate, iOS relies on you to:
Identify the type of audio interruption your application can cause
Respond appropriately when your application continues after an audio interruption ends
Every application needs to identify the type of audio interruption it can cause, but not every application needs to determine how to respond to the end of an audio interruption. This is because, for most types of applications, the appropriate response to the end of an audio interruption is to resume playing audio. Only applications that are primarily or partly media playback applications, and that provide media playback controls, have to take an extra step to determine the appropriate response.
Conceptually, there are two types of audio interruptions, based on the type of audio that is doing the interrupting and the way users expect certain applications to respond when the interruption ends:
Resumable interruption. A resumable interruption is caused by audio that users view as a temporary interlude in their primary listening experience.
After a resumable interruption ends, an application that displays media playback controls should resume what it was doing when the interruption occurred, whether this is playing audio or remaining paused. An application that doesn’t have media playback controls should resume playing audio.
For example, consider a user listening to a music playback application when a VoIP call arrives in the middle of a song. The user answers the call, expecting the music playback application to be silent while they talk. After the call ends, the user expects the playback application to automatically resume playing the song, because the music—not the call—constitutes their primary listening experience and they had not paused the music before the call arrived. If, on the other hand, the user had paused music playback before the call arrived, they would expect the music to remain paused after the call ends.
Other examples of applications that can cause resumable interruptions are applications that play alarms, audio prompts (such as spoken driving directions), or other intermittent audio.
Nonresumable interruption. A nonresumable interruption is caused by audio that users view as a primary listening experience, such as audio from a media playback application.
After a nonresumable interruption ends, an application that displays media playback controls should not resume playing audio. An application that doesn’t have media playback controls should resume playing audio.
For example, consider a user listening to a music playback application (music app 1) when a different music playback application (music app 2) interrupts. In response, the user decides to listen to music app 2 for some period of time. After quitting music app 2, the user would not expect music app 1 to automatically resume playing because they’d deliberately made music app 2 their primary listening experience.
The following guidelines help you decide what information to supply and how to continue after an audio interruption ends.
Identify the type of audio interruption your application caused. You do this by deactivating your audio session in one of the following two ways when your audio is finished:
If your application caused a resumable interruption, deactivate your audio session with the
AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivationflag.If your application caused a nonresumable interruption, deactivate your audio session without any flags.
Providing this information helps iOS to give interrupted applications the ability to resume playing their audio automatically, if appropriate.
Determine whether you should resume audio when an audio interruption ends. You base this decision on the audio user experience you provide in your application.
If your application displays media playback controls that people use to play or pause audio, you need to check the
AVAudioSessionInterruptionFlags_ShouldResumeflag when an audio interruption ends.If you receive the Should Resume flag, you should:
Resume playing audio if your application was actively playing audio when it was interrupted
Not resume playing audio if your application was not actively playing audio when it was interrupted
If your application does not display any media playback controls that people can use to play or pause audio, you should always resume previously playing audio when an audio interruption ends. You do not have to check for the presence of the Should Resume flag.
For example, a game that plays a soundtrack should automatically resume playing the soundtrack after an interruption.
Handle Media Remote Control Events, if Appropriate
Beginning in iOS 4.0, applications can receive remote control events when users use iOS media controls or accessory controls (such as headset controls). This capability allows your application to accept user input that does not come through your UI, whether your application is currently playing audio in the foreground or in the background.
A media playback application, in particular, needs to respond appropriately to these events, especially if it plays audio while it’s in the background.
To meet the responsibilities associated with this privilege, be sure to follow these guidelines:
Limit the eligibility to receive remote control events to times when it makes sense. If, for example, your application allows users to read content, search for information, and listen to audio, it should only accept remote control events while the user is in the audio context. When the user leaves the audio context, you should relinquish the ability to receive the events. This allows users to listen to a different application’s audio (and control it with headset controls) while they’re in the nonaudio contexts of your application.
Don’t repurpose an event, even if the event has no meaning in your application. Users expect the iOS media controls and accessory controls to function consistently in all applications. You do not have to handle the events that your application doesn’t need, but the events that you do handle must result in the experience users expect. If you redefine the meaning of an event, you confuse users and risk leading them into an unknown state from which they can’t escape without quitting your application.
Providing Choices
iOS includes a few elements that help users make selections. When you need to offer choices in your application, you should use these selection methods because users are already familiar with their behavior. In general, you should not try to replicate the appearance and behavior of selection controls you might see in a desktop computer application, such as an application menu or a set of radio buttons. iOS provides the following elements you can use to offer choices to users:
Lists (that is, table views). Users tap a row in a list to select an item. Lists are suitable for displaying almost any number of choices. For details on the ways you can use table views in your application, see “Table Views.”
Pickers, including date and time pickers. Users spin the wheels in a picker until each wheel displays the desired part of a multipart value, such as a calendar date that comprises year, month, and day. For more information about using pickers in your iPhone application, see “Date and Time Pickers” and “Pickers.”
Switch controls. Users slide a switch control from one side to the other, revealing one of two values. A switch control is intended to offer a simple choice within a list. For more information about switch controls, see “Switch Controls.”
Providing a License Agreement or a Disclaimer
If you provide an end-user license agreement (or EULA) with your iPhone application, be aware that the App Store displays it, so that people can read it before they get your application.
If possible, try to avoid requiring users to indicate their agreement to your EULA when they first start your application. This allows users to enjoy your application without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your application, try to do so in a way that harmonizes with your user interface and causes the least inconvenience to users.
Similarly, if you need to provide a disclaimer, be sure to balance your business needs with maintaining a great user experience. If you can, provide your disclaimer within your application description or EULA, so that it is available in the App Store.
Last updated: 2010-08-03