4 ms·

> I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer

by mcny 8y ago

> I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer running in foreground I can imagine that being quite a hurdle to overcome (without compromising the reason for doing it in the first place). I don't think this is true. Please correct me if I am wrong but there are ways to handle the scenario. Apple could create nsfirebase (basically an Apple version of Firebase for lack of a better name) and require all websites to talk to nsfirebase and the iOS device only needs to reach out to that particular end point on nsfirebase which minimizes battery loss. In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours (where n is something Apple can monitor and update with any iOS release).

untog 8y ago
> In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours But iOS apps can't do that. The only way they can guarantee background execution is if they are playing audio, or say they're a VOIP app. Of course, Apple could change those rules for Safari, but what I'm saying is that I don't think it's as simple as just flipping a switch - it'll need OS level changes, which will slow things down a lot compared to stuff like offline caching, which the Safari team can implement themselves. There's also a fundamental difference between iOS notifications and Web Push ones - the notification is already created in the iOS payload. So it doesn't need to wake the app up at all, it just shows the notification. That's not possible with Web Push, so it's a change compared to how iOS handles every other notification.
- menckenjr 8y ago
  Getting background location updates will also let your app stay unsuspended. You better have a good reason for getting them, though, or your app won't make it into the store. (Ditto for VoIP or audio apps; the app store reviewers are wise to tricks for mimicking services in a non-service architecture.)
  - wpietri 8y ago
    This is interesting: > the app store reviewers are wise to tricks for mimicking services Has that been written up anywhere? I'd really like to know more about the reasons behind this arms race.

by mcny 8y ago

untog 8y ago

> In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours But iOS apps can't do that. The only way they can guarantee background execution is if they are playing audio, or say they're a VOIP app. Of course, Apple could change those rules for Safari, but what I'm saying is that I don't think it's as simple as just flipping a switch - it'll need OS level changes, which will slow things down a lot compared to stuff like offline caching, which the Safari team can implement themselves. There's also a fundamental difference between iOS notifications and Web Push ones - the notification is already created in the iOS payload. So it doesn't need to wake the app up at all, it just shows the notification. That's not possible with Web Push, so it's a change compared to how iOS handles every other notification.

menckenjr 8y ago
Getting background location updates will also let your app stay unsuspended. You better have a good reason for getting them, though, or your app won't make it into the store. (Ditto for VoIP or audio apps; the app store reviewers are wise to tricks for mimicking services in a non-service architecture.)
- wpietri 8y ago
  This is interesting: > the app store reviewers are wise to tricks for mimicking services Has that been written up anywhere? I'd really like to know more about the reasons behind this arms race.