[floatingatoll]

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?

[Andrew_nenakhov]

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.

[floatingatoll]

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.

[Andrew_nenakhov]

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.

[floatingatoll]

I am sad to hear that didReceive(_:withContentHandler:) is not sufficient for you to implement end-to-end encryption of the content of user-visible push notifications using an encryption key exchanged prior to APN delivery. I hope someday Apple extends their support for preprocessing received display notifications to users to ensure that the intermediary only knows the receiver’s destination address at most.

https://developer.apple.com/documentation/usernotifications/...