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 iPhone Application Programming Guide.
iPhone applications should start instantly so users can begin using them without delay. When starting, iPhone applications should:
Specify the appropriate status bar style (see “The Status Bar” for information about the available styles).
Display a launch image that closely resembles the first screen of the application. This decreases the perceived launch time of your application. For more information, see “Launch Images.”
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.
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 iPhone Application Programming Guide for some guidance on developing a well-tuned application.
iPhone applications stop when users open a different application or use a device feature, such as the phone. In particular, note that users don’t tap an application close button or select Quit from a menu. iPhone applications should:
Be prepared to receive an exit or terminate notification 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. See “Using Alerts” for more information about creating alerts.
iPhone applications can offer settings that define preferred application behaviors or configuration options users can set 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 iPhone 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.
iPhone OS provides an edit (or pasteboard) menu that supports Cut, Copy, Paste, Select, and Select All operations in text views, web views, and image views. One of the ways users can reveal the menu is to first touch and hold to display the magnified view (which allows them to move the insertion or selection point to the correct location) and then release. If the menu is supported in the current context, it appears when the finger is lifted. Choosing Select in the menu selects the word or application-defined item in the view. Users can extend their selection by dragging the handles on the currently selected area. After a selection is made, the menu can display Cut, Copy, or Paste, as appropriate.
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 iPhone 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.
The commands visible in the edit menu 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. Similarly, if something is selected, the menu does not contain Select. 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.
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 application’s user interface from being obscured, if necessary.
Note that 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, you should 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 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.
You can enable selection of static text, but only when the static text represents content that’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.
Button titles should not be selectable because it would be 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.
If you support the Cut, Copy, and Paste commands in your application, you should also support undo and redo (described in “Supporting Undo and Redo”). This is because the edit menu does not require confirmation before the actions are performed and users often expect to be able to undo recent operations if they change their minds.
iPhone OS gives users the ability to undo and redo their typing in text views. Users initiate an undo by shaking the device, which displays an alert that allows users 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 users 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 users if they also use shake to perform a different action.
The shake gesture is the primary way users 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, users 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.
When you register your application with Apple Push Notification Service, you can arrange to alert users when new data arrives, even if your application isn’t running. When a device receives a message for an application that isn’t running, it can notify the user by:
Updating a badge on the application’s Home screen icon
Playing an alert sound
Displaying an alert message
or some combination of these. The user might respond by starting the application to manage the new data or merely acknowledging its arrival. (To learn how to handle push notifications in code, see Apple Push Notification Service Programming Guide.)
The Notifications section in the built-in Settings application hosts push notification settings for every application that registers for the Apple Push Notification Service. For each application, iPhone OS provides settings for users to allow or disallow badging, sounds, and alert messages.
Take some time to think about the types of events for which users would appreciate notification. A notification should give users useful, actionable information they want to receive, even when they’re not using your application.
After you’ve identified the events your users are likely to care about, you should also allow users to decide which events should generate what type of notification, if any. If you don’t allow users to customize the push notification experience in your application, you’re liable to pester users with notifications they’re not interested in.
Users can choose which types of notifications they want to receive, so you should support all three types:
Badge. Badging is the least intrusive way to tell users that there is new content they might be interested in. The badge is a small red oval that appears over the upper-right corner of your Home screen icon. You do not have any control over the appearance of the badge and it contains only numbers, not letters or punctuation.
Badging works well when you want to tell users how many items are waiting for their attention. For example, the number in a badge might indicate unread messages, newly assigned tasks, or how many remote players are currently playing a game.
Sound. You can supply a custom alert 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 Apple Push Notification Service Programming Guide.) Note that you cannot force the device to vibrate when a notification is delivered; the user has control over whether alerts are accompanied by vibration.
An easily recognized sound is ideal for situations in which the notification arrival itself provides enough information for users to act. For example, a collaborative task management system might use a unique sound to accompany the completion of a member’s assignment. Merely hearing this sound tells the user that the assignment has been completed.
Alert. An alert is the most intrusive way to notify users of new content. An alert displays your application name at the top, your message below that, and one or two buttons at the bottom. If you specify two buttons, the alert displays the Close button on the left and the View button on the right (users can tap the View button to simultaneously dismiss the alert and launch your application). If you specify one button, the alert displays an OK button. The Close button and the OK button both dismiss the alert without opening your application.
Alerts interrupt the user’s workflow, so they’re best used sparingly to deliver a short, important message about an event. In particular, be sure to avoid including any advertising content in your alert message.
An application is accessible when users with disabilities can use it successfully, perhaps with the help of an assistive application or device. iPhone OS–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, the story is a little different. VoiceOver is Apple’s innovative screen-reading technology, which gives users control over their devices without requiring them to see the screen. 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 to users with visual impairments.
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.
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.)
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, iPhone OS 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.
Users can rotate iPhone OS–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 iPhone 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.
Users expect great sound from iPhone OS–based devices, whether they’re hearing system sounds, such as ringtones and alert sounds, or application sounds, such as media playback, ambient sounds, and soundtracks. In addition, users expect sounds from their devices to obey both their preferences and their intentions.
Users decide how loud sounds should be and whether they want to hear them at all. Sometimes, however, users expect to hear certain sounds even when their current settings indicate that they prefer silence. For example, users always expect to hear 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, iPhone OS 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.
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.
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. This means that users can always use the volume buttons to quiet any sound, regardless of the position of the Ring/Silent switch.
In some cases, it might be appropriate for an application to give users volume-setting capability in the application’s user interface. For example, YouTube displays a volume slider users can use to adjust the volume of the video they’re watching. While YouTube is running, users can use the slider and the volume buttons interchangeably to affect the video’s volume. This is because the slider acts as a proxy for the volume buttons while the application is running: The slider affects both the application’s volume and overall system volume, with the exception of 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 (such as an A2DP device), the volume slider is replaced by the appropriate device name.
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.)
This behavior follows the principle of user control because the user always decides how loud sounds from their device should be.
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.
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.
Users appreciate the convenience of wireless headsets, such as Bluetooth A2DP devices. 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, iPhone OS automatically displays a control that allows users to pick an output audio route. Because choosing a different audio route is a user-initiated action, users expect currently playing audio to continue without pause.
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. For example, you need to decide whether:
Your audio should continue playing when the device locks or is switched to silent
Your audio should mix with other audio that is currently playing (such as a song in iPod)
Your application needs to handle both audio input and output, either sequentially or simultaneously
Your audio should automatically resume playing after an interruption
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. Audio Session Services governs sound produced using technologies such as the AV Foundation framework, Audio Queue Services, OpenAL, and the I/O audio unit.
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.
The audio session is an intermediary for audio between your application and the system. From a user-experience perspective, the most important facet of the audio session is the category that defines the audio behavior of your application.
To provide a great audio user experience, select the category that best describes the audio in your application. Be sure to make your choice based on the semantic meaning of a category, 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, you might need to enhance or refine a category’s standard behavior by adding a property to the audio session. For example, you can add the kAudioSessionProperty_OtherMixableAudioShouldDuck property to make sure your application’s audio is louder than all other audio (except phone audio). You might do this if it’s important for the user to hear the audio from your application while other audio is playing. However, you should be aware that a category’s standard behavior represents what most users expect, so you should consider carefully before you add a property to refine that behavior. To learn more about audio session properties, see “Fine-Tuning the Category” in Audio Session Programming Guide.
You can base your category selection on the current audio environment of the device. You might want to do this if, for example, users can use your application while listening to other audio instead of the soundtrack you provide. If this makes sense for your application, be sure to avoid forcing users to stop listening to their music or make an explicit soundtrack choice when your application starts. See Scenario 2 in “Putting it All Together” to learn how to do this.
It’s also possible to change categories while your application is running, although this is seldom necessary. The primary reason for doing this is when an application needs to support recording and playback at different times. In such an application, it can be better to switch between the Record category and the Playback category as needed, than to choose the Play and Record category. This is because choosing the Record category ensures that no alerts (such as an incoming text message alert) will sound while the recording is in progress.
Table 4-1 lists the audio session categories you can use. iPhone OS assigns the Solo Ambient category to an audio session by default.
AVAudioSessionCategory. The actual symbol name of the MixWithOthers property is kAudioSessionProperty_OverrideCategoryMixWithOthers.Category | Meaning | Silenced by Ring/Silent switch and locking | Mixes with other audio |
|---|---|---|---|
| Sounds enhance application functionality, and should silence other audio | Yes | No |
| Sounds enhance application functionality, but should not silence other audio | Yes | Yes |
| Sounds are essential to application functionality, and might mix with other audio | No | No (default) Yes (when the |
| Audio is user-recorded | No | No |
| Sounds represent audio input and output, sequentially or simultaneously | No | No (default) Yes (when the |
| Application performs hardware-assisted audio encoding (it does not play or record) | - | No |
Here are some scenarios that illustrate how to choose the audio session category that provides an audio experience users appreciate.
Scenario 1. Imagine that you’re developing an educational application that helps people learn a new language. You provide feedback sounds that play when users tap specific controls and 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 (as described in Table 4-1), 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. Imagine that you’re developing a game that allows users to guide an onscreen character through many different tasks. You provide various gameplay sound effects and 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 3. Imagine that you’re developing an application that provides precise, real-time navigation instructions to the user’s chosen destination. You provide spoken directions for every step of the journey and a few feedback sounds. In addition, you think people would appreciate being able to listen to their own audio while they use your application.
In this application, the spoken navigation instructions represent the primary task. 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.
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 4. Imagine that you’re developing a blogging application that allows users to upload their text and graphics to a central website. You might have 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), and 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 user interface sound effects and alert sounds that obey device locking and the Ring/Silent switch as users expect.
iPhone OS 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. iPhone OS 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.”
Sometimes, an application requires users to accept a license agreement before they can begin using the application. Such an agreement (often called an end-user license agreement, or EULA) usually contains various terms and conditions that can describe liability limits and govern usage. If you provide a license agreement 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 with 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 way that harmonizes with your user interface and causes the least inconvenience to users.
Last updated: 2009-11-20
