Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Change Causes Scramble Among Private Messaging App Makers

theinformation.com

Post reply on HN
Print view View original

81–90 of 110 posts

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#81

Post by GeekyBear »

lacker wrote: post #79
GeekyBear wrote: post #66

Earlier quoted context omitted.

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 Ph…

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 batter…

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#82

Post by GeekyBear »

toast0 wrote: post #71
GeekyBear wrote: post #66

Earlier quoted context omitted.

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 Ph…

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…

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#83

Post by joshuamorton »

pdimitar wrote: post #77
toast0 wrote: post #71

Earlier quoted context omitted.

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…

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.

> 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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#84

Post by pmart123 »

GeekyBear wrote: post #82
toast0 wrote: post #71

Earlier quoted context omitted.

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…

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.

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#85

Post by toast0 »

pdimitar wrote: post #77
toast0 wrote: post #71

Earlier quoted context omitted.

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…

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.

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#86

Post by gnicholas »

cromwellian wrote: post #73
gnicholas wrote: post #27

Earlier quoted context omitted.

Isn’t this possible with Apple’s Find Friends functionality? EDIT: downvote because why?

I didn't downvote you, but Find Friends doesn't geo-fence. So unless I'm actively tracking him, I won't know. I only want to be notified if he leaves the school premises during school hours, I don't want to micromanage his location otherwise.

Thanks, I understand that the feature is enabled at a more granular level in some of these third-party apps. I don't have smartphone-aged kids, so thankfully I've not dug into these details yet...

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#87

Post by GeekyBear »

joshuamorton wrote: post #83
pdimitar wrote: post #77

Earlier quoted context omitted.

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.

> 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 m…

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#88

Post by jbverschoor »

pdimitar wrote: post #77
toast0 wrote: post #71

Earlier quoted context omitted.

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…

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.

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

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#89

Post by vonseel »

lacker wrote: post #80
vonseel wrote: post #76

If you were building an app that needs to do something like this in the background today, what is the recommended approach if you're on a platform like React-Native? Can JS even be reliably executed in the background?

For the vast majority of cases it’s better to just use the Apple push notification API and not try to keep a background process running constantly.

What if you need to decrypt the payload?

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#90

Post by Andrew_nenakhov »

floatingatoll wrote: post #70
Andrew_nenakhov wrote: post #67

In short: apple is breaking the only reliable way to deliver notifications. We're making an xmpp app and this breaks everything: regular silent notifications provided by apple work like shit. We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.

What non-UI-resulting notifications does your app need to deliver that, as a user, will negatively affect the quality of my experience when not delivered through the VOIP method? Why, as a developer, did you find that non-VOIP Background Data Refresh failed to meet your needs for creating a viable user experience - and what needs did it fail for?

There is a lot of traffic in xmpp that is not message. Like, delivery / read receipts, carbon copies, etc. It's often fully encrypted and a server doesn't even know the contents and if it should or not be showing anything for this event: it just has to tell an app to wake up, fetch messages, let it decide what to do.

With this change, we're left with 2 notification methods: one that always presents a notification banner (resulting in EXTREMELY BAD user experience - banner on every read receipt, on every your own message sent from every device, etc), or one that is extremely unreliable: it is delivered badly if a user is low on battery, and never delivered if a user swipes an app away.

Post reply on HN