For Silent-Push Notifications (SPNs), Apple suggests sending no more that 2 Pushes per device per hour. If you exceed this limit, the client's DASD (Duet Activity Scheduler Daemon) may throttle future SPNs to the target app. The decision heuristic for this throttling is not well documented, perhaps intentionally. But since SPNs are required to be set with apns-priority=5 (non-immediate, non-guaranteed delivery) what is the ideal send rate for getting a successful delivery to the app?
For example, are chances of successfully navigating the DASD better by sending 2 SPNs/device per HOUR (until an ACK is received by our server) or are the chances better with only 2 SPNs/device per DAY?
Any insight is appreciated. Thanks!
Related
The app I worked on got an alert from apple wallet: "Some passes are receiving too many updates, which may affect battery life. Automatic updates for *** passes will be disabled. Choose RE-enable if you want automatic updates to continue." I only have 2 passes in the wallet from that app.
Does anyone know what's the reason trigger this alert? If we send 2 push notifications within 5 seconds, will that trigger this kind of alert?
It means pretty much what it says. Apple is respectful of user's battery life and data consumption and recognises that a pass update is a high energy activity that the user has little control over, and so if a pass issuer makes too many updates, then iOS takes action to alert the device owner so they can choose if they would like to continue to receive these updates (at the expense of reduced battery life).
Apple's previous policy was to silently throttle updates, but this led to problems, since users were unaware that they were being throttled and would wonder why their passes were not updating.
Apple recognises that developers may need to push content more frequently, which is why you can disable rate limiting on your device via the developer menu (that appears when you have your iPhone hooked up to Xcode).
Apple doesn't publish the criteria that it uses to throttle, and normally a quick burst of activity (E.g. a one-off burst of 2 or 3 messages in the space of a few minutes) would be tolerated. But if the issuer is sending dozens of messages every few minutes, then you can almost certainly expect they will see this message.
Based on my understanding of how subcriptions work, it seems like we should build some sort of cron job to check if almost about to expire users were renewed since notifications won't be sent in some cases.
Based on reading these:
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_
https://medium.com/revenuecat-blog/ios-subscriptions-are-hard-d9b29c74e96f
my question is:
is my conclusion true? are notifications not sent for renewals?
if I have to build a cron job and call verifyReceipt myself I can imagine that I would call it quite a lot per day, is there a limit to how many times I can call this endpoint? When will I be throttled?
Notifications are not sent for regular renewals. You will get a notification (INTERACTIVE_RENEWAL) if the user cancels and resubscribes. Best practice would be to check the /verifyReciept endpoint to get subscription status from Apple. There aren't any published throttles on this endpoint and would imagine it's extremely scalable.
Also, highly recommend RevenueCat to completely manage subscription status for you.
I'm trying to decide which way to implement a "quiet hours" feature in my app to allow users to specify times in which push notifications should be silent. I see two options:
1) Server-side. Their settings are sent to the server which sends notifications with different properties (or perhaps not at all) during quiet hours.
2) Client-side. The app receives all notifications via silent push, the app then processes each notification and only notifies the user as appropriate.
I see problems / limitations with each method.
For #1, the implementation becomes more complex (especially if I want to add additional notification filters based on alert type, etc), and the issue of which timezone the client is in would be very hard to resolve (especially as the client moves from one timezone to another). I certainly don't want to be tracking their position and updating their current timezone on the server.
For #2 I have read a number of comments in various places that the silent push that goes only to the app is not as reliable as normal push notifications that directly notify the user and are not processed through the app. I would prefer to implement quiet hours in this way, but I am very concerned about a reduction in the reliability of the notifications coming through. I have also read that the app will NOT be started in the background if the user has force-quit it. Is that still the case?
I have two questions. First, how have others handled this concept of quiet hours? Second, is the silent push as unreliable as I have heard in the real-world, or has this gotten better (or worse) with the latest versions of iOS? I know there are factors, such as how much power the app consumes while processing these notifications. On average my app would only receive a few silent notifications a day, and processing would be very fast.
Not sure this is really an answer, but too much for a comment!
Is your app likely to be used in different time zones?
Or are your users all based in one country?
This could mean handling client side is going to be a lot simpler.
Also remember that there is no guaranteed delivery time of a push, its normally pretty instant, but not always, so although you might of sent it with 5 minutes to spare before a quiet hour, it might arrive after the quiet hour has actually started.
App that I am working on is offering a VPN connection, that can run even when the app is not running at all. This service is paid, but also I would like to offer a free trial limited by session length and maximum data transfered.
The problem I've encoutered, is with monitoring the data trasnfered when the app is in background or not runing at all. So far the best solution I've came up with, would be to periodically run small task that checks if the user is still within the data limit and if not, the VPN will be disconnected and notification shown to the user.
Will silent notification get priority every time it will be required? According to this quote from developer.apple.com, they are low-priority which isn't what I need, but I was unable to find anything else.
Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour.
How can this be done reliably? Is there any other way?
If this is a personal VPN connection (i.e. you're just providing a config to the standard system) and you're not in the flow, then this isn't possible. There is intentionally no "I want my program to run all the time" solution. Even if you come up with one, Apple will probably shut you down.
If you're writing an MDM/supervised VPN connection (i.e. you're providing a ...Flow object of your own), then you're already running all the time and you can just control it as you want. I'm assuming you have the former or you wouldn't be asking.
I believe you're doing this backwards. Monitor the session length on the server, and disconnect there. When you disconnect, send a push notification, which can display a message directly without having to open the app. That is both robust and the intended solution.
Periodically posting a silent notification to wake yourself up will definitely not work because Apple specifically does not want you to do that and they explicitly break it (as they note "silent notifications are not meant as a way to keep your app awake in the background"). It's bad for battery life. This is intended to be solved on your sever, on on the user's device.
The Apple APNS only allow up to 20 max connections from your server, so how does apps like WhatApp is able to deliver such high volume of message per seconds?
Even they can use multiple servers, but assuming they have 5M active users sending message, they also need 250K servers, that sound crazy, right?
What is the trick here?
It's very simple: You don't need one connection per user.
You can send multiple messages per APNS connection. Each message can be sent to a different device. The maximum payload length is 256 bytes plus 45 bytes of overhead; a 10Mbit connection can handle at least 4100 messages per second, or about 250k/min, or about 3 per hour per user.
Does the average "active user" send more than 3 per hour? It's hard to tell. "Active" might mean that they sent a message that month; such distributions have very long tails.
Either way, that's for a single 10M connection. I'm not sure how much contention there is on Apple's side, but it would not surprise me if you could exceed 50M without too much fuss.
Additionally, they almost certainly use their own servers when the app is in the foreground, and if they're clever they can keep the connection open for a few minutes after the app is backgrounded (and only use push notifications once the connection closes).