3 ms·
> If you are an Apple engineer and can help get that shipped, I will buy you a nice dinner. If you're an Apple recruiter, hire me so I can help ship it! :) Not
by mcny 8y ago
> If you are an Apple engineer and can help get that shipped, I will buy you a nice dinner. If you're an Apple recruiter, hire me so I can help ship it! :)
Not that I know anything not known publicly but I suspect the reason Apple iOS Safari does not have Web Push API is not because they lack developer resources to write the code to get it done. Apple is under tremendous pressure to increase revenue from its "services" right now so it seems a bad time to strengthen PWAs.
- palidanx 8y agoWouldn't you say though if that push notifications were allowed PWAs would cannibalize the revenue of the ios app store? It doesn't seem like apple would have much incentive to do this as PWAs would eventually compete with their own platform.
- scarface74 8y agoApple makes most of its app revenue from in app purchases and most of that is for consumables for games. The types of apps that could be a PWA wouldnt make Apple any money.
- sjroot 8y agoYou can integrate Apple Pay pretty seamlessly into a PWA. It actually adds a lot in the way of feeling like a real native app.
- untog 8y agoI don't think that's really true, because Apple has strengthened PWAs in a lot of ways in recent iOS releases. 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).
- 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 agoGetting 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.)