From 439fa6865722d4dbafd7fec40c2cf7cd4d5fab4c Mon Sep 17 00:00:00 2001 From: chevron7 Date: Tue, 12 May 2026 13:23:48 -0500 Subject: [PATCH] fix(ios): bridge audio element through AudioContext to survive backgrounding iOS WKWebView suspends the HTMLAudioElement's audio session when a standalone PWA is backgrounded (WebKit #261858). MediaSession reports "playing" but no sound. Routing the element through an AudioContext holds the iOS audio session more durably and survives backgrounding. Bridge is set up lazily on the first user-gesture play and only when the user-agent is iOS AND display-mode is standalone (i.e. the only case where the suspension bug applies). Desktop, Android, and iOS Safari tabs keep the bare-element path. --- frontend/lib/audio-controller.ts | 56 ++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/frontend/lib/audio-controller.ts b/frontend/lib/audio-controller.ts index aac869d..5e72062 100644 --- a/frontend/lib/audio-controller.ts +++ b/frontend/lib/audio-controller.ts @@ -55,6 +55,16 @@ export class AudioController { // Route-change observability: track time of last play to compute ms-since-play on pause. private lastPlayAt = 0; + // iOS standalone PWA audio session bridge. iOS WKWebView suspends the + // HTMLAudioElement's audio session when backgrounded; MediaSession reports + // "playing" but no sound. Routing the element through an AudioContext + // keeps the iOS audio session active across backgrounding because the + // AudioContext claims it more durably than a bare