Background audio for an iPhone workout app: UIBackgroundModes audio, and what it does not promise

A cue that plays in the simulator and dies on the first locked-phone run has usually failed one of two separate switches. One is the audio session category, which decides whether audio continues when the screen locks. The other is a background execution mode, which decides whether the app is allowed to keep playing once it is in the background. Apple documents both, and a workout app needs both.

This page covers the iPhone side, says plainly what Apple's pages do not promise, and points to the different rules on Apple Watch.

Switch one: a category that survives the lock#

Apple's playback category page says audio "continues with the Silent switch set to silent or when the screen locks," then names the second switch in the same breath: "To continue playing audio when your app transitions to the background (for example, when the screen locks), add the audio value to the UIBackgroundModes key in your information property list file."

The default category and ambient are both, in Apple's words, silenced by screen locking, so no background mode rescues them. Picking the category is its own page.

Switch two: UIBackgroundModes audio#

Apple's UIBackgroundModes key covers "Services provided by an app that require it to run in the background," and Apple says to add it by enabling "the Background Modes capability in Xcode."

Apple's Configuring background execution modes article gives the steps: select the target, open Signing & Capabilities, find Background Modes, and tick the modes you need, after which "Xcode adds the UIBackgroundModes array to your app's Info.plist file, if it isn't already present." In its table the iPhone mode is called "Audio, AirPlay, and Picture in Picture," value audio, described as "The app plays audible content in the background." The result in Info.plist:

<key>UIBackgroundModes</key>
<array>
  <string>audio</string>
</array>

Apple's Configuring your app for media playback article joins the two switches: "With this mode enabled and your audio session configured, your app is ready to play background audio."

Use it sparingly, and for what it is for#

Apple's background-modes article is direct about cost: "Use background execution modes sparingly because overuse can negatively impact device performance and battery life. If an alternative to executing in the background exists, use the alternative instead."

The App Store Review Guidelines, last updated June 8, 2026 when we read them, say in guideline 2.5.4: "Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc." Store policy as a whole belongs to compliance; we quote the guideline only because it bears on this choice, and we make no prediction about any review outcome.

Our reading, as engineering guidance: a workout app that speaks coaching cues during a session is playing audio, which is what the mode is for. A run-tracking app that holds the location mode for GPS is using that mode for location. Declare each mode for the job it does, not one to cover the other.

What these pages do not promise#

Here precision matters more than reassurance. Apple's background-modes article says that for apps adopting these modes, "the system launches or resumes the app, in the background, and affords it time to process any related events." None of the pages we read for this cluster says whether an app with the audio mode keeps executing during the silent minutes between cues, when no audio is playing.

There is a hint in the other direction. Apple's interruptionNotification page notes: "Starting in iOS 10, the system deactivates an app's audio session when it suspends the app process," so a suspended process is a documented state for an audio app. We are not going to claim the mode keeps your timer alive, or that it does not. If your cue schedule depends on your code running at a precise moment with the screen locked, prove that on a device, with the screen off, for a full workout. Our HIIT app guide treats this as a scheduling problem and explains why.

Apple Watch is a different rulebook#

Apple's Running workout sessions article: "Workout sessions require the Workout processing background mode. If your app plays audio or provides haptic feedback during the workout session, you must also add the Audio background mode." And: "Workout apps can use the AVFoundation framework to play short audio clips in the background, such as coaching or notifications. In order to play an audio clip, an active workout session must be running; any attempt to play background audio outside a workout session are invalid."

So on the watch the session, not the background mode alone, is what makes background cues valid. The session lifecycle is covered in HKWorkoutSession lifecycle, and audio output on the wrist, speaker or Bluetooth, is on the watch audio page.

A checklist that catches both switches#

Monday morning#

Open Signing & Capabilities and confirm Background Modes is there with Audio ticked; open Info.plist and confirm audio is in the array. Confirm the category is set before the first cue. Then run a full workout on a device with the screen locked from the first minute, and log the wall-clock time each cue actually played against the time it was scheduled.