Our app stops playing wkwebview-driven audio when the app is put in the background. This severely limits the podcast-playing experience.
This issue has been open for a long time with no word from Apple. We should move to native audio.
I propose that we play audio natively when the web app behavior triggers it.
This means either injecting the JavaScript that listens for the web audio actions from the app side of things, or initialize the behavior from the web app side similar to what we do with sendHapticMessage which triggers vibrations.
While it's kind of annoying that webview audio just doesn't work as it should (and did in past iOS versions), this is a chance to bolster our audio playback in the long run. Audio is an area where native control may be something we want to lean in soon to provide the best overall mobile experience.
This is sort of a bug report and feature request....
Per this discussion: https://forums.developer.apple.com/thread/121822
Our app stops playing
wkwebview-driven audio when the app is put in the background. This severely limits the podcast-playing experience.This issue has been open for a long time with no word from Apple. We should move to native audio.
I propose that we play audio natively when the web app behavior triggers it.
This means either injecting the JavaScript that listens for the web audio actions from the app side of things, or initialize the behavior from the web app side similar to what we do with
sendHapticMessagewhich triggers vibrations.While it's kind of annoying that webview audio just doesn't work as it should (and did in past iOS versions), this is a chance to bolster our audio playback in the long run. Audio is an area where native control may be something we want to lean in soon to provide the best overall mobile experience.