Safari Developer Library


iOS Human Interface Guidelines



Whether sound is a primary part of your app’s user experience or an optional enhancement, you need to know how users expect sound to behave and how to meet those expectations.

Understand User Expectations

People can use device controls to affect sound, and they might use wired or wireless headsets and headphones. People also have various expectations for how their actions impact the sound they hear. Although you might find some of these expectations surprising, they all follow the principle of user control in that the user, not the device, decides when it’s appropriate to hear sound.

Users switch their devices to silent 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 app startup sounds

  • Avoid hearing game sounds that are not essential to using the game, such as sound effects and soundtracks

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

The Ring/Silent (or 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 app is not silenced because the media playback was explicitly requested by the user.

  • A Clock alarm is not silenced because the alarm was explicitly set by the user.

  • A sound clip in a language-learning app is not silenced because the user took explicit action to hear it.

  • Conversation in an audio chat app is not silenced because the user started the app for the sole purpose of having an audio chat.

Users use the device’s volume buttons to adjust the volume of all sounds their devices can play, including songs, app sounds, and device sounds. Users can use the volume buttons to quiet any sound, regardless of the position of the Ring/Silent (or Silent) switch. Using the volume buttons to adjust an app’s currently playing audio also adjusts the overall system volume, with the exception of the ringer volume.

Users use headsets and headphones to hear sounds privately and to free their hands. Regardless of whether these accessories are wired or wireless, users have specific expectations for the user experience.

When users plug in a headset or headphones, or connect to a wireless audio device, they intend to continue listening to the current audio, but privately. For this reason, they expect an app that is currently playing audio to continue playing without pause.

When users unplug a headset or headphones, or 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. For this reason, they expect an app that is currently playing audio to pause, allowing them to explicitly restart playback when they’re ready.

Define the Audio Behavior of Your App

If necessary, you can adjust relative, independent volume levels to produce the best mix in your app’s 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 an app’s audio output remains in users’ hands, where it belongs.

Ensure that your app can display the audio route picker, if appropriate. (An audio route is an electronic pathway for audio signals, such as from a device to headphone or from a device to speakers.) 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 (use the MPVolumeView class to allow the control to display in your app). Because choosing a different audio route is a user-initiated action, users expect currently playing audio to continue without pause.

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.

If your app produces only UI sound effects that aren’t essential to its functionality, 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. When you use System Sound Services to produce sound, you cannot influence how your audio interacts with audio on the device, or how it should respond to interruptions and changes in device configuration. For a sample project that demonstrates how to use this technology, see Audio UI Sounds (SysSound).

If sound plays an important role in your app, 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.

In Audio Session Services, the audio session functions as an intermediary for audio between your app and the system. One of the most important facets of the audio session is the category, which defines the audio behavior of your app.

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 app. This is the case whether your app plays audio in the foreground only 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. By selecting a category whose purpose is clear, you ensure that your app behaves according to users’ expectations. In addition, it gives your app 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 ducking property to make sure your audio is louder than all other audio (except phone audio), if that’s what users expect from your app. (To learn more about audio session properties, see Fine-Tuning a Category.)

  • Consider basing your category selection on the current audio environment of the device. This might make sense if, for example, users can use your app while listening to other audio instead of to 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 app starts.

  • In general, avoid changing categories while your app is running. The primary reason for changing the category is if your app 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.

Table 35-1 lists the audio session categories you can use. Different categories allow sounds to be silenced by the Ring/Silent or Silent switch (or device locking), to mix with other audio, or to play while the app is in the background. (For the actual category and property names as they appear in the programming interfaces, see Audio Session Programming Guide.)

Table 35-1Audio session categories and their associated behaviors





In Background

Solo Ambient

Sounds enhance app functionality, and should silence other audio.





Sounds enhance app functionality but should not silence other audio.





Sounds are essential to app functionality and might mix with other audio.


No (default)

Yes (when the Mix With Others property is added)



Audio is user-recorded.




Play and Record

Sounds represent audio input and output, sequentially or simultaneously.


No (default)

Yes (when the Mix With Others property is added)


Audio Processing

App performs hardware-assisted audio encoding (it does not play or record).



Yes *

* If you select the Audio Processing category and you want to perform audio processing in the background, you need to prevent your app from suspending before you’re finished with the audio processing. To learn how to do this, see Implementing Long-Running Background Tasks.

Here are some scenarios that illustrate how to choose the audio session category that provides an audio experience users appreciate.

Scenario 1: An educational app 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 app, sound is essential to the primary functionality. People use this app to hear words and phrases in the language they’re learning, so the sound should play even when the device locks or is switched to silent. 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 app, you’d use the Playback category. Although this category can be refined to allow mixing with other audio, this app 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) app. You provide:

  • The ability to accept audio input

  • The ability to play audio

In this app, sound is essential to the primary functionality. People use this app to communicate with others, often while they’re currently using a different app. Users expect to be able to receive calls when they’ve switched their device 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 continue calls when the app is in the background.

To produce the expected user experience for this app, you’d use the Play and Record category, and you’d 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 app, sound greatly enhances the user experience, but isn’t 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 app 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 wouldn’t appreciate being forced to listen to the game soundtrack instead. In this situation, you’d choose the Ambient category.

  • If users aren’t listening to any other audio when your app starts, you’d choose the Solo Ambient category.

Scenario 4: An app 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 app, the spoken navigation instructions represent the primary task, regardless of whether the app is in the background. For this reason, you’d use the Playback category, which allows your audio to play when the device is locked or switched to silent, and while the app is in the background.

To allow people to listen to other audio while they use your app, 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 to ensures that your audio is louder than all currently playing audio, with the exception of phone audio on iPhone. These settings allow the app to reactivate its audio session while the app is in the background, which ensures that users get navigation updates in real time.

Scenario 5: A blogging app 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 app, sound enhances the user experience, but it's not essential. The main task has nothing to do with audio and users don’t need to hear any sounds to successfully use the app. In this scenario, you’d use System Sound Services to produce sound. This is because the audio context of all sound in the app 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 (or Silent) switch in the way that users expect.

Manage Audio Interruptions

Sometimes, currently playing audio is interrupted by audio from a different app. On iPhone, for example, an incoming phone call interrupts the current app’s audio for the duration of the call. In a multitasking environment, the frequency of such audio interruptions can be high.

To provide an audio experience users appreciate, iOS relies on you to:

  • Identify the type of audio interruption your app can cause

  • Respond appropriately when your app continues after an audio interruption ends

Every app needs to identify the type of audio interruption it can cause, but not every app needs to determine how to respond to the end of an audio interruption. This is because most types of apps should respond to the end of an audio interruption by resuming audio. Only apps that are primarily or partly media playback apps—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’s doing the interrupting and the way users expect the particular app to respond when the interruption ends:

  • 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 app that displays controls for media playback should resume what it was doing when the interruption occurred, whether this is playing audio or remaining paused. An app that doesn’t have media playback controls should resume playing audio.

    For example, consider a user listening to an app for music playback on iPhone when a VoIP call arrives in the middle of a song. The user answers the call, expecting the playback app to be silent while they talk. After the call ends, the user expects the playback app 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. On the other hand, if 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 apps that can cause resumable interruptions are apps that play alarms, audio prompts (such as spoken driving directions), or other intermittent audio.

  • A nonresumable interruption is caused by audio that users view as a primary listening experience, such as audio from a media playback app.

    After a nonresumable interruption ends, an app that displays media playback controls should not resume playing audio. An app that doesn’t have media playback controls should resume playing audio.

    For example, consider a user listening to a music playback app (music app 1) when a different music playback app (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 wouldn’t 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 app caused. You do this by deactivating your audio session in one of the following two ways when your audio is finished:

  • If your app caused a resumable interruption, deactivate your audio session with the AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation flag.

  • If your app caused a nonresumable interruption, deactivate your audio session without any flags.

Providing, or not providing, the flags allows iOS to give interrupted apps 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 app.

  • If your app displays media playback controls that people use to play or pause audio, you need to check the AVAudioSessionInterruptionFlags_ShouldResume flag when an audio interruption ends.

    If your app receives the Should Resume flag, your app should:

    • Resume playing audio if your app was actively playing audio when it was interrupted

    • Not resume playing audio if your app was not actively playing audio when it was interrupted

  • If your app doesn’t display any media playback controls that people can use to play or pause audio, your app should always resume previously playing audio when an audio interruption ends, regardless of whether the Should Resume flag is present.

    For example, a game that plays a soundtrack should automatically resume playing the soundtrack after an interruption.

Handle Media Remote Control Events, if Appropriate

Apps can receive remote control events when people use iOS media controls or accessory controls, such as headset controls. This allows your app to accept user input that doesn’t come through your UI, whether your app is currently playing audio in the foreground or in the background.

Apps can send video to AirPlay-enabled hardware—such as Apple TV—and transition to the background while playback continues. Such an app can accept user input via remote control events, so that users can control video playback while the app is in the background. In addition, this type of app can also reactivate an audio session after an interruption while it’s in the background.

A media playback app, in particular, needs to respond appropriately to media remote control events, especially if it plays audio or video while it’s in the background.

To meet the responsibilities associated with the privilege of playing media while your app is in the background, be sure to follow these guidelines:

Limit your app’s eligibility to receive remote control events to times when it makes sense. For example, if your app helps users read content, search for information, and listen to audio, it should accept remote control events only while the user is in the audio context. When the user leaves the audio context, you should relinquish the ability to receive the events. If your app lets users play audio or video on an AirPlay-enabled device, it should accept remote control events for the duration of media playback. Following these guidelines allows users to consume a different app’s media—and control it with headset controls—when they’re in the nonmedia contexts of your app.

As much as possible, use system-provided controls to offer AirPlay support. When you use the MPMoviePlayerController class to enable AirPlay playback, you can take advantage of a standard control that allows users to choose an AirPlay-enabled device that is currently in range. Or you can use the MPVolumeView class to display AirPlay-enabled audio or video devices from which users can choose. Users are accustomed to the appearance and behavior of these standard controls, so they’ll know how to use them in your app.

Don’t repurpose an event, even if the event has no meaning in your app. Users expect the iOS media controls and accessory controls to function consistently in all apps. You do not have to handle the events that your app 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 app.