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