Bug 291892 – WebAudio AudioContext silent after PWA returns from background, even after resuming it

• Component: Web Audio
• Status: NEW

[Alex Suzuki]

I maintain a JavaScript library that uses WebAudio to emit a beep when a certain event happens.
Some of my users have reported that when a Home Screen app (PWA) uses the library, the beeping "sometimes" stops to work when the app returns to foreground after being previously backgrounded.

I've seen two potentially related issues on the internet, with both sources claim that calling .resume() on the AudioContext after returning from background (detected by document.visibility state changing to 'visible') helps alleviate the issue:
Howler.js issue: https://github.com/goldfire/howler.js/issues/862#issuecomment-2183054186
Similar WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=276687

However they do not mention Home Screen apps specifically, and I've been able to reproduce the issue with a minimal test PWA multiple times:
URL: https://suzukieng.github.io/wa-pwa/
Source: https://github.com/suzukieng/wa-pwa

Reproduction steps:
1) Open URL, Add To Home Screen
2) Press "Play Beep" -> Beep sound should play, AudioContext state is running
3) Send app to background, do something else for a while, lock phone etc.
4) Return to app. If AudioContext state is not 'running', press "Resume Context".
5) Press "Play Beep" again -> occasionally, this will not emit any audio, and remain silent.

Unfortunately, the reproduction only triggers the issue occasionally (I'd say maybe one in ten times), and I don't know of a more precise sequence of events to trigger it.

All interactions in the reproducer happen in the context of a user event, so activation requirements should not be an issue here.

What I've also occasionally observed, is that a previously scheduled sound will suddenly play "out of order", when the context is resumed.

I'd hate to do it, but at this point I'm considering adding an HTML5 AudioElement fallback if running on iOS in PWA mode.

[Alex Suzuki]

Further comments:
- Sometimes the AudioContext is in 'running' state after the page becomes visible again, yet playing a sound will remain silent
- Playing a sound over an HTML5 AudioElement seems to work reliably in this scenario, even if the AudioContext is silent

[Radar WebKit Bug Importer]

<rdar://problem/150267305>

I have similar issue on Mac. 

Environment:
Browser: Safari 18.5 (20621.2.5.11.8)
Operating System: macOS 15.5

Issue Description:
Audio plays normally when triggered by user clicks upon page load.
After playing one audio segment and waiting for some time, subsequent attempts to play audio result in a silent AudioContext (no audio output).
AudioContext.state remains running, and AudioSource ended callback triggers normally.
Refreshing the page (including clearing cache) or restoring tabs (cmd + shift + t) does not help
Opening the page in a new tab allows audio to play normally.

Code Details:
A new AudioContext is created on each page load.
Only AudioSource nodes are used; no other nodes (e.g., GainNode, AnalyserNode).
Audio files are fetched via fetch (format not specified, assumed MP3 or WAV).
AudioSource is properly cleaned up before each playback (stop, remove event listeners, disconnect).
Audio playback is triggered by user clicks.

Attempted Exclusions:
User interaction restrictions (click-triggered).
AudioContext suspension (resume ineffective).
AudioSource resource leaks (proper cleanup).
AudioContext creation issues (newly created on page load, manual reset ineffective).
Browser cache or tab state (cache clearing and tab restoration ineffective).

[Mariano Goni]

On iOS 26 beta 2, after added to home screen, works the first time, but not next times, no matter what you do.  
The only way to make it work again is erasing Safari cache.

I can confirm that on my iPhone 13 Pro running iOS 26 (public release), any webpage added to the home screen as a PWA will only work with Web Audio on the first run. For me, this happens 100% of the time and affects any webpage attempting to call AudioContext.resume() from the suspended state — the function never returns. Note that resume() was invoked from within a click event.

I have tried numerous ways to revive the audio context, but without success. Terminating the app completely and reopening it also has no effect. The only solution I found was to delete the app from the home screen, though I suspect clearing Safari’s cache may also work.

Steps to reproduce:
1) Open https://webaudioapi.com/samples/visualizer/
2) Add the page to your home screen with the Open as Web App option enabled
3) Launch the page from the home screen
4) Tap Click to Play — this calls AudioContext.resume()
5) Tap Play/Pause and confirm that audio plays correctly
6) Swipe up to terminate the app, or simply minimize it
7) Relaunch the page from the home screen
8) Tap Click to Play and notice that the app hangs without removing the button — this is resume() stalling

Even if you bypass the suspended state and attempt to play audio directly, you will hear nothing.
Unfortunately, this issue is severe enough to prevent any Web Audio API use in a PWA on iOS.

[Alex Suzuki]

On iOS 26, it seems even the regular <audio> element is broken in PWAs?

The reproducer for this ticket has a 'HTML5 Fallback Beep' button which creates a new audio element (new Audio(...)) and invokes .play() on it, which succeeds, but there's just silence.
URL: https://suzukieng.github.io/wa-pwa/

This is on an iPhone 12, running iOS 26.0 (23A340).

[Peter Woods]

I've just updated my iPhone 16 to iOS 26.2 Beta 3 (23C5044b) and the issue appears to have been fixed !