Does anyone know if iOS has a budget for remote push notifications?
That is, if an app or device receives too many remote push notifications in a day, is the app or device "cut off" or limited in some way for the remainder of the day?
I know that the Apple Watch has a budget for complication updates. I also know that there is a budget for the number of background refreshes an iOS app can request during a day. This varies depending on the iOS's determination of that app's usage patterns, being a "good citizen", battery life, etc.
If there is a budget for remote push notifications, is it at the app level, or device level? Is there any way to know when it has been exhausted?
The reason for the inquiry is that I'm considering forcing regular background activity in an app via remote push notifications. Not ideal, but more reliable than background refresh intervals.
Thanks for any help / insight you can provide.
If you are sending multiple notifications to the same device within a short period of time, the push service will send only the last one. For that reason, I do not recommend to use the push notification to trigger the method or background activity.
Apple Push Notification Service (APNS) does not warranty that push notifications are arrived all the time, it is risky!
Related
I need to extend my app functionality with push notifications. The desired outcome would be to send silent notifications which will trigger the creation of local notifications.
I read about this silent notifications and they seem to be very unreliable.
First of all according to this:
"If something force quits or kills the app, the system discards the held notification.".
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app the silent notification can be discarded. From my understanding force quit means that you double tap on home screen button and swipe up the app, right?
Secondly, according to this https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app apple doesn't recommend to send more than 3-4 silent notifications per hour. Do you have any experience with this behaviour? if you send 15 notification on an hour how many did you get?
If what I wrote above is true, then what alternative I have to silent notifications?
I believe remote notifications (of type alert, for example) are not affected by my two points above, right? Even if you force kill the app you will still get them.
I know there are so some stack overflow questions that covers parts of this topics but they are pretty old.
I understand that Silent Notifications and Remote Notifications are different things. The silent is just a regular Push Notification that doesn't generate any kind of alert to the user, it goes directly to the Notification Center, but there's still a hidden notification somewhere. Notice that the docs doesn't mention silent anywhere.
Now Remote Notifications are the real deal for your needs. This kind of notification doesn't produce any kind of alert to the end user, its just a payload that is passed into your AppDelegate methods, that way you can generate asynchronous calls to your app to inform that some external event happened, and take some action about it, like updating your local database.
The thing is, Remote Notifications rely on the same APNS infrastructure, and Apple doesn't guarantee the delivery of notifications. Although the failure rate tends to be very low nowadays, you should be aware that you can't rely on notifications for serious business logic. Background updates is a more a means of having your local state in sync and immediately available when the user opens the app, but it doesn't save you from having to manually trigger synchronization logic when your app is opened.
So about the specific bullets:
The thing is, iOS manages received notifications and optimizes the delivery to your app. Notifications can be received while your app is in background or stopped state. If you've sent a notification to the user and iOS kept it cached while your app was in background, and then the user forcibly killed your app, this notification will be lost. This should be probably be a very rare scenario, but could happen.
I personally don't have experience with this notification throughput stuff. I believe this is probably related to the fact that when a notification is sent and your app is in background, iOS will run it in background to deliver the notification and give you a chance to process it. Depending on the volume of notifications the operating system may impose restrictions on the background processing to preserve battery or other system resources.
So, I don't know your feature requirements, but I wouldn't consider the Remote Notification infrastructure much reliable for more than small updates to the local state.
I am working on one iOS App in which I want to read all incoming remote notifications and reschedule them to my desired time.
So Let's say, I have reschedule all of my phone's push notification to 10am in morning, so all of my Phone notifications would come only at 10am in my Phone and there would be no any other notification except this time.
is this feasible in iOS? Does Apple allow this?
I assume you mean all notifications, not just ones from an app you may be developing. In which case, no, it's not possible to affect when the notifications are shown.
You could simply just turn your phone off (or put it in Airplane Mode) and turn it back on at 10am. :)
Apple does provide "Do Not Disturb" as a feature however. This doesn't stop notifications from arriving, but they don't alert the user when they do arrive. Instead there'll just a be a list of notifications waiting for you when you pick up your phone.
As stated clearly in Apple docs, beacon ranging can be done in background for a short period of time only, say up to 10 seconds by default or up to 3 minutes with the help of background task expiration handler. As per my app's use case, app needs to do beacon ranging for every 15 mins until user exits the region. I am thinking of using background push notification(silent push notification) for this purpose(assuming data connection is available on the device always). So the flow goes like this, upon user entering the region, app calls the server with device token, server sends silent push notification for every 15 minutes. Once app received push notification, it does beacon ranging within allowed period of time if needed. Question I have here is whether using push notification in background mode to do ranging is legal, will I face any issues during app store submission.
Note: Also I need to enable BLE background mode for the app, to read some characteristics from some BLE devices.
Technically you can do it, but Apple mostly rejects such app. One important thing you have to consider is that, if the app is manually killed by the user and not running in the background, then the app won't wake up with silent push notification. There is a workaround if you have VoIP push notifications it will wake the app even from the terminated state. But you might need strong reason while pushing it to AppStore.
If you misuse one of the background modes, the app will probably be rejected, saying that, I don't think silent push notifications were meant for: keep an iOS app in "Background" state by sending it a silent push notification every few minutes.
another thing is that silent push notifications are rate limited as described http://asciiwwdc.com/search?q=push+notification, so I'm not sure if they will be sent every few minutes.
Apple says that;
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.
You might want to see this article. The user talks about apps that use silent notification for triggering location tracking. But eventually it's a hack that Apple may reject some time in the future, so it's best to have a contingency plan. FWIW so far I haven't heard anyone reporting rejection.
So the official answer is don't do it, as for the why you can refer to Ashish's answer. The unofficial answer is if you can't change your business logic then do it at your own risk.
The iOS application I'm working on does the exact same thing with the exception that I'm using recording instead of a Beacon. Recording by iOS standards gives more issues in pushing the app to the app store.
But Apple did not reject this app. Although we still are facing some issues but they don't relate to your problem.
You can follow such a tutorial for further help apart from the answer you were looking for : iOS Push Notification Demysitfied
Also, I've done firing of local notifications, while the application is in the background. BLE even works if the app is killed by the system, when the OS receives some communication from your peripheral or central, iOS wakes your app up and executes the desired function, before putting your app back to sleep.
I have developed a small iBeacon based application, when the application detects one of our iBeacons makes a call to a web service to obtain a data set and send a local notification to the user. All this is working correctly.
I have now raised the idea that these local notifications could vary over short time intervals, with new content. The problem is that if the user does not leave the region of the iBeacon and reenters, the application will not "wake up" and the user will not receive the new updated notification.
After asking for advice on how to tackle the problem, someone suggested using remote notifications. Reading about it I found the silent remote notifications, but I'm not sure if I can use them as I'm thinking.
My idea is this, when a notification is modified or created and is associated to a iBeacon on the server, sending a silent push notification to the application so that it "wakes" if not in foreground. Thus, when the application "wakes up", you can do ranging few seconds, and if any iBeacon near detect and send the new notification.
Is this possible and permissible? I can send all silent push notifications that I want or is there some limit?Thanks
This is possible and permissible. You can read more about this in the Using Push Notifications to Initiate a Download section here:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
However, there are a few drawbacks:
Remote notifications can be slow to arrive, and are actually not even guaranteed by Apple to arrive at all.
They are a bit of a headache to set up given that you need to build server ifrastructure to send them.
A less timely alternative is to just do periodic refreshes, but the OS typically lets your app do this only once a day. See Fetching Small Amounts of Content Opportunistically here:
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
I want to add a fire alarm function to my app. I think the push notification may be the best choice. But if there is much delay, like over 10 mins, it would be meaningless for fire alarm.
So how much delay for push notification, assuming the device is online?
Push notifications are unreliable and cannot be guaranteed that they have been delivered. It all depends on the apple APNS server, that said, usually when I send a push notification I get the result in under a few seconds.
More Information:
They are not reliable! There is no guarantee that push notifications will actually be delivered, even if the APNS server accepted them.
As far as your server is concerned, push notifications are fire-and-forget; there is no way to find out what the status of a notification is after you’ve sent it to APNS. The delivery time may also vary, from seconds up to half an hour.
Also, the user’s iPhone may not be able to receive push notifications all the time. They could be on a WiFi network that does not allow connections to be made to APNS because the required ports are blocked. Or the phone could be turned off.
APNS will try to deliver the last notification it received for that device when it comes back online, but it will only try for a limited time. Once it times out, the push notification will be lost forever!
Source: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12