iPhone and iPad can play audio through internal or external speakers, headphones, and wirelessly through Bluetooth or AirPlay-enabled devices. People use several types of controls to manipulate sound on their devices, including volume buttons, the Ring/Silent switch, headphone controls, the Control Center volume slider, and sound controls in third-party accessories. Whether sound is a primary part of your app’s experience or an embellishment, you need to meet people’s expectations for how your app’s sound should behave.


People switch their device to silent when they want to avoid being interrupted by unexpected sounds like ringtones and incoming message tones. In this scenario, they also want to silence nonessential sounds, such as keyboard clicks, sound effects, game soundtracks, and other audible feedback. When a device is in silent mode, it should play only the audio that people explicitly initiate, like media playback, alarms, and audio/video messaging.


People expect their volume settings to affect all sound in the system — including music and in-app sound effects — regardless of the method they use to adjust the volume. The exception is the ringer volume, which people can adjust separately in Settings.


People use headphones to keep their listening private 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 — don’t adjust the overall volume. Your app can adjust relative, independent volume levels to achieve a great mix of audio, but the system volume should always govern the final output.

Permit rerouting of audio when possible. 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 let people make audio adjustments. The volume view includes a volume-level slider and a control for rerouting audio output. You can customize the appearance of the slider. For developer guidance, see MPVolumeView.

Use the system’s sound services to play short sounds and vibrations. For developer guidance, see Audio Services.

Choose an audio category that fits the way your app uses sound. Depending on the audio category you choose, your app’s sounds can mix with other audio, play while your app is in the background, or stop when people set the Ring/Silent switch to silent. As much as possible, pick a category that helps your app meet people’s expectations. For example, don’t make people stop listening to music from another app if you don’t need to. For developer guidance, see AVAudioSession.Category.

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.

When an interruption ends, determine whether to resume audio playback automatically. Sometimes, audio from a different app can interrupt the audio your app is playing. An interruption can be resumable — like an incoming phone call — or nonresumable, like when people start a new music playlist. Use the interruption type and your app’s type to decide whether to resume playback automatically. For example, a media playback app that’s actively playing audio when an interruption occurs should check to be sure the type is resumable before continuing playback when the interruption ends. On the other hand, an app like a game doesn’t need to check the interruption type before automatically resuming playback, because a game plays audio without an explicit user choice. For developer guidance, see shouldResume.

Ensure your VoIP app responds correctly to audio-session interruptions. In particular, it’s crucial to end a call when people close the Smart Folio of their iPad while they’re using the built-in microphone. Closing the Smart Folio automatically mutes the iPad microphone and by default interrupts the audio session associated with it. If you restart the audio session when people reopen their Smart Folio, you risk invading their privacy by reenabling the microphone without their knowledge. You can inspect an audio-session interruption to help determine the right way to respond; for developer guidance, see Responding to Audio Session Interruptions.

Let other apps know when your app finishes playing temporary audio. If your app can temporarily interrupt the audio of other apps, be sure to flag your audio session in a way that lets other apps know when they can resume. For developer guidance, see notifyOthersOnDeactivation.

Respond to audio controls only when it makes sense. People can control audio playback from outside 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 a Bluetooth or AirPlay-enabled device, it’s fine to respond to audio controls. Otherwise, when people activate a control, your app shouldn’t halt another app’s audio that’s currently playing.

Don’t repurpose audio controls. People expect audio controls to behave consistently in all apps so you should never redefine the meaning of an audio control in your app. If your app doesn’t support certain controls, simply don’t respond to them.