Audio Apps That Survive Calls, Unplugged Headphones, and Other Apps Taking Over

Handle route changes

Unplug your headphones and have audio keep blasting from the speaker — Apple's Human Interface Guidelines explicitly call this out as behavior to avoid. Subscribe to AVAudioSession.routeChangeNotification and pause when the output route is lost.

func observeRouteChanges() {
    NotificationCenter.default.addObserver(
        self, selector: #selector(handleRouteChange),
        name: AVAudioSession.routeChangeNotification, object: nil)
}
 
@objc private func handleRouteChange(_ note: Notification) {
    guard let info = note.userInfo,
          let raw = info[AVAudioSessionRouteChangeReasonKey] as? UInt,
          let reason = AVAudioSession.RouteChangeReason(rawValue: raw) else { return }
 
    switch reason {
    case .oldDeviceUnavailable:
        // Headphones or Bluetooth device removed. Pause before it falls to the speaker.
        DispatchQueue.main.async { self.player.pause() }
    default:
        break
    }
}

.oldDeviceUnavailable means "the output you were just using is gone," and it fires the instant you unplug headphones. By contrast, simply plugging in a new device yields a different reason code, so you do not pause there. Pausing uniformly without checking the reason creates the inconvenience of stopping unintentionally the moment the user switches to Bluetooth.

Connect Now Playing and remote commands

An app that plays in the background is only production-grade once it can be controlled from the lock screen and Control Center. Receive actions with MPRemoteCommandCenter and hand display info to MPNowPlayingInfoCenter.

import MediaPlayer
 
func setupRemoteCommands() {
    let center = MPRemoteCommandCenter.shared()
 
    center.playCommand.addTarget { [weak self] _ in
        self?.player.play()
        return .success
    }
    center.pauseCommand.addTarget { [weak self] _ in
        self?.player.pause()
        return .success
    }
}
 
func updateNowPlaying(title: String, elapsed: TimeInterval, duration: TimeInterval) {
    var info = [String: Any]()
    info[MPMediaItemPropertyTitle] = title
    info[MPMediaItemPropertyPlaybackDuration] = duration
    info[MPNowPlayingInfoPropertyElapsedPlaybackTime] = elapsed
    info[MPNowPlayingInfoPropertyPlaybackRate] = player.isPlaying ? 1.0 : 0.0
    MPNowPlayingInfoCenter.default().nowPlayingInfo = info
}

Whenever an interruption or route change alters playback state, remember to call updateNowPlaying to refresh PlaybackRate. Skip it and you get a mismatch: paused inside the app but shown as playing on the lock screen. The "button frozen in playing state" bug I hit earlier was, at root, the same state inconsistency.

Enable background playback and test

Finally, enable Background Modes → Audio in Capabilities so sound keeps playing in the background. Projects generated by Rork Max sometimes lack this setting, so check it. Without it, audio stops the moment the screen closes.

Test on a real device by running through this sequence once: place and hang up a call to your own number during playback, unplug headphones during playback, open another music app during playback, and trigger Siri during playback. After each, confirm the three — sound, screen, and lock screen — do not disagree.

The order to fold this into an existing app

When retrofitting interruption handling, I find this order safest.

1. Call the audio session category setup exactly once, right at launch
2. Initialize the interruption, route-change, and remote-command subscriptions together
3. Run one real-device pass through call, headphone, and other-app interruptions to crush the combinations that occur in production

The caution is not to re-register subscriptions on every screen appearance. In my own case, adding the subscription inside a view's onAppear registered the notification handler multiple times, and a single interruption fired play and pause twice. I recommend enforcing a single subscription in one place as the fix.

I believe the polish of an audio app concentrates in how it answers these interruptions. It is quieter work than adding features, but tend to it carefully and users receive an impression of "a well-made app" without ever putting it into words. I hope this helps anyone working on the same problem.