Hacker News Reader

Comment by judah | Hacker News Reader

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.

View on HN

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.

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.

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.

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/

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.

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.

Chrome employs a neat trick where background tabs have all timers set to at least 1000ms:

https://codereview.chromium.org/6577021

Works on mobile as well.

> 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.

> 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.

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".

> 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.

But there is no case where it should be up to a web app whether its content should count as background audio. It is possible that a user should be able to flag such a situation, but native apps both have affirmative consent when downloading an application and have permissions models the user can manage, whereas the web has neither and web browsers need to assume both malicious and incompetent web devs will do terrible things with any feature they allow.

Because native garbage from the AppStore is at least vetted by Apple. For example background execution permissions will be subject to extra scrutiny by the reviewers.

Sorry, but I trust them more than those npm junkies saturating my pipes with adtech crap on every other corner of the web.

And with the App Store, the user has a chance to get an idea of what the app in question does and can make judgment calls as to quality, trustworthiness, etc before any code is executed.

Web technologies are not "suddenly" inferior to native technologies. They have always been inferior in some ways, and superior in others.

Letting javascript run when the browser isn't even in use would sacrifice one of the ways that web technologies are superior (nonintrusive when not in use) to make it a little less inferior in another way (ability to set up background tasks). That doesn't seem like a good tradeoff to me.

> I would argue that you are misusing the web.

It shouldn't matter. Even if auto-playing music is a terrible idea for most sites, there should be a way to ask the user for permission where it is reasonable.

There has been some efforts to create a permissions API, which included MIDI devices (last time I checked), which might be able to support this: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...

> You're trying to shoehorn something to do something it wasn't intended

That applies to almost all web content. Even hacker news doesn't fall into the original document browsing usage.

> there should be a way to ask the user for permission where it is reasonable.

Beware the law of unintended consequences - if you did that, every single add would pop up an annoying permission box.

( And before you say “no, ...” remember that there are more unscrupulous ad/malware companies that will prove you wrong. )

There are already a bunch of those pop ups that trigger when a script tries to access the microphone, USB, camera, etc. There just isn't any unified API for asking for permissions.

I was working on a SPA that needed to ask location information to tell the user service outages in their area, we spent a lot of time optimizing the permissions asking flow, making sure we didn't ask too often etc.

So I think companies with scruples, not malware oriented, or just possessed of good common sense will ask only when necessary.

I certainly prefer using (efficient) webapps over actual apps.

There seems to be a large concerted effort to make the browser the platform of choice for building apps, I see arguments all the time that web apps can be made to do what native apps can do and so forth, and that even if there is a lag in the development of web apps that lag will be covered in time and the network effects and ease of discoverability of web apps will triumph (I am stuck for time here so I had to summarize various arguments I've seen, I suppose others have seen them as well)

Your argument here is that there are classes of application that can never be built on the browser platform, based on you saying "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."

That argument may be correct, however then Apple should make an open statement saying hey, web apps just won't do it. Otherwise people might mistakenly hear the arguments that they will do it and think I will make a web app. And the people making the arguments for web apps should be hit about how do you handle getting the app to work in the background when it is something that absolutely needs to like a radio station.

>> I would argue that you are misusing the web

What? I built a music player, like Pandora. How is that misusing the web?

I don't want to build a native app. This is a side project for me - I don't have the time, resources, or desires to rebuild my app in proprietary technologies.

> I don't want garbage running in the background

If you're using my music player app, you absolutely want it running; otherwise the music stops.

> There are plenty of audio/radio apps on iOS using native technologies

I don't want proprietary native technologies, anymore than I want Flash or Silverlight. I want the open web.

> A playlist would be a hell of a lot cheaper than trying to run arbitrary javascript.

My app isn't a playlist. It's an app, akin to Pandora.

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.

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-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.)

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.

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.

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?

Reply on news.ycombinator.com