---
title: "Audio interruptions during a workout on iOS: calls, Siri and the cue that never comes back"
canonical: "https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios"
cluster: "Audio Coaching"
primary_query: "avaudiosession interruption workout app"
last_reviewed: "2026-10-03"
description: "interruptionNotification, shouldResume, the WasSuspended key and iOS 27's lifecycle notifications, mapped to what a workout's cues and clock should do."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Audio interruptions during a workout on iOS: calls, Siri and the cue that never comes back\", AIFitnessAPI, https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios"
---

# Audio interruptions during a workout on iOS: calls, Siri and the cue that never comes back

> An interruption deactivates your audio session underneath you: Apple documents that when interruptionNotification arrives with the began type, the system interrupted your session and it's no longer active, and that the ended type carries options in which shouldResume is a hint that it's appropriate to resume without waiting for user input. In iOS 27 Apple added lifecycle notifications, didBecomeInactiveNotification and resumptionRecommendationNotification, and recommends them for new code because they don't get out of sync when the system can't deliver an end event; for iOS 26 and earlier you still observe interruptionNotification. For a workout the audio and the clock are separate decisions: suspend speech during the interruption, keep the workout timer running, and never replay a cue whose moment passed during a call.

- Canonical: https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios
- Last reviewed: 2026-10-03
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Audio interruptions during a workout on iOS: calls, Siri and the cue that never comes back", AIFitnessAPI, https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios

---

A workout is long enough that something will interrupt it: a phone call, an alarm, Siri, another app starting its own audio. When that happens your audio session is deactivated underneath you. The bugs come afterwards: cues that never return, a stale cue that fires the moment the call ends, or a workout clock that stopped because it was tied to audio that stopped.

This page covers the iOS interruption notifications, including the lifecycle notifications Apple added in iOS 27, and how a workout app should treat each case. Headphones being unplugged is a route change, not an interruption, and has [its own page](/audio-coaching/headphones-disconnect-route-change).

## What an interruption is

Apple's [Handling audio interruptions](https://developer.apple.com/documentation/avfaudio/handling-audio-interruptions) article opens with the canonical case: "consider the scenario of receiving a phone call while you're watching a movie in the TV app on your iPhone. In this case, the movie's audio fades out, playback pauses, and the sound of the call's ringtone fades in. If you decline the call, control returns to the TV app, and playback begins again as the movie's audio fades in."

The article notes that `AVPlayer` "monitors your app's audio session and automatically pauses playback in response to interruption events." A workout app speaking through `AVSpeechSynthesizer` or `AVAudioPlayer` does not get that behaviour for its cue schedule. The schedule is yours to pause and resume.

## The legacy notification: interruptionNotification

For apps deploying to iOS 26 and earlier, Apple's article says to "observe interruptionNotification directly." The [`interruptionNotification`](https://developer.apple.com/documentation/avfaudio/avaudiosession/interruptionnotification) page: "If the interruption type is AVAudioSession.InterruptionType.began, the system interrupted your app's audio session and it's no longer active. If the interruption type is AVAudioSession.InterruptionType.ended, this dictionary also contains the AVAudioSessionInterruptionOptionKey key." Apple adds: "The system posts this notification on the main thread."

```swift
func handleInterruption(_ notification: Notification) {
    guard let info = notification.userInfo,
          let raw = info[AVAudioSessionInterruptionTypeKey] as? UInt,
          let type = AVAudioSession.InterruptionType(rawValue: raw) else { return }

    switch type {
    case .began:
        cueScheduler.suspendSpeech()          // the workout clock keeps running
    case .ended:
        let opts = (info[AVAudioSessionInterruptionOptionKey] as? UInt)
            .map(AVAudioSession.InterruptionOptions.init(rawValue:)) ?? []
        if opts.contains(.shouldResume) { cueScheduler.resumeSpeech() }
    @unknown default:
        break
    }
}
```

The ended case carries [`shouldResume`](https://developer.apple.com/documentation/avfaudio/avaudiosession/interruptionoptions/shouldresume), which Apple describes as "a hint that it's appropriate for your app to resume audio playback without waiting for user input." Apple adds that apps "that don't require user input to begin audio playback (such as games) can ignore this flag and resume playback when an interruption ends."

Apple's [Playing audio guidelines](https://developer.apple.com/design/human-interface-guidelines/playing-audio) give the distinction behind the flag: "An interruption can be resumable, like an incoming phone call, or nonresumable, like when people start a new music playlist."

## The interruption that arrives late

One note on Apple's notification page explains a confusing report: an interruption notification arriving when the app comes back, long after anything happened. "Starting in iOS 10, the system deactivates an app's audio session when it suspends the app process. When the app starts running again, it receives an interruption notification that the system has deactivated its audio session. This notification is necessarily delayed in time because the system can only deliver it once the app is running again."

In that case the dictionary "contains the AVAudioSessionInterruptionWasSuspendedKey key with a value of true." Apple's advice is aimed at nonmixable sessions: "If you configured your audio session to be nonmixable (the default behavior for the playback, playAndRecord, soloAmbient, and multiRoute categories), deactivate your audio session if you're not actively using audio when you go into the background."

For a workout app this key is diagnostic. If you see it during a session the user thinks is live, the process was suspended mid-workout. That is a [background audio](/audio-coaching/background-audio-workout-app-ios) problem, not an interruption-handling one.

## iOS 27: lifecycle notifications

Apple's article now leads with a different model: "In iOS 27, tvOS 27, visionOS 27, and watchOS 27 and later, AVAudioSession posts a set of life-cycle notifications that model interruptions as deactivation and resumption events rather than as begin and end signals. Adopt these notifications for new code because they represent the interrupted-versus-active state directly and don't get out of sync when the system can't deliver an end event."

| Notification (iOS 27.0) | Apple's description | User info |
| --- | --- | --- |
| [`didBecomeActiveNotification`](https://developer.apple.com/documentation/avfaudio/avaudiosession/didbecomeactivenotification) | Sent when the session becomes active | none |
| [`didBecomeInactiveNotification`](https://developer.apple.com/documentation/avfaudio/avaudiosession/didbecomeinactivenotification) | Sent when the session becomes inactive | `AVAudioSession.DeactivationContext` under `deactivationContextKey` |
| [`resumptionRecommendationNotification`](https://developer.apple.com/documentation/avfaudio/avaudiosession/resumptionrecommendationnotification) | Sent when the system suggests whether to resume after an interruption ends | `AVAudioSession.ResumptionContext` under `resumptionContextKey` |

The deactivation context's `source` says "whether your app or the system initiated the deactivation," and when the system did, `interruptionContext` describes it. That matters for a cue app more than most: you deactivate your own session after every cue to give the user's music back, so you will receive `didBecomeInactiveNotification` constantly for your own deactivations. Filter on the source, or your cue scheduler will treat every finished cue as an interruption.

The resumption context's `recommendation` is `.shouldResume` or `.shouldNotResume`. Apple: "Unlike the legacy interruption notification, resumptionRecommendationNotification isn't tied to the interrupting app's end-of-interruption signal, so your app doesn't stay stuck in an interrupted state if that signal never arrives." Apple also writes that "In later releases, the system deprecates" the legacy notification, its keys and enumerations. Our reading: if you support iOS 26 and earlier, observe both and route them to the same handler.

## Calls: banner or full screen

Apple documents a preference that changes whether a call interrupts you at all. [`setPrefersNoInterruptionsFromSystemAlerts(_:)`](https://developer.apple.com/documentation/avfaudio/avaudiosession/setprefersnointerruptionsfromsystemalerts(_:)): "Beginning in iOS 14, users can set a global preference that indicates whether the system displays incoming calls using a banner or a full-screen display style. If using the banner style, setting this value to true prevents the system from interrupting the audio session with incoming call notifications, and gives the user an opportunity to accept or decline the call. The system only interrupts the audio session if the user accepts the call."

Marked important: "This preference has no effect if the device uses the full-screen display style—the system interrupts the audio session on incoming calls." Apple's examples of where it helps are apps "that record audiovisual media or that you use for music performance." Our judgement: for a workout app that only speaks short cues, it is a small gain. Whichever way you set it, test both call display styles, because they behave differently by design.

## When the whole media server restarts

Rare, but documented. [`mediaServicesWereResetNotification`](https://developer.apple.com/documentation/avfaudio/avaudiosession/mediaserviceswereresetnotification): "Under rare circumstances, the system terminates and restarts its media services daemon. Respond to these events by reinitializing your app's audio objects (such as players, recorders, converters, or audio queues) and resetting your audio session's category, options, and mode configuration. Your app shouldn't restart its media playback, recording, or processing until initiated by user action." Apple notes you "don't need to reregister for any audio session notifications."

That last sentence is about media playback. A workout's cue schedule is closer to a timer than to playback; our judgement is to rebuild the audio objects silently and let the next scheduled cue play. Apple gives a way to test it, covered on [the testing page](/audio-coaching/testing-workout-audio-cues).

## What a workout should do with each case

The right column is our judgement. The middle column is what Apple documents.

| Event | What Apple documents | What the workout should do |
| --- | --- | --- |
| Incoming call, accepted | Session interrupted, no longer active | Keep the workout clock running; suspend speech; show the cue visually |
| Call ends with `shouldResume` | A hint it is appropriate to resume without user input | Resume the schedule from the current time; do not replay the cue that was cut off |
| Call ends without `shouldResume` | Do not resume automatically | Stay silent until the next user action or the next cue boundary |
| Another app starts its own playlist | Nonresumable interruption | Treat cues as off until the user returns to the app |
| `WasSuspended` key is true | Session was deactivated when the process was suspended | Treat it as a background-execution bug and investigate |
| Media services reset | Rebuild audio objects, reset category, options and mode | Rebuild silently; carry on at the next cue |

The commonest mistake in that table is the second row: replaying the cue that was interrupted. "Ten seconds left" replayed after a two-minute call is wrong. Cues are tied to workout time, not to a playlist position.

## Monday morning

Find your interruption handler, or confirm you do not have one. Make sure it suspends speech without stopping the workout clock, that a resumed schedule recomputes the next cue from elapsed time, and that no stale cue replays. If you target iOS 27, observe the lifecycle notifications and filter out your own deactivations by source. Then take a real call mid-interval, once with each call display style.

## Sources

- [developer.apple.com/documentation/avfaudio/handling-audio-interruptions](https://developer.apple.com/documentation/avfaudio/handling-audio-interruptions) — interruption model, iOS 27 lifecycle notifications, legacy handling (checked 2026-10-03)
- [developer.apple.com/documentation/avfaudio/avaudiosession/interruptionnotification](https://developer.apple.com/documentation/avfaudio/avaudiosession/interruptionnotification) — began and ended; main thread; WasSuspended key (checked 2026-10-03)
- [developer.apple.com/documentation/avfaudio/avaudiosession/interruptionoptions/shouldresume](https://developer.apple.com/documentation/avfaudio/avaudiosession/interruptionoptions/shouldresume) — resume hint (checked 2026-10-03)
- [developer.apple.com/documentation/avfaudio/avaudiosession/setprefersnointerruptionsfromsystemalerts(_:)](https://developer.apple.com/documentation/avfaudio/avaudiosession/setprefersnointerruptionsfromsystemalerts%28_:%29) — banner versus full-screen calls (checked 2026-10-03)
- [developer.apple.com/documentation/avfaudio/avaudiosession/mediaserviceswereresetnotification](https://developer.apple.com/documentation/avfaudio/avaudiosession/mediaserviceswereresetnotification) — media server reset handling (checked 2026-10-03)

## FAQ

### Why does my app never get an interruption ended notification after a call?

Because the end signal is not guaranteed. Apple's Handling audio interruptions article says the iOS 27 lifecycle notifications exist precisely because they don't get out of sync when the system can't deliver an end event, and that resumptionRecommendationNotification isn't tied to the interrupting app's end-of-interruption signal, so your app doesn't stay stuck in an interrupted state if that signal never arrives. On iOS 26 and earlier, design the cue scheduler so the next scheduled cue, or the next user action, recovers the session even if no ended notification ever comes.

[Permalink](https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios#faq-1)

### Should a workout app automatically resume voice cues after a phone call ends?

Resume the schedule, not the interrupted cue. Apple documents shouldResume as a hint that it's appropriate to resume audio playback without waiting for user input, and its design guidance distinguishes resumable interruptions, like a phone call, from nonresumable ones, like the user starting a new playlist. Our judgement for a workout is to resume speaking at the next cue boundary computed from elapsed workout time, and to drop any cue whose moment passed during the call. A ten-seconds-left cue replayed after a two-minute call is simply wrong.

[Permalink](https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios#faq-2)

### What does AVAudioSessionInterruptionWasSuspendedKey mean in a workout app?

That your process was suspended and the session was deactivated while it was asleep. Apple documents that starting in iOS 10 the system deactivates an app's audio session when it suspends the app, and delivers an interruption notification, necessarily delayed, once the app runs again, with this key set to true. If you see it during a workout the user believes is live, the problem is background execution rather than interruption handling, and the background audio configuration is the first thing to check.

[Permalink](https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios#faq-3)

### Can I stop incoming calls from interrupting my app's workout audio?

Partly, and only for one call style. Apple documents setPrefersNoInterruptionsFromSystemAlerts: if the user has chosen the banner style for incoming calls, setting it to true prevents the system interrupting your session for the call notification, and the session is interrupted only if the user accepts the call. Apple marks it important that the preference has no effect with the full-screen style, where the system interrupts the session on incoming calls. Test both styles, because they behave differently by design.

[Permalink](https://aifitnessapi.com/audio-coaching/audio-interruptions-during-workout-ios#faq-4)