News for hackers. Stuff that matters.
Re:Apple approves previously rejected HKMap.live app by yzmtf2008 on Friday October 04, 2019 @05:05PM (#21161887)
While I too wish for better support for PWAs in iOS, the way push notifications are implemented in PWAs and iOS are fundamentally incompatible. iOS requires all push notifications to go through Apple's push server, which means there is only one long-poll connection to check and significant battery savings. Whereas, Google's PWA docs[1] literally lists random-push-service.com as the push server.

[1]: https://developers.google.com/web/fundamentals/push-notifica...

Re:Apple approves previously rejected HKMap.live app by coder543 on Friday October 04, 2019 @05:07PM (#21161906)
Safari on macOS already implements a proprietary web push technology using APNS. Push providers like OneSignal already support it.

It is 100% compatible with the way notifications work on iOS.

Re:Apple approves previously rejected HKMap.live app by RX14 on Saturday October 05, 2019 @04:00AM (#21164317)
A long poll connection (i.e., a TCP connection not sending packets) uses exactly 0 joules of battery until something is sent.
Re:Apple approves previously rejected HKMap.live app by yzmtf2008 on Saturday October 05, 2019 @06:11PM (#21168308)
That's not true. Long pools cannot have an indefinite timeout, especially for a mobile use case. Plus, it's not just the TCP connections. If you look at push notifications on Android phones in China, because GMS isn't available, every other app is having a background thread checking for push notifications. It adds up.
Re:Apple approves previously rejected HKMap.live app by Nullabillity on Friday October 04, 2019 @05:33PM (#21162100)
From that page:

> Each browser can use any push service they want, it's something developers have no control over.

The browser dictates the push service to use, not the developer of the web app. That URL is for the app developer to push content to.