> They do it so they don't have to stand up their own push servers

I don't agree with this dependency on being in good standing with Google either.

But there is a technical reason that isn't wanting to avoid using their push servers. It is about battery usage and radio bandwidth.

Keeping open an idle connection over WebSocket, long-poll HTTP or TCP/IP needs regular pings (typically 30 seconds are used), one ping per connection. Otherwise your app can't be sure to receive messages from the server in real time, as the connection can disappear into CGNAT or similar hole where it doesn't receive messages sent by the server. To an app not using pings to check, such a blackholed connection is indisinguishable from an idle connection with no pending messages.

Waking the radio every 30 seconds, times 2 (back and forth), times the number of registered applications, would be quite battery draining. It drains battery both for background CPU usage and radio processing. Those pings in aggregate can even amount to a significant amount of data usage for users on smaller plans.

So there is a battery and radio advantage in using a shared push service, which only need a single idle connection to be kept live with 30 second pings.

There's another level to this, not available to regular developers using TCP/IP, HTTP or WebSockets.

The mobile network itself has to maintain handset connection liveness to the nearest tower, at a lower level than IP pings, and this is obviously optimised for battery and radio performance, and always running.

With arrangements in place with the mobile networks (which Google and Apple have), the mobile OS can leverage that for more reliable, lower power push notifications, by either guaranteeing the network will send something technically similar to a low-level SMS when there's an outstanding message, or by guaranteeing their special push IP connection will stay live by itself (no CGNAT blackhole) or be notified if something happens to it.

This allows the mobile OS to offer a shared push service that's fairly reliable at real-time notifications, with zero continuous CPU and radio power overhead for the idle connection.

▲ dotancohen an hour ago | parent [-]

Why does a banking app that I'm not currently using need to ping a server occasionally?

When I want to do banking I'll open the app, do my business, then close the app. A banking application does not need push notifications.

▲ jlokier 37 minutes ago | parent | next [-]

My comment was about push service sharing generally, not banks, from a technical point of view that many people aren't aware of but may find interesting.

Clearly, real-time notifications are useful with many apps, notably real-time messaging, even if you don't think they have a place with bank apps.

For bank and credit card apps, I find their push notifications to be very useful. They are among the most useful notifications I get, because they tell me about things I find important, which I wouldn't notice otherwise.

They tell me things about transactions that have gone through, sometimes after a long delay, transactions that need confirmation right now or they will be blocked, balance being too low, or too high (credit cards), payments that are required today, refunds that came through after a product was returned, transfers that completed on the receiving said, payment received from a client, direct debits that are going out tomorrow so I will need to make sure there's enough in the account, customer service messages that require a response from me or they will eventually close the account, and so forth.

"Just open the app" doesn't work: All of those, except transaction confirmations, are things where I wouldn't know to open the app if I didn't get a message of some kind to tell me.

These days, in some juristictions it's also required to send real-time notification to confirm some purchases, because the phone's security is considered better than card details alone. Depending on how the purchase is made (e.g. in-person vs online, different payment terminals), you might not know the reason a transaction is blocked or held is because it's waiting for you to confirm in the app, so the notification is useful for this.

All these used to be done by SMS, and that was useful too. But SMSs are just push notificatons with a worse UI and worse visual cues.

	▲	dotancohen 30 minutes ago \| parent [-]
		`> But SMSs are just push notificatons with a worse UI and worse visual cues.` ... and no dependence on Google or Apple.

▲ vbarrielle an hour ago | parent | prev [-]

Unfortunately it needs push notifications to authorize online payments.

	▲	dotancohen 38 minutes ago \| parent [-]
		So open the app when performing an online payment.