How do Messenger and other apps refresh themselves in the background regularly and display every single notification?
Is it a server that sends a signal to the app on a regular basis to refresh their data in the background?
Mostly applications use multiple ways to update notifications:
Send push notification, if in case you want to inform user about the activity.
Send silent push notification, if in case you don’t want to inform user that something happened in background. ( "content-available" : 1 )
IMPORTANT
Background update notifications are not meant as a way to keep your app awake in the background beyond quick refresh operations, nor are they meant for high priority updates. APNs treats background update 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.
Source: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html
But still most apps use this.
Run/schedule a background task to perform some action.
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 trying to understand what is the limit for push notification per hour assuming I do not show the user a message, only update data on a terminated app, to move some small critical calculation from a server to the phone.
So for example if I want to update a device on a value that's being changing all the time, and say I want to inform the phone on a new value every 1-3 minutes , or even 10 minutes, wake up and calculate something and decide if I should alert the user.
Reading many posts like is there a limit when sending push notifications to multiple iOS devices?
did not provide a clear answer.
Is it something popular to inform a device every 10M ? is it a good practice ? do large companies do that ?
It seems that here :
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_updates_to_your_app_silently
Apple says you allowed to send 2 Silent Notifications per hour, and it works only when the app is in the background.
When you send real push notification which inform the user on the lock screen, then you can send how many you like (which is pretty strange because both use the same resources from Apple exactly, and on silent notification I even provide better user experience by filtering some of the notification from alerting him, so its not clear why when the user is being alerted you can spam him but when a server update an app in the background - you have a limit )
If you use Remote Notification (silent notification) you have a limit per hour maximum 3 notification you can receive or send.
Silent Notification.
If you want to update your app in background or even if it is killed, without limitation of Push, you can use UNNotificationServiceExtension in order to download something from your serve or you can implement some value to share with your main app, then when user open your app, you can refresh it.
I'm developing a great feature for my app which requires HTTP requests to be sent periodically in background.
I have read already many articles and discussions here, but haven't come up with a solution because all suggestions I met on stackoverflow.com solve the problem only partially.
Let me explain in details what do I want my application to do.
Consider there is a website with API and I want to send requests (when app is in background mode) periodically to check the state of data on the website. And if the state of data is acceptable I would send Push Notification to user to notify him that data is correct at the moment.
Could someone propose a solution how to implement this idea in iOS app?
On iOS you can't do this, as you've described it. You don't get to schedule tasks to happen at regular intervals when your app is in the background or not running. You also don't get to control whether iOS decides to terminate your app when it's running in the background, so "not running" is a case you'd need to handle (you can't just keep running in the background as for long as you want).
I'm not sure I understand the server side of things though. If your server is manipulating the data until it's acceptable, and it can send push notifications, why does it need to wait for an incoming request from the phone? Why not just send the push when the data is ready? If the app decides what's "acceptable", maybe have the app tell the server what it wants so that the server knows when to send a push.
There are a couple of options that would get close to what you describe. If you implement the "background fetch" feature in your app, iOS will launch the app when it's not running and let it make network calls in the background. There's no guarantee of how often this happens, though. This is described in Apple's background execution docs
The other option is the "silent" push notification. If your server sends one of these, iOS can launch the app in the background to handle the notification. The app could make a network call if necessary. You can send these at whatever time you like, but Apple warns to not overdo it:
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.
Silent pushes are described in Apple's push notification docs.
iOS Background Execution Limits
Questions
How do I keep my app running continuously in the background?
If I schedule a timer, how do I get it to fire when the screen is locked?
How do I run code in the background every 15 minutes?
How do I set up a network server that runs in the background?
How can my app provide an IPC service to another one of my app while it’s in the background?
Answer from Apple:
The short answer to all of these is You can’t. iOS puts strict limits on background execution. Its default behavior is to suspend your app shortly after the user has moved it to the background; this suspension prevents the process from running any code.
Official: https://developer.apple.com/forums/thread/685525
I'm developing a great feature for my app which requires HTTP requests to be sent periodically in background.
I have read already many articles and discussions here, but haven't come up with a solution because all suggestions I met on stackoverflow.com solve the problem only partially.
Let me explain in details what do I want my application to do.
Consider there is a website with API and I want to send requests (when app is in background mode) periodically to check the state of data on the website. And if the state of data is acceptable I would send Push Notification to user to notify him that data is correct at the moment.
Could someone propose a solution how to implement this idea in iOS app?
On iOS you can't do this, as you've described it. You don't get to schedule tasks to happen at regular intervals when your app is in the background or not running. You also don't get to control whether iOS decides to terminate your app when it's running in the background, so "not running" is a case you'd need to handle (you can't just keep running in the background as for long as you want).
I'm not sure I understand the server side of things though. If your server is manipulating the data until it's acceptable, and it can send push notifications, why does it need to wait for an incoming request from the phone? Why not just send the push when the data is ready? If the app decides what's "acceptable", maybe have the app tell the server what it wants so that the server knows when to send a push.
There are a couple of options that would get close to what you describe. If you implement the "background fetch" feature in your app, iOS will launch the app when it's not running and let it make network calls in the background. There's no guarantee of how often this happens, though. This is described in Apple's background execution docs
The other option is the "silent" push notification. If your server sends one of these, iOS can launch the app in the background to handle the notification. The app could make a network call if necessary. You can send these at whatever time you like, but Apple warns to not overdo it:
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.
Silent pushes are described in Apple's push notification docs.
iOS Background Execution Limits
Questions
How do I keep my app running continuously in the background?
If I schedule a timer, how do I get it to fire when the screen is locked?
How do I run code in the background every 15 minutes?
How do I set up a network server that runs in the background?
How can my app provide an IPC service to another one of my app while it’s in the background?
Answer from Apple:
The short answer to all of these is You can’t. iOS puts strict limits on background execution. Its default behavior is to suspend your app shortly after the user has moved it to the background; this suspension prevents the process from running any code.
Official: https://developer.apple.com/forums/thread/685525
Is it possible to use both background fetching and silent remote notifications at the same time to maximize the number of background activity? Apple says they put limits on both but using both would be a work around to such limits right? If I set the background fetch interval to the minimum and then send a silent notification every 15 minutes, how would this work?
Yes, you can set both. But remember that the background fetch interval is just an indication to iOS. iOS determines when background fetches occur based on its own criteria (including the phone being plugged in or not, being unlocked or not, doing any other work that woke up the CPU and radios, etc.).
Likewise, delivery of silent remote notifications is not guaranteed.
Remember that in any case, you want to minimise power consumption while in the background. All those restrictions Apple sets are there for this reason. Trying to bypass them has a cost.