We are developing an iOS app that plays individual prerecorded spoken-audio files in response to background triggers. The user explicitly enables this functionality while the app is in the foreground. Subsequently, playback may need to start while the app is backgrounded or the device is locked, with silent intervals between files. For this question, please assume that the app is legitimately executing in the background when a trigger arrives. We are not asking how to wake a suspended app or keep it running artificially. Desired behavior Temporarily interrupt other media playback while an audio file is playing. Release the audio session afterwards, allowing the other app to resume. Repeat this for subsequent triggers without requiring foreground interaction. We do not need to override phone calls, Siri, or other higher-priority system audio. Current configuration try session.setCategory( .playback, mode: .voicePrompt, options: [.duckOthers, .interruptSpokenAudioAndMixWithOthers] ) try session.setActive(true) After playback finishes: try session.setActive( false, options: .notifyOthersOnDeactivation ) This provides ducking for other music playback. However, we would prefer non-mixing playback during each file. We are considering .playback with .spokenAudio and no mixing options, but Apple's documentation describes cannotInterruptOthers when attempting to activate a non-mixable session from the background. Questions Is there a supported audio-session lifecycle that allows this intermittent, non-mixing background playback after the user initially enables the feature in the foreground? If we deactivate the session between files, does the background activation restriction apply again to every subsequent file, regardless of the earlier user interaction? Does implementing a CarPlay audio app with the appropriate entitlement change these restrictions? In particular, is there a distinction between playback explicitly initiated through the CarPlay interface and later background-triggered playback? If this behavior is not supported, is ducking/mixing the recommended approach for this use case? We want to use public APIs and avoid silent playback or retaining an active audio session solely to prevent other apps from playing. Any clarification on the intended behavior and recommended configuration would be appreciated. Thank you for your time and guidance! regards, Carsten :-)