In March 2022, a Wikipedia developer filed WebKit bug #237322. The title was straightforward:
“webaudio api is muted when the iOS ringer is muted”
The description was less calm:
“This is HIGHLY confusing. I cannot count the amount of times where I have begun playback using webaudio and figured the webpage had broken, only to figure out that because I always have my phone set to Silent, the audio is muted.”
He wasn’t alone. This bug had been frustrating web developers for over a decade.
The problem
iOS has a hardware mute switch on the side of every iPhone. When it’s on, you’d expect everything to go silent. But that’s not what happens.
iOS actually splits audio into two invisible channels:
- Ambient: respects the mute switch. This is for notifications, keyboard clicks, game sound effects.
- Playback: ignores the mute switch. This is for music, podcasts, video.
Native app developers have always been able to choose which channel to use. One line of Swift:
AVAudioSession.sharedInstance().setCategory(.playback)Spotify, YouTube, Podcasts, every music app uses this. That’s why you can set your phone to silent and still listen to music. It’s been this way since iOS 3.
Web developers got no such choice.
The <audio> and <video> HTML elements play on the playback channel. Makes sense. But the Web Audio API, which uses AudioContext for low-latency, programmable audio, plays on the ambient channel. Mute switch kills it.
This meant any web app using the Web Audio API for games, music tools, interactive exercises, synthesizers, anything beyond a simple audio player, would go silent the moment someone had their iPhone on mute.
The quiet fix
On January 19, 2023, a WebKit commit appeared: c393587. The commit message:
“Enable AudioSession Web API by default, but only a reduced subset.”
It enabled navigator.audioSession and navigator.audioSession.type in WebKit. No blog post. No announcement. No mention in any Safari release notes.
Nine months later, Safari 17 shipped with iOS 17 in September 2023. The API was live.
The only public acknowledgment came from a WebKit engineer named Jean-Yves Avenard, who replied to that 2022 bug report:
“Since iOS 17, you can set the audio session type to ‘playback’. Add in your code something like
navigator.audioSession.type = 'playback'and audio will not be suspended.”
That was it. One comment on a bug tracker.
In November 2024, over a year after Safari shipped it, the W3C Media Working Group published the First Public Working Draft of the Audio Session API specification. Led by Youenn Fablet from Apple and Alastor Wu from Mozilla.
The fix
One line:
navigator.audioSession.type = 'playback';This tells iOS to route Web Audio API sounds through the playback channel, bypassing the mute switch. The same thing native apps have been doing since 2009 with AVAudioSession.
What bothers me
This fix has been available since September 2023. It’s now 2026. Most web developers still don’t know about it. The bug report is marked “RESOLVED CONFIGURATION CHANGED”, which is WebKit’s way of saying “we added an API, go use it.”
There was no migration guide. No deprecation of the old workarounds. No blog post on webkit.org explaining the change. The W3C spec draft came out over a year after Safari shipped the feature.
If you search “iOS web audio no sound” today, the top results are still the old <audio> element hack from 2018. The actual fix is buried in a bug tracker comment.
Native developers get WWDC sessions, migration guides, and deprecation warnings. Web developers get a commit hash and a one-line comment on a bug report.