How reliable are iOS silent notifications?

user_9401094 0
Viewed 803

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.

  1. 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?
  2. 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.

apple-push-notifications push-notification swift ios
1 Answers

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:

  1. 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.

  2. 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.

user_151694920
Related