Live data from Hacker News

Apple Change Causes Scramble Among Private Messaging App Makers

theinformation.com

91–100 of 110 posts

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#91
post #68

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.

By “work like shit”, what exactly do you mean? Slower delivery? Unreliable delivery?

Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#92

Earlier quoted context omitted.

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

So, I’m going to translate this because it will sound different in another phrasing. This will sound judgmental, but I want to present the contrasting view that Apple likely holds here, rather than a sympathetic ear (as many others have provided that service already). No insult or harm is meant, and I have made no effort to look up what your app does, so this isn’t personal at all. Here goes.

You’re willfully circumventing iOS guidelines regarding Background App Refresh in order to provide an experience that breaks two enforced behaviors that Apple imposes on all apps.

First, in low battery mode, iOS reduces the frequency of non-alert notifications in order to conserve power by reducing cellular traffic frequency, often to the point of batching to once a minute or more. By overcoming this behavior with the VOIP framework, you bypass the intentional battery life protections Apple has built into the operating system.

Second, iOS enforces that no invisible background refreshes may occur once apps are force quit%, unless and until they are reopened. You willfully are circumventing this restriction that was put into place to respect user intentions to “quit” an app by using the VOIP framework to perform background activity even after your app is quit.

Both of these actions are taken with the express intent of breaking the constraints that the Background App Refresh system places on all iOS apps, in order to deliver an experience that has no “Fetching latest changes” delay when the app is next opened, either during low power mode or after a force quit.

Apple had the right to terminate your app from the App Store altogether in response to this violation of their background app refresh guidelines, as they make clear that their guidelines are not the sole and exclusive definition of the boundaries of acceptable behavior, and are generally unfriendly towards those who exercise loopholes to the detriment of their designed experience.

For whatever^ reason, Apple instead gave everyone three months warning that this Background App Refresh loophole is being closed. The VOIP system is meant to carry real-time communications that require the user to be immediately notified, visually and/or audibly, and abusing it for non-visible notifications is no longer permissible. Fortunately, the existing notification system that everyone used prior to the VOIP loophole still works just as it always has, and so the apps will have no trouble reverting to compliant methods.

This will not only restore behaviors that users expect from low power mode and force quitting apps, but will also ensure that the critical and significant battery performance gains of low power mode’s reduction in background app refresh update intervals are restored to all iOS devices afflicted by apps using the VOIP hack today.

I hope this helps explain why “delivered badly” may be considered a better outcome than “delivered ignoring low power mode and force quit”. I assume you disagree with Apple’s choice to restrict background app refresh behaviors, and this led you to implement the VOIP mechanism, but unfortunately that time is over. I hope your users and app are able adapt readily and without fuss to the return of the power-saving pre-VOIP paradigm+ for silent background refreshes.

% Nomorobo sends a visible push notification if you haven’t fetched updated rules in a while, offering to reopen the app and start a refresh if you tap the notification. I rarely see it, but I’m grateful for it every time.

^ Facebook.app using this same approach

+ Mail.app demonstrates this paradigm effectively, reducing fetch times to “essentially never” in low power mode if you don’t have notifications configured. It takes a good minute or so sometimes for it to download my Mail after I wake up and check it, but my phone also only uses 5% battery overnight, ensuring that my phone’s alarm clock goes off even when I can’t find a charger. I’m very grateful that Mail.app makes me wait for my mail instead of checking silently in the background and draining my battery, and that in a nutshell is why low power mode is worth a ‘poor’ user experience.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#93
post #48

Earlier quoted context omitted.

That doesn't work with average users. Basically Android did that - apps started to ask for admin permissions, accessibility features and other dangerous stuff and users just click Allow on anything.

This is exactly correct: because average users are dumb, it is our duty as software developers to make decisions for them, and to use whatever practical encryption or legal copyright means available to us to ensure that users do not have the ability--by any means that could plausibly be under the control of the user--to access and modify (or even see!) the behavior of the software running on the hardware they think t…

So, I really wonder if the reason I am getting so many downvotes (I am only at 0 right now, but I have been as high as 3, so this comment has been pretty controversial so far) is because people are somehow failing to get my over-the-top / so-exaggerated-it-hurts sarcasm (which is a bit sad), or if people so truly agree with the premise that upstream developers are smart and users are dumb that they are angry at my strong characterization of it as categorically evil (which is downright terrifying).

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#94
post #68

Earlier quoted context omitted.

By “work like shit”, what exactly do you mean? Slower delivery? Unreliable delivery?

Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.

That’s is what I expect. If I kill your app for whatever reason I expect it to remain killed, not to override my decision.

If your protocol is so bad it can’t handle intermittent connection, well to hell with this protocol.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#95

Earlier quoted context omitted.

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

So, I’m going to translate this because it will sound different in another phrasing. This will sound judgmental, but I want to present the contrasting view that Apple likely holds here, rather than a sympathetic ear (as many others have provided that service already). No insult or harm is meant, and I have made no effort to look up what your app does, so this isn’t personal at all. Here goes. You’re willfully circumv…

TLDR: you know nothing.

Longer explanation: You do not know how XMPP works. XMPP is a federated protocol that requires a persistent connection between a client and a server. XMPP consist of multiple independent servers. Client developers and server owners are usually different parties.

To send a push notification to JabberChat app some XMPP server (say, xmpp.org ) must post a notification update to appserver hosted by JabberChat owners (say, jabberchat.org), because only they can send push notifications to an app. If you insist, like Apple, to transmit only 'meaningful' updates, appserver owners will be able to snoop on all passing traffic. That is not desireble bordering not acceptable.

So, XMPP naturally devised a way that only 'content available' notification is transmitted to an appserver, which relays it to a client via APNS/FCM. A client application then wakes up, connects directly to its own server (which is likely INDEPENDENT from app developer!), fetches data and acts accordingly. Now this capability to reliably fetch data without Apple / appserver intermeddling is crippled, which introduces lots of privacy risks.

See XEP-0357 for more details.

You see, instant chat messages are exactly that kind of real-time communications that requires a user to be immediately notified. The only viable way to provide real-time notifications without violating user privacy were these VoIP notifications, and apple just killed these.

All your logic applies only to centralised client-app architecture, and totally not applies to any federated one.

Also, Apple's restrictions are honestly dumb. Smartphone is a computer and one should not restrict how a user wants to use that computer. If a user needs background tasks, just let them do it, only alert them about power usage and let them decide if they need this app or not.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#96
The notification are for signaling. The message notification can be distinct and encrypted using standard push notifications. If the problem is with metadata around the conversation (like typing indication, etc), they still can be encrypted on the server but with a cleartext flag associated with them to tell if the content should be pushed or not.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#97
post #94

Earlier quoted context omitted.

Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.

That’s is what I expect. If I kill your app for whatever reason I expect it to remain killed, not to override my decision. If your protocol is so bad it can’t handle intermittent connection, well to hell with this protocol.

Oh. You know nothing too. A protocol can handle the intermittent connection. A user can't handle instant message not delivered instantly, and it has nothing to do with a protocol, only with Apple's restriction.

Oh, there ARE ways to deliver a meaningful message, but they require transmitting full unencrypted message text over APNS! (this also results in app developers being capable to snoop on this traffic too - while currently data is exchanged directly between a user server and his client, bypassing client developers).

Next time comment on something you have any clue about.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#98
post #96

The notification are for signaling. The message notification can be distinct and encrypted using standard push notifications. If the problem is with metadata around the conversation (like typing indication, etc), they still can be encrypted on the server but with a cleartext flag associated with them to tell if the content should be pushed or not.

You do not want any kind of cleartext alerts on read receipts or typing notifications. Most people also don't want apple to know what type of data is transmitted to your app.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#99
post #71

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…

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

Re: Apple Change Causes Scramble Among Private Messaging App Makers

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

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.
Post reply on HN