alt Hacker NewsThe entire architecture here is surprising to me.
>an iPhone could not afford to let every installed application maintain its own background poll against a remote server. The proposal...a single persistent TLS connection from each device to Apple, over which any registered third party could deliver alerts.
I thought apps were sending notifications locally in the device. Like, if a messaging app receives a message, there's a network call for that. Then if the messaging app wants to tell the user they received a message, it can just hit a local API for that, right?
Is the pattern actually that the app makes another network call to the notification service to register the notification, which makes another network call to the device to deliver it?
yeah this is what author hints at with "Push as a battery problem". Apps are limited by default in what they can do in the background due to this, so most apps are in a suspended state not making network calls when you are not using them. To avoid the app having to keep running this stuff is delegated to OS which tells the app, "hey I have a push for you wake up and handle it!" You can send pushes locally but because of the background limitation it is not practical for unpredictable events like messages coming in.