Like many here, I was looking for a reliable way to deliver push notifications to an app for background processing. I finally decided to use PushKit and all works well and the app was accepted into the AppStore, even though it's not a VoIP application. I'm using the AWS SNS (Simple Notification Services) to handle the backend push processing. However, even VoIP notification delivery will be throttled by iOS if you send excessive push notifications. As a simple test, I can send several VoIP notifications over 2 - 3 min and they will deliver promptly and processed by the app in the background. After I wait about 10 minutes (after locking the iPad and waiting for the application to be put to sleep by iOS) a subsequent VoIP push won't be delivered promptly by iOS. AWS is pushing the notification, but iOS is not delivering it to the app. I know this because as soon as I plug in the device, the notification is processed by the application. As an aside, if the device is left plugged in, all notifications deliver and process promptly.
So my question is this: Have others noticed this behavior with VoIP pushes also? Even though the iOS docs indicate that VoIP pushes are delivered immediately, it appears that iOS does throttle them if it considers the pushes "excessive" over some period of time.
I guess, When you keep your app in background then you receives push notification. but when your app is in terminated then don't receive push notification.
Possibly your app gets crash when it is in killed ( terminated ) state.
Pushkit silent notification is always with higher priority and works well all the time.
Try below things to find out cause and solution.
(1) Debug your app in killed ( terminated ) state, like app is crashing or not
(2) Send silent notification with simple php code using pem and certificates ( Both case background and killed ( terminated ) )
(3) Check pushkit integration steps, if your app is not registered for VOIP, then it would not receive silent notification.
Debug pushkit notification in terminated state
Put debug pointer on delegate methods
Go to edit scheme
Select run option then Launch -> Wait for executable to be launched
Send push kit payload from back end
Once you get payload on device
it will automatically invoke and debug pointer will invoke at delegate methods.
Refer some material
Related
Right now I have a framework that receives a silent notification, get the data from it (custom data) and translate it into a local notification to show the alert to the user (this is donde in didReceiveRemoteNotification:fetchCompletionHandler method). I have implemented this framework on an app and everything seems to be working correctly, silent notifications are being process when the app is in background and foreground. However, when the app is killed by the user or it is not running, I cannot receive notifications because of this:
Use this method to process incoming remote notifications for your app.
Unlike the application:didReceiveRemoteNotification: method, which is
called only when your app is running in the foreground, the system
calls this method when your app is running in the foreground or
background. In addition, if you enabled the remote notifications
background mode, the system launches your app (or wakes it from the
suspended state) and puts it in the background state when a remote
notification arrives. However, the system does not automatically
launch your app if the user has force-quit it. In that situation, the
user must relaunch your app or restart the device before the system
attempts to launch your app automatically again.
The reason I use this method for showing notifications is because the payload I sent to APNS has custom data with key-values that indicate how the notification must behave.
I've been doing some research and I found that Pushkit for VoIP can do the job. However, many post suggest that this can cause app rejection.
So my question is, how can I achieve receiving remote notifications even if my app was killed and considering that data in the payload has custom information to build the notification?
Silent push notifications are unreliable: they might get delayed, delivered in groups or even not delivered at all.
If you need to modify the content of the notification before presenting a banner for the user, you should use a Notification Service App Extension. You can also share some information between your app and this extension - using app groups or the keychain - if it needs something from your app to process the notification data.
I am trying to implement silent push notification in my application where I need to update some data in the server when silent notification comes. I am using Pushkit and it uses VoIP certificate for silent push notification but the app has been rejectd by Apple saying that "I can't use VoIP" certificate. It seems that apple has rejected it as I don't have any VoIP call functionality in my app. In that case how can I implement silent push notification so that my app gets activated even if it is not runnning(not even in the background) and I can update the server?
From my experience, iOS respects user's choice, so in case the user has killed the app, it will remain killed - no silent push notification will wake this app. VoIP is an exception to that, but as you wrote, it should be used only in VoIP apps. This makes sense, consider it a platform limitation: thanks to that user have some control over what is actually running on the phone, the device consumes less battery and lastly, foreground/system Apps has the most CPU time to utilize.
There are few techniques to work with data in the background:
Content-available push notification: will wake up the application in case it is suspended, or startup it in case it has been killed by the system/crashed. Note, that this only opens a 30-second window and amount of notifications is throttled by APNS.
Background fetch capability will act in a similar manner.
Background task to finish existing task - but this is only used when app is moved to the background.
If you need App to send updates to the server, I believe above should be sufficient (unless your app is spying on a user, it should have all relevant data available once the user finishes interaction with the App).
If you need a server to send data to the App, use silent push notification (or background fetch for periodic pulling), or in case this data is critical to the user, you can present him a remote notification - if the user considers that an important update, he will open the app.
I am using FCM notification for my app. When my app is in background or foreground I am receiving notification. But when my app is terminated that means closed from task then I am not receiving any notification. I searched about this and I am confused is it work when the app is terminated? I just need to know is it work or not when the app is terminated.
If it works when the app is terminated then I will go for next step for my app otherwise I will stop my implementation that's why I am not sharing any code. I followed this link
Beware with fcm on iOS, there are 2 ways of sending and receiving data; one is upstream/downstream messages the other is the push notifications. If you are using upstream/downstream messages the fcm connection is closed after the app is suspended, new messages will not wake your app. You may use push notifications instead but of course the downside is that they are push notifications you don't have much control over them.
I have a messaging service that I use for regular push notifications. For example, when one user sends a message, the other user receives a push notification with that message. I have noticed if the phone is on wifi and 3g / 4g, and the app is killed (and the screen is locked), the notification will be received. If the device is only on wifi and the app is killed (and the screen is locked), the notification is not received.
My assumption is that in order to conserve battery, the device disconnects from wifi after a certain time, and that is why push notifications are not received.
But when I use VOIP push notifications, the situation is different. Even if the app is killed and the device is on wifi (and the screen is locked), the notification will be received. So what does this mean? How is phone receiving this notification, if it disconnects from wifi?
What am I missing here?
Furthermore, to add to Sivajee Battina's answer, this is what you can read in the guidelines:
There are many advantages to using PushKit to receive VoIP pushes:
The device is woken only when VoIP pushes occur, saving energy.
Unlike standard push notifications, which the user must respond to before
your app can perform an action, VoIP pushes go straight to your app
for processing.
VoIP pushes are considered high-priority notifications
and are delivered without delay.
VoIP pushes can include more data than what is provided with standard push notifications.
Your app is automatically relaunched if it’s not running when a VoIP push is received.
Your app is given runtime to process a push, even if your
app is operating in the background.
So the third point confirms that your standard push notifications can be delayed in certain circumstances, while VoIP push notifications will always be delivered instantly.
Also, have a look at this question for reasons why standard push notifications are delayed or dropped.
You are almost correct in this - this is how voIP works. Excerpted from Apple Docs:
In the past, a VoIP app had to maintain a persistent network
connection with a server to receive incoming calls and other data.
This meant writing complex code that sent periodic messages back and
forth between the app and the server to keep a connection alive, even
when the app wasn’t in use. This technique resulted in frequent device
wakes that wasted energy. It also meant that if a user quit the VoIP
app, calls from the server could no longer be received.
Instead of persistent connections, developers should use the PushKit
framework—APIs that allows an app to receive pushes (notifications
when data is available) from a remote server. Whenever a push is
received, the app is called to action. For example, a VoIP app could
display an alert when a call is received, and provide an option to
accept or reject the call. It could even begin taking precursory steps
to initiate the call, in the event the user decides to accept.
When I receive a remote notification I updated a counter that I save to UserDefaults and I also show a local notification. Everything works as expected when the app is in the foreground, background, and suspended states Ref. When the app is in the Not Running state my counter is not updated nor is my local notification shown.
It is my understanding that I should be able to receive and process Remote Notifications while the app is completely off. A few articles online claim that when a Remote Notification arrives while in the Not Running state that the application:didFinishLaunchingWithOptions: should be called followed by application: didReceiveRemoteNotification:fetchCompletionHandler: but in my case it is not.
Is it possible to receive remote notifications while in Not Running state?
If your app is a VoIP app and you are using VoIP pushes through PushKit then a push notification will launch your app from the terminated state in order to deliver the notification. If you are using standard push notifications then your app will not receive the notification if it is terminated. You can include an alert text with a 'silent' notification that will be displayed to the user in the event that your app is terminated in order to prompt them to launch your app.
First of all, it sounds like you have a silent notification set up. Once you add alert data to your push notification (information like the title, body etc.. you can find more on that here), it'll start to display on the lock screen.
Second, it's not possible for your application to launch from a push notification, silent or otherwise, if it's in the Not Running state. The documentation on this is actually incorrect, as it states that the application will only not be launched if the user has quit the app. However, this actually also applies for any circumstance under the not-running state, for example if your app has never been launched since installation/rebooting, or if it was quit due to memory (a fairly common occurrence - iOS purges apps which haven't been run recently as required).
did you check this mark when app is background?