18 ms·

Power saving is great, except when it breaks apps. Unfortunately, Webkit has broken certain web apps by their power saving features. For example, on iOS, I ha

by judah 7y ago

Power saving is great, except when it breaks apps. Unfortunately, Webkit has broken certain web apps by their power saving features. For example, on iOS, I have a Pandora-like web app that plays music. When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. I'm not doing any active JS, just an event handler for audio.ended event. The event handler never fires when my app is the in background or when the screen is off, thus, I can't play the next song. This effectively makes it impossible to build a functioning audio app/radio station on iOS using web technologies. I've reported this issue to Apple some 2 years ago, but they still haven't fixed it. Bonus: as of iOS 12, it also breaks web apps that are packaged with Cordova and published into the App Store.

inetknght 7y ago
> Power saving is great, except when it breaks apps. That's a problem. > Pandora-like web app that plays music. When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. I think that's intended. I would argue that you are misusing the web. I would argue that most users don't want websites to run while the browser isn't in the foreground. If you want to elevate your capability to interact with the user while in the background then build and install a native app or leverage existing native apps' functionalities. > When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. The event handler never fires when my app is the in background or when the screen is off, thus, I can't play the next song. That's good. I don't want garbage in the background to do anything javascript-related at all. > This effectively makes it impossible to build a functioning audio app/radio station on iOS using web technologies. Really? There are plenty of audio/radio apps on iOS using native technologies. You're trying to shoehorn something to do something it wasn't intended and then causing noise because it doesn't do what it wasn't intended. > I've reported this issue to Apple some 2 years ago, but they still haven't fixed it. What bug? You think this is a problem caused by power saving? No, it's not. You've already stated that the song is playing until it ends, but that your javascript doesn't get notified that it ended. You think the problem is that power saving is stopping you from processing the next song to play. I disagree. I think the problem is that you aren't providing a play list to the browser. Frankly, I'm not a web developer so I don't even know if there is a playlist API. But if there isn't, then that is your problem. A playlist would be a hell of a lot cheaper than trying to run arbitrary javascript.
- Scoundreller 7y ago
  > then build and install a native app or leverage existing native apps' functionalities. Personally, I trust my browser a lot more than any native app. I cringe every time I'm forced to use a native app when the browser would do.
- marmada 7y ago
  I'm pretty sure your comment misunderstands the original comment, and even if it didn't, it is rather aggressive. Why are web-technologies suddenly inferior to native technologies? Maybe I want my playlist to be accessible through a website from all my devices instead of having to download a native app on each device. The company saves money/releases an app that would otherwise never have existed, and I get to use a service in a consistent manner across all platforms. Oh, and web-apps are more secure because they have less permissions than a regular app. The author of the comment said web-app. That probably means a progressive web-app. This means there is an icon for the web-app on the home screen (like a normal app) and the user interacts with it, like a normal app, although in reality, everything is being handled by the browser behind the scenes. > Progressive Web Apps are installable and live on the user's home screen, without the need for an app store. They offer an immersive full screen experience with help from a web app manifest file and can even re-engage users with web push notifications. I would argue that in this case it makes sense for the progressive web app to have all the capabilities of a native app since that's what it looks like to the user. Of course, if by web-app, the author means "a tab inside Safari browser", then the behavior is logical and your comment makes sense, we wouldn't want Safari to churn through iOS battery. > That's good. I don't want garbage in the background to do anything javascript-related at all. Why is "javascript-related" garbage better or worse than native-related garbage? Arguably, "native-related" garbage is worse because it can do more to your phone than "javascript-related garbage".
  - saagarjha 7y ago
    > The author of the comment said web-app. That probably means a progressive web-app. This means there is an icon for the web-app on the home screen (like a normal app) and the user interacts with it, like a normal app, although in reality, everything is being handled by the browser behind the scenes. Presumably the issue here is that there is no special case where a progressive web app can let the OS know that the content it's playing should count as background audio.
tinus_hn 7y ago
And they are obviously never going to fix it. You can’t give websites a way to run in the background on a phone, they’ll just drain the battery with analytics, ads, cryptocoin mining or just spinning. They can’t be trusted.
- microcolonel 7y ago
  They should provide a permission dialog for this. It's one thing to protect people from this by default, another altogether to make it impossible.
  - Wowfunhappy 7y ago
    Apple OS's are already overloaded with permission dialogues. Add enough of them and you'll start to really frustrate users, and/or cause them to blanket accept everything. Desktop UI's are built around showing the user which programs are awake and active, and which are not. Mobile UI's are not. Unless/until that changes, users rely on the OS to make these decisions for them. It would be nice if we could rely on developers instead, but they will naturally be focused on their own app or page, not the system overall.
  - MaxBarraclough 7y ago
    The more likely solution would be for them to enable this sort of thing in 'PWAs'. Apparently [0] it's not possible today though. [0] https://stackoverflow.com/a/53572400/ https://stackoverflow.com/a/53572400/
    - microcolonel 7y ago
      Webpages can play media in the background on Android, but it involves locking the screen, then pressing the play button on the lock screen to confirm that you really wanted that.
  - inimino 7y ago
    That would be the consistent way to solve the issue if Apple wanted web apps to be as powerful as native iOS apps. But they don't, and that ship sailed long, long ago.
Malic 7y ago
I think you've hit on an opt-in usage case. Much like the opt-in feature "Will you allow [website] to access your location?", there could be a "Will you allow [website] to operate in the background?" I think that is something that the community could get behind.
- AgentME 7y ago
  Instead of a permission prompt, Safari could make it so sites that use the Media Session API (https://developers.google.com/web/updates/2017/02/media-session https://developers.google.com/web/updates/2017/02/media-sess...) get to run code in the background if they have a media control visible in an active notification. (If the user doesn't want the site to run in the background, then the user could swipe away the media controller notification.)
  - saagarjha 7y ago
    I wonder if Apple is reluctant to do something like these because a website will use it to stay in the background (as the Facebook app did a while back) but in this case there is no App Store Review to force websites to behave.
deleted 7y ago
[deleted]
iwalton3 7y ago
This is one of the more frustrating limitations of the iOS mobile browser I’ve had to deal with. You can work around it by live streaming the music to the client, and handling track playback on the backend. Music Player Daemon is a good package to do this, but it will only handle one user per instance.
nkristoffersen 7y ago
Building a react native version of your app shouldn’t take more than a few days and you could then integrate with the native expectations. Have you tried that?

by judah 7y ago

inetknght 7y ago

> Power saving is great, except when it breaks apps. That's a problem. > Pandora-like web app that plays music. When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. I think that's intended. I would argue that you are misusing the web. I would argue that most users don't want websites to run while the browser isn't in the foreground. If you want to elevate your capability to interact with the user while in the background then build and install a native app or leverage existing native apps' functionalities. > When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. The event handler never fires when my app is the in background or when the screen is off, thus, I can't play the next song. That's good. I don't want garbage in the background to do anything javascript-related at all. > This effectively makes it impossible to build a functioning audio app/radio station on iOS using web technologies. Really? There are plenty of audio/radio apps on iOS using native technologies. You're trying to shoehorn something to do something it wasn't intended and then causing noise because it doesn't do what it wasn't intended. > I've reported this issue to Apple some 2 years ago, but they still haven't fixed it. What bug? You think this is a problem caused by power saving? No, it's not. You've already stated that the song is playing until it ends, but that your javascript doesn't get notified that it ended. You think the problem is that power saving is stopping you from processing the next song to play. I disagree. I think the problem is that you aren't providing a play list to the browser. Frankly, I'm not a web developer so I don't even know if there is a playlist API. But if there isn't, then that is your problem. A playlist would be a hell of a lot cheaper than trying to run arbitrary javascript.

Scoundreller 7y ago
> then build and install a native app or leverage existing native apps' functionalities. Personally, I trust my browser a lot more than any native app. I cringe every time I'm forced to use a native app when the browser would do.
marmada 7y ago
I'm pretty sure your comment misunderstands the original comment, and even if it didn't, it is rather aggressive. Why are web-technologies suddenly inferior to native technologies? Maybe I want my playlist to be accessible through a website from all my devices instead of having to download a native app on each device. The company saves money/releases an app that would otherwise never have existed, and I get to use a service in a consistent manner across all platforms. Oh, and web-apps are more secure because they have less permissions than a regular app. The author of the comment said web-app. That probably means a progressive web-app. This means there is an icon for the web-app on the home screen (like a normal app) and the user interacts with it, like a normal app, although in reality, everything is being handled by the browser behind the scenes. > Progressive Web Apps are installable and live on the user's home screen, without the need for an app store. They offer an immersive full screen experience with help from a web app manifest file and can even re-engage users with web push notifications. I would argue that in this case it makes sense for the progressive web app to have all the capabilities of a native app since that's what it looks like to the user. Of course, if by web-app, the author means "a tab inside Safari browser", then the behavior is logical and your comment makes sense, we wouldn't want Safari to churn through iOS battery. > That's good. I don't want garbage in the background to do anything javascript-related at all. Why is "javascript-related" garbage better or worse than native-related garbage? Arguably, "native-related" garbage is worse because it can do more to your phone than "javascript-related garbage".
- saagarjha 7y ago
  > The author of the comment said web-app. That probably means a progressive web-app. This means there is an icon for the web-app on the home screen (like a normal app) and the user interacts with it, like a normal app, although in reality, everything is being handled by the browser behind the scenes. Presumably the issue here is that there is no special case where a progressive web app can let the OS know that the content it's playing should count as background audio.

tinus_hn 7y ago

And they are obviously never going to fix it. You can’t give websites a way to run in the background on a phone, they’ll just drain the battery with analytics, ads, cryptocoin mining or just spinning. They can’t be trusted.

microcolonel 7y ago
They should provide a permission dialog for this. It's one thing to protect people from this by default, another altogether to make it impossible.
- Wowfunhappy 7y ago
  Apple OS's are already overloaded with permission dialogues. Add enough of them and you'll start to really frustrate users, and/or cause them to blanket accept everything. Desktop UI's are built around showing the user which programs are awake and active, and which are not. Mobile UI's are not. Unless/until that changes, users rely on the OS to make these decisions for them. It would be nice if we could rely on developers instead, but they will naturally be focused on their own app or page, not the system overall.
- MaxBarraclough 7y ago
  The more likely solution would be for them to enable this sort of thing in 'PWAs'. Apparently [0] it's not possible today though. [0] https://stackoverflow.com/a/53572400/ https://stackoverflow.com/a/53572400/
  - microcolonel 7y ago
    Webpages can play media in the background on Android, but it involves locking the screen, then pressing the play button on the lock screen to confirm that you really wanted that.
- inimino 7y ago
  That would be the consistent way to solve the issue if Apple wanted web apps to be as powerful as native iOS apps. But they don't, and that ship sailed long, long ago.

Malic 7y ago

I think you've hit on an opt-in usage case. Much like the opt-in feature "Will you allow [website] to access your location?", there could be a "Will you allow [website] to operate in the background?" I think that is something that the community could get behind.

AgentME 7y ago
Instead of a permission prompt, Safari could make it so sites that use the Media Session API (https://developers.google.com/web/updates/2017/02/media-session https://developers.google.com/web/updates/2017/02/media-sess...) get to run code in the background if they have a media control visible in an active notification. (If the user doesn't want the site to run in the background, then the user could swipe away the media controller notification.)
- saagarjha 7y ago
  I wonder if Apple is reluctant to do something like these because a website will use it to stay in the background (as the Facebook app did a while back) but in this case there is no App Store Review to force websites to behave.

deleted 7y ago

[deleted]

iwalton3 7y ago

This is one of the more frustrating limitations of the iOS mobile browser I’ve had to deal with. You can work around it by live streaming the music to the client, and handling track playback on the backend. Music Player Daemon is a good package to do this, but it will only handle one user per instance.

nkristoffersen 7y ago

Building a react native version of your app shouldn’t take more than a few days and you could then integrate with the native expectations. Have you tried that?