Simple repro site at https://ios-standalone-bug.backgroundnoise.app 1. Write a web app that Includes an HTML <audio> element 2. Pin it to home screen on iOS with display:standalone in manifest.json 3. Launch the web app 4. Play the audio 5. Leave the web app Expected: Audio keeps playing Actual: Audio stops playing. NOTE: If you play the audio in Safari and leave Safari it keeps playing in the background. This only affects standalone web apps/PWAs
<rdar://problem/51202332>
I'm also having this problem on https://podcatcher.app/
Please get this on somebody's list. We have a very popular PWA with limited functionality on iOS 13 due to no background audio!
We use WKWebView in our app, and we also have this bug. I've looked sources for a little, and it seems that it is not actually a webkit bug, but something in iOS. Safari manages media via some complicated mechanisms, so it doesn't reproduces there.
Please get somebody to work on the fix for this issue, this bug blatantly prevents users to have the same experience as native app users.
Same Problem on my progressive Web app based on audio content. It was perfectly working with previous IOS. It's a huge step backwards for user experience.
This is a big problem for our PWA, as well.
I'm having this issue also we need to develop an only native app for Apple other support audio in the backgroung
I'm also having this problem on https://podcasts.ba-ba-bam.com/be-lively-lexperience-bien-etre/
Hi everyone, just a quick update: we have been investigating this issue but don’t yet have a solution. We understand that the current behavior blocks a lot of important use cases. But because the issues causing this behavior may be due to the underlying platform, investigation is being tracked inside Radar, rather than here on bugzilla. If we do identify a fix, we’ll ping this thread when that fix is available for testing. Thanks for your patience.
(In reply to Jer Noble from comment #10) It is wonderful to hear that this issue is being investigated! Thank you for your hard work. Is there a link to the bug report on Radar, so that I can track the progress?
Following some internal info trails, I believe this is a dupe of https://bugs.webkit.org/show_bug.cgi?id=205687 and thus resolved (but not yet in a release). I will confirm with an internal build before duping, and I’ll see what we can do about getting the fix in an update.
(In reply to Maciej Stachowiak from comment #12) > Following some internal info trails, I believe this is a dupe of > https://bugs.webkit.org/show_bug.cgi?id=205687 and thus resolved (but not > yet in a release). I will confirm with an internal build before duping, and > I’ll see what we can do about getting the fix in an update. Did you end up confirming that #205687 fixes this issue? I'm sure there are hundreds of engineers and many thousands of users who are eager to hear updates about whether this is fixed in an upcoming release. Thanks in advance, Brian.
(In reply to Maciej Stachowiak from comment #12) > Following some internal info trails, I believe this is a dupe of > https://bugs.webkit.org/show_bug.cgi?id=205687 and thus resolved (but not > yet in a release). I will confirm with an internal build before duping, and > I’ll see what we can do about getting the fix in an update. Hey have you found any fix for this? I have also been searching for months for a fix on this. Our app has many audios and all of them cannot be used inside our WKWebView 30 seconds after app goes into background/screen goes black, the audio cuts out. Would love to see a fix coming on this. Thank you!
(In reply to Maciej Stachowiak from comment #12) This is a big issue for our app (like numerous others). It would be great to know if this has been resolved, and, if so, when it will be released. Thank you for your efforts.
Hello, Big issue for us also. Could you confirm that the bug will be fix in the next update?
Hello, this is a big issue for our Progressive Web App as well, could you confirm if the bug is going to be fix during the next update ?
Maciej Stachowiak, following up here -- what is the latest status of this issue? It doesn't look like the alleged fix made it in 13.5, or at least if it has, it has not fixed this issue.
Apparently https://bugs.webkit.org/show_bug.cgi?id=205687 shipped in 13.5.1, and this issue (audio stops playing when standalone web app is no longer in foreground) was not fixed. So these are duplicates, and the issue remains unfixed.
After iOS 13.5.1 this does appear to still not be working. Any update on this in the near future? It seems to have been broken since September. Thank you!
Waiting for this fix for our PWA which has audio content
(In reply to Maciej Stachowiak from comment #12) > Following some internal info trails, I believe this is a dupe of > https://bugs.webkit.org/show_bug.cgi?id=205687 and thus resolved (but not > yet in a release). I will confirm with an internal build before duping, and > I’ll see what we can do about getting the fix in an update. Here I'm using the iOS 13.5.1 and audio stops playing when a standalone web app is no longer in the foreground or in lock screen. Any updates on this? Really thank you!!
This issue is very problematic for our company ... Any update about it :( ?
Hello, is this problem will be fix soon? Does someone have informations on it ? Thanks
Bump -- does anyone have any information on whether or not iOS 14 will bring support for this feature?
(In reply to Cass from comment #25) > Bump -- does anyone have any information on whether or not iOS 14 will bring > support for this feature? seems to be fixed in iOS 14 Beta 2
> seems to be fixed in iOS 14 Beta 2 I am using iOS 14 Beta 2 and this is not fixed for me (I'm following the repro steps exactly).
(In reply to Wes Peter from comment #27) > > seems to be fixed in iOS 14 Beta 2 > > I am using iOS 14 Beta 2 and this is not fixed for me (I'm following the > repro steps exactly). Indeed. Only fixed if web app is launched through a webview from a native app, not if it is directly installed from Safari.
Unfortunately, this is still not fixed in iPadOS 14 Beta 5, which basically renders our progressive web app useless :( Apple, please allow playing audio in the background for a standalone web app!
The same frustration here. Not fixed in Iphone and iPad 14 Beta. Anyone can help us? Reopening the bug and prioritize it in release?
+1 on the request that Apple support background play from PWAs.
Any news from the team on this issue? I know there are things that take longer than expected but it's been over a year and it seems like no one is giving any importance to this. I know that Apple doesn't have much love for PWA, but come on we are dealing with a basic need, sound. There are so many apps waiting for this around the world. I would love to have someone from the team give a little more detail, focus and love on this.
Any news about it? Not fixed in IOS 14 / iPadOS 14.
We are at +15 months and webkit still limits a normal use of the devices put on the market. This limitation has a monstrous impact on an entire ecosystem. I suspect that the decision is more political than technical (allowing background playback being a "risk" for the popularity of iTunes). A straightforward communication on this subject seems to me necessary.
We are here in same situation, Paul. Very stressful. Hope to see an official communication from developers/maintainers about this.
I will just echo Paul and Pedro's frustration, above. It feels like iOS is intentionally hobbling PWAs. I suppose this is just more reason to focus on the Android market.
I agree with Paul, Pedro and Jon. Our PWA has been crippled by this. We have waited over a year for a fix and it still doesnt seem to be on the radar. Would really appreciate a fix here.
Adding to the request to get this fixed! Music pwa just not running in background, makes it useless -> https://danreverse.com
I think Apple will sponsor the first marathon on Mars before someone answers us.
+1 but as this ticket has "Nobody" assigned to it, I don't think anyone is going to read this. Should we create a new ticket, maybe get some attention to it?
Thanks for further reporting this bug is not fixed. This bug is tracked internally, the required fix might not be at WebKit level.
Thanks for feedback! So, what is the next step to provide a solution/workaround for this? Open a ticket in another place?
(In reply to Pedro Furtado from comment #42) > Thanks for feedback! So, what is the next step to provide a > solution/workaround for this? Open a ticket in another place? A ticket was already created internally.
I want to echo Pedro Furtado's frustration at the seeming inaction on this issue. It would be really great to get a fix.
(In reply to youenn fablet from comment #43) > (In reply to Pedro Furtado from comment #42) > > Thanks for feedback! So, what is the next step to provide a > > solution/workaround for this? Open a ticket in another place? > > A ticket was already created internally. Can you share with us the status of this internal ticket? In development, staging, in review, or is in backlog to be done some day? Thank you!
Thanks Youenn for the update. Just chiming in, would be helpful to get at least status on that internal ticket. We're pretty much on standby here, and there is no workaround..
(In reply to Dan from comment #46) > Thanks Youenn for the update. Just chiming in, would be helpful to get at > least status on that internal ticket. We're pretty much on standby here, and > there is no workaround.. Status is : playing the ostrich
Status: prevent Safari on iOS from installing a website as a home screen app, just let it be a regular home screen shortcut that opens in the full browser. I've come across so many weird bugs, quirks and what not when installing a web app as a home screen app, I'm just giving up on iOS users.
Still an issue in May 2021. Hate to sound like a broken record but just pinging a comment to keep it active 🙂 Just saying but supporting PWAs properly could be a good tactic for Apple to show that IOS supports alternative delivery platforms for developers and there isn't any monopolisation 😉
(In reply to ik from comment #48) > Status: prevent Safari on iOS from installing a website as a home screen > app, just let it be a regular home screen shortcut that opens in the full > browser. > > I've come across so many weird bugs, quirks and what not when installing a > web app as a home screen app, I'm just giving up on iOS users. ik@rejh.nl, wondering if it's possible to somehow make the web page full screen from a standard home screen bookmark? Also would love to know how you stopped IOS from installing it as a web app but allowed android users to still do it? If the above is possible, then this could be a good workaround for everyone until the issue is fixed (although it would mean sacrificing other essential PWA features such as offline functionality, not that I ever managed to get that working on IOS anyway).
Jamie De Vivo: To prevent Safari from adding a web site as a PWA/standalone: 1) Remove all meta tags that tell Safari it's web app capable. 2) Remove the manifest tag from the html and, in javascript, detect the browser and add he manifest for browsers you want to support (in my case: `if (!is_iOS()) { /* add manifest tag */ }`). Step 2 is required these days as Safari added support for setting 'standalone' mode in the manifest (something I wish they hadn't, in hindsight, because iOS' standalone mode introduces so many bugs, quirks, etc, I consider it broken). > make the web page full screen from a standard home screen bookmark You could try the FullScreen API but that requires a user gesture, so probably not the solution you're looking for.
It's such a shame that this issue exists. It makes PWAs on iOS have a far worse user experience than opening the site in the browser. Is it something we expect will be resolved?
I've been experiencing this bug also. Background audio is essential for my app so I have had to degrade the UX and modify my PWA to display: "minimal-ui" on ios devices. This at least allows background audio continue in the background.
I haven't tried that yet @bshano, nice catch. Will do that for now. Do we have any updates for this issue on iOS 15? I saw something about this issue on the release notes, but I have not had the chance to play around with iOS 15 beta yet. https://developer.apple.com/safari/technology-preview/release-notes/ "Fixed audio that stops playing when backgrounding a page that is playing and capturing audio (r273069)"
Thalles: from the description in the linked revision, there is no mention of PWA / home screen web apps: https://trac.webkit.org/changeset/273069/webkit/ "This makes it working for websites using video elements for both audio and video, which is more common than websites using video elements for video and audio elements for audio." So I figure this is just a bug in websites that use video elements for both video and audio; now the audio stream in the video will continue to work while the video can be stopped or whatever.
Open for 2 years and 2 major releases. Its very clear now that Apple does not want competition from Web Apps to impact PROFITS and CONTROL from the monopoly App Store. I'm tired hearing the rhetoric from Apple/Tim Cook about being open, fair and transparent. Can someone call and raise the issue the FTC. Probably get a faster response than 2 years.
This should, I think, be fixed in iOS 15 beta 4 and onwards.
(In reply to Sam Sneddon [:gsnedders] from comment #57) > This should, I think, be fixed in iOS 15 beta 4 and onwards. Unfortunately that is not the case. Audio still stops when switching to another app, or going to Home Screen. Also stops when turning screen off.
<rdar://68184444>
I'd just like to leave a use case here: I have a music player app that supports playlist-style playback of songs. I listen to the `onended` event of the currently-playing Audio element to know when it is time to load and play the next track (this includes a fetch request to get some track metadata from the server). However, Safari on iOS won't run that JavaScript to completion when the tab is not in the foreground. This means that if my phone is locked, the playlist will just stop playing once the current song has finished. I'm not sure what the expectation is here, but I am hoping that this use case will be supported at least when in standalone PWA mode.
(In reply to Peter Fernandes from comment #60) > I'd just like to leave a use case here: > > I have a music player app that supports playlist-style playback of songs. I > listen to the `onended` event of the currently-playing Audio element to know > when it is time to load and play the next track (this includes a fetch > request to get some track metadata from the server). > > However, Safari on iOS won't run that JavaScript to completion when the tab > is not in the foreground. This means that if my phone is locked, the > playlist will just stop playing once the current song has finished. > > I'm not sure what the expectation is here, but I am hoping that this use > case will be supported at least when in standalone PWA mode. Please ignore the above, which appears to be working for me now and is not relevant to this bug post. :)
RE: Antitrust meeting today in DC To those of you who attended please note that this article was referenced as a non-issue as a result of recent comments but is still an issue on all current releases of the iOS operating system.
@Kevin Banfield I am interested to hear more. Are you saying that there was an anti-trust meeting that discussed this issue, but dismissed it under the incorrect assumption that it had been fixed?
Someone mentioned to me that this is (finally) fixed in iOS beta 15.4. Can someone confirm this? I'm not running the beta :)
(In reply to ik from comment #64) > Someone mentioned to me that this is (finally) fixed in iOS beta 15.4. Can > someone confirm this? > > I'm not running the beta :) Wow, just tested my PWA on 15.4 and the audio actually keeps playing when the app is sent to the background! So that's a confirmation from me anyway.
I created a couple reduced test cases for testing audio in PWAs with varying display modes on iOS. display: standalone https://careful-plastic-sidecar.glitch.me/ display: fullscreen https://mammoth-cottony-linen.glitch.me/ display: minimal-ui https://decorous-excellent-firewall.glitch.me/ As of iOS 15.3, background audio is broken in both standalone and fullscreen, but minimal-ui works fine (as @bshano noted above). Going to see if I can test on iOS 15.4 w/ Xcode Beta...
(In reply to Micah from comment #66) > display: minimal-ui > https://decorous-excellent-firewall.glitch.me/ > > As of iOS 15.3, background audio is broken in both standalone and > fullscreen, but minimal-ui works fine (as @bshano noted above). When I test that web app on iPhone, it launches from home screen to Safari. I suspect that iOS does not support minimal-ui. That would also explain why background audio works.
(In reply to Šime Vidas from comment #67) > When I test that web app on iPhone, it launches from home screen to Safari. > I suspect that iOS does not support minimal-ui. That would also explain why > background audio works. Sure enough, minimal-ui isn't supported (it just launches a Safari tab, same as any other non-PWA website that was added to the homescreen). The good news is that on the iOS 15.4 simulator, both standalone & fullscreen PWAs do have working background audio. I didn't see the audio player UI on the lock screen for them, but hopefully that's a quirk of the simulator or the beta version.
When using `new AudioContext()` rather than an audio element. Background audio doesn't work at all. Regardless of whether the site is installed or not. fullscreen: https://ios-bg-audio.glitch.me/fullscreen.html minimal-ui: https://ios-bg-audio.glitch.me/minimal-ui.html standalone: https://ios-bg-audio.glitch.me/standalone.html
Tested with the app from the initial comment. It sometimes keeps playing, but sometimes stops when you pull down Notification Center or switch apps. Sometimes the Play button doesn’t work. It also stops when you get a push notification with a sound (“ding”) and doesn’t resume. It’s progress, but still somewhat unpredictable behavior. This is for 15.4 (19E5209h).
(In reply to Jesper van den Ende from comment #69) > When using `new AudioContext()` rather than an audio element. Background > audio doesn't work at all. Regardless of whether the site is installed or > not. > > fullscreen: > https://ios-bg-audio.glitch.me/fullscreen.html > > minimal-ui: > https://ios-bg-audio.glitch.me/minimal-ui.html > > standalone: > https://ios-bg-audio.glitch.me/standalone.html This is expected. On iOS, WebAudio is considered "Ambient" audio from the system's perspective, and ambient audio is blocked by the system once the app producing it is no longer foreground.
> This bug is tracked internally, the required fix might not be at WebKit level. I'm starting to believe the fix/problem might be at the corporate level :|
As of iOS 15.4.1 this looks to be fixed! The repro site https://ios-standalone-bug.backgroundnoise.app mentioned in the opening post now works: audio keeps playing, and after the audio snippet ends, it correctly loops back to the beginning.
This is almost to good to be true, but I can confirm this is fixed! I can even pause/stop and then resume the playback from the lockscreen controls when the web app is in the background. Holy. Moly. It would be nice if someone would update this ticket (before we find out it's fixed on our own). Are we supposed to check every release for fixes for 3 yr old bugs? (sorry, I have to point that out and can't seem to do it without sounding snarky) Anyway. Good news. Thanks!
Hi folks who our wondering, this is indeed fixed. Due to a process oversight, we created a separate issue when the code change landed instead of updating this one. I'm duping to the other (newer) bug so it's clear that this is resolved. We regret the error. *** This bug has been marked as a duplicate of bug 232909 ***
And to note, this was a change shipped in iOS 15.4, not 15.4.1.