[GeekyBear]

When the user is not running the app, what is the use case for the app waking up and processing data that is not an incoming message to be delivered to the user?

Facebook was using the VOIP framework to burn so much power after the user had quit the app that you would see articles pointing out that deleting the Facebook app could double the battery life of the device.

>Deleting This 1 App Can Literally Double Your Phone's Battery Life

https://www.inc.com/john-koetsier/deleting-this-one-app-can-...

If I am not running a messaging app, the only power draw I want to see from that app is decrypting an incoming message intended for delivery.

Anything else can wait until I next open the app.

[toast0]

From my perspective, everything you want to see in the app when you next open it, should be transfered to your phone when you have network access; because you might not have access when you open the app. There's lots of things that fit in there -- read receipts, group changes, profile photo changes, contacts that join or leave the network.

Not user visible (mostly), but still important are things like end to end key changes and key cycling related to group changes.

Disclaimer: I used to work for a messaging company.

[GeekyBear]

As far as I'm concerned, if reading an incoming message in a notification doesn't motivate me to open your app, then all of those housekeeping tasks can wait until I do open your app.

Respect the battery life of my device.

[pmart123]

My exceptions would be financial market apps and news apps. I might also throw podcast apps in this group to selectively download typically viewed shows or topics.

[pdimitar]

Disagreed.

I don't want apps working in the background. If I want to see what changed in an app, I'll open it and I expect it to request the changes then and only then. If I have no network then I'll see no changes. Easy.

Your perspective is very foreign to me and definitely seems hostile to the battery life of my device.

[toast0]

I want to be able to message with people while I (and they) have intermittent coverage. I live in an area with poor cell coverage, and it's difficult to use messengers that require me to be online while the app is open if I'm on the bus or the ferry. The worst is those that show notifications with partial messages, but then I can't read the whole message, because I'm in a dead zone.

SMS doesn't require me to have the app open while I have a working connection, and an SMS replacement shouldn't either.

But --- I think your perspective is reasonable too; there's a tradeoff here: offline experience, battery (maybe --- if you're going to get and process everything anyway, there is a difference in processing it in small batches vs one big batch, but it might not be that big), server visibility into types of messages, etc. Most phone OSes have a battery saver mode that disables background processing, so you can force this, but I personally disable that for the apps I want to work offline.

[joshuamorton]

> Your perspective is very foreign to me and definitely seems hostile to the battery life of my device.

Not if the OS manages the batching of those updates. Then it's barely any more hostile than what the OS needs to do to manage things like receive phone calls.

I think you're also strongly in the minority on this. People who use messaging apps prefer the ability to get notified (at least sometimes) when they get a message, even an unexpected one. That true for phone calls, texts, emails, or Whatsapp/signal/fbm etc.

[GeekyBear]

Message notification is not impacted here. You don't need to open the full app for that to happen.

If the app uses encrypted messages, you just have to write an extension to handle the decryption on device while the app is not running.

If the user wants to interact further after reading the message notification, they open the full app.

[jbverschoor]

Indeed. I disabled background app refresh, and I don’t want apps to abuse certain features to do thing I don’t want them to do.

I kicked out zoom and adobe permanently for the same reason

[scarface74]

Background app refresh on iOS is one of the few features that Apple automatically allows but you can disable on an app by app basis.

[pdimitar]

And I did. That's not related to my parent commenter's point, I think.

[scarface74]

Apple has had “Background App Refresh” for a while now.

[lacker]

The use case here is to keep it private when exactly you are receiving a message. The push API requires that the server know when data indicates a user-visible message and when it does not, and the maximally private messaging app server wouldn’t need to know that.

There is certainly a trade off between privacy and battery life here. If Apple stated that they were sacrificing a small bit of privacy for improved battery life, I would find their communications honest on this issue. Since their messaging is typically so pro-privacy, they probably have just fallen into the habit of claiming every change enhances privacy even when it isn’t.

[GeekyBear]

From my perspective, receiving an encrypted message, decrypting it, and displaying it for the user is the only thing a messaging app that is not running should be able to do.

I literally can't think of a single other thing that should happen unless and until the user opens the app, at which time the app can open an encrypted connection to the server and exchange any sorts of messages it likes.