3 ms·

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 pr

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.

vonseel 7y ago
By “work like shit”, what exactly do you mean? Slower delivery? Unreliable delivery?
- Andrew_nenakhov 7y ago
  Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.
  - p2t2p 7y ago
    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.
    - Andrew_nenakhov 7y ago
      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.
      - dang 7y ago
        Yikes! Attacking another user like this will get you banned on HN. Can you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here?
floatingatoll 7y ago
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 7y ago
  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 7y ago
    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.

vonseel 7y ago

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

Andrew_nenakhov 7y ago
Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.
- p2t2p 7y ago
  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.
  - Andrew_nenakhov 7y ago
    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.
    - dang 7y ago
      Yikes! Attacking another user like this will get you banned on HN. Can you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here?

floatingatoll 7y ago

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