[gcr]

This is basically what iOS has done from the start.

If you don't see the app in front of you, iOS will very quickly kill it if it has any background tasks.

It's a leaky abstraction, but honestly I like the implicit promise/guarantee between the scheduler and the user.

I only get annoyed when I want some batch task like uploading photos, but even then it's not too hard to leave the phone powered on and unlocked on my desk until the photos upload...

[kuschku]

Except when you try to ensure someone gets notifications while the phone is in an intranet.

Or when you try to transmit notifications without going through Google/Apple servers, because those require you to control the messaging server (due to API auth limitations), which does not work with distributed systems.

A messaging app that only works when the screen is on is useless.

[gcr]

Why not use Apple's servers to deliver a ping, and then the app checks with your own server what the content of the message should be?

That way, you get realtime event notifications without the privacy risk of exposing content to Apple's servers.

[kuschku]

To send any message to Apple’s push service, you need to have a certificate.

That same certificate can be used to replace your app on the store, or so on.

Basically, that is your one key to the kingdom.

So, I obviously can’t give everyone who hosts a server for the app that key.

So I have to host a server transmitting all those pings then.

Even ignoring the obvious DDoS risk, and assuming it’s only used in good ways, I end up with having to buy an entire additional server, just for that.

And I still leak metadata, which – as the NSA has shown – can be easily correlated with who is whom if you have enough data.