[mcdonje]

The 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?

[mrbombastic]

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.

[mcdonje]

What you're describing seems reasonable, but it doesn't align with what I quoted, unless I'm missing something, which I very well could be.

Having apps sleep and a daemon wake them to handle notifications doesn't require all of the notifications coming from Apple.

[mrbombastic]

Not sure i understand. Sure it doesn’t require it but Apple doesn’t trust you to handle it because you’ll probably drain the battery or spam the user or whatever, that is Apple MO, putting themselves in the middle so they can control the experience.

The single persistent connection is just to receive pushes, there is still some daemon controlled by apple in charged of dispatching to correct app.