People manipulate sound through the volume buttons, silence switch, headphone controls, and the onscreen volume slider. Many third-party accessories include sound controls too. Audio can be output through internal or external speakers, headphones, and even wirelessly through an AirPlay-enabled or Bluetooth device. Whether sound is a primary aspect of your app’s experience or an embellishment, you need to know how people expect sound to behave and meet those expectations.


People switch their device to silent to avoid being interrupted by unexpected sounds, such as ringtones and incoming message sounds. They also want nonessential sounds disabled, including keyboard sounds, sound effects, game soundtracks, and other audible feedback. When the device is set to silent, only explicitly initiated sounds should occur, such as audio during media playback, alarms, and audio/video messaging.


Whether using physical device buttons or an onscreen slider, people expect changes in volume to affect all sound systemwide, including music and in-app sound effects. The only exception is the ringer volume, which is always adjusted separately when audio isn’t actively playing.


People use headphones to hear sound privately and to free their hands. When plugging in headphones, users expect sound to reroute automatically without interruption. When unplugging headphones, they expect playback to pause immediately.

Designing a Great Audio Experience

Adjust levels automatically when necessary, but not the overall volume. Your app can adjust relative, independent volume levels to achieve a great mix of audio. However, the final output should always be governed by the system volume.

Permit rerouting of audio when appropriate. People often want to select a different audio output device. For example, they may want to listen to music through their living room stereo, car radio, or Apple TV. Support this capability unless there’s a compelling reason not to.

Use the system-provided volume view to allow audio adjustments. The best way to provide interface controls for adjusting audio is to use a volume view. This view is customizable, includes a volume-level slider, and even includes a control for rerouting audio output. For developer guidance, see MPVolumeView.

Use the system’s sound services for short sounds and vibrations. For developer guidance, see System Sound Services.

Categorize your audio if sound is essential to your app. Different audio categories allow sounds to be silenced by the silence switch, to mix with other audio, or to play while your app is in the background. Pick a category based on its meaning and the current audio state of the device, and assign it to your audio sessions. For example, don’t make people stop listening to music from another app if you don’t need to. In general, it’s best to avoid changing the category while your app is running, with the exception of apps that record and play back audio at different times. For developer guidance, see Audio Session Programming Guide.

Category Meaning Behavior
Solo ambient Sound isn’t essential, but it silences other audio. For example, a game with a soundtrack. Responds to the silence switch.
Doesn’t mix with other sounds.
Doesn’t play in the background.
Ambient Sound isn’t essential, and it doesn’t silence other audio. For example, a game that lets people play music from another app during gameplay in place of the game’s soundtrack. Responds to the silence switch.
Mixes with other sounds.
Doesn’t play in the background.
Playback Sound is essential and might mix with other audio. For example, an audiobook or educational app that teaches a foreign language, which people might want to listen to after leaving the app. Doesn’t respond to the silence switch.
May or may not mix with other sounds.
Can play in the background.
Record Sound is recorded. For example, a note-taking app that offers an audio recording mode. An app of this nature might switch its category to playback if it lets people play the recorded notes. Doesn’t respond to the silence switch.
Doesn’t mix with other sounds.
Can record in the background.
Play and record Sound is recorded and played, potentially simultaneously. For example, an audio messaging or video calling app. Doesn’t respond to the silence switch.
May or may not mix with other sounds.
Can record and play in the background.

Resume audio playback when appropriate after an interruption occurs. Sometimes, currently playing audio is interrupted by audio from a different app. Temporary interruptions such as incoming phone calls are considered resumable. Permanent interruptions, such as a music playlist initiated by Siri, are considered nonresumable. When a resumable interruption occurs, your app should resume playback when the interruption ends if audio was actively playing when the interruption started. For example, a game playing a soundtrack and a media app in the process of playing audio should both resume.

Let other apps know when your app finishes playing temporary audio. If your app might temporarily interrupt the audio of other apps, it should flag audio sessions appropriately so other apps get notified when it’s safe to resume. For developer guidance, see the AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation constant in AVFoundation.

Respond to audio controls only when it makes sense. People can control audio playback from outside of your app’s interface, such as in Control Center or with controls on their headphones, regardless of whether your app is in the foreground or background. If your app is actively playing audio, in a clear audio-related context, or connected to an AirPlay-enabled device, it’s fine to respond to audio controls. Otherwise, your app shouldn't halt another app’s audio that may be playing when a control is activated.

Don’t repurpose audio controls. People expect audio controls to behave consistently in all apps. Never redefine the meaning of an audio control. If your app doesn’t support certain controls, then it simply shouldn’t respond to them.