It also omes down to power consumption and special mobile protocols. Keeping a TCP connection open on a mobile link requires occasional keepalive package excha

It also omes down to power consumption and special mobile protocols. Keeping a TCP connection open on a mobile link requires occasional keepalive package exchange. That wakes up the mobile radio, which is quite power hungry if the device isn't doing anything else. That radio wakeup is needed for each independent TCP connection's keepalives, so to minimise the power consumption of multiple idle app/notifier connections, you want them multiplexed over a single TCP connection. Another factor is the ability to send the underlying event over a lower-level mobile protocol. The mobile base station is regularly exchanging with the handset anyway, to maintain a link which can carry station-to-handset events already and to monitor the link. The whole thing is very well optimised for the radio. So an occasional application event can be sent over that link as well without needing any extra keepalives or radio wakeups. That's the most power efficient thing to do in principle, assuming application events aren't happening often. Unfortunately, having lots of independent push notification providers being used by different apps at the same time would be quite power hungry. I think it would be great if a user could direct all the subscriptions through one or two services of their choice though, including an option to provide their own service URL that they run themselves.