I am working on an app that needs reliable push messages (like any voip) under ios9.
Here it says, that with IOS8+ one should use apns (registerForRemoteNotifications):
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/occ/instm/UIApplication/setKeepAliveTimeout:handler:
In the Optimize VOIP Apps document, Pushkit is preferred:
https://developer.apple.com/library/ios/documentation/Performance/Conceptual/EnergyGuide-iOS/OptimizeVoIP.html#//apple_ref/doc/uid/TP40015243-CH30-SW1
Does anybody have a clue on this?
Or do they run the same code in the background?
From the documentation for VoIP Push Notifications:
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.
The biggest advantage of VoIP Push Notifications over regular ones is in my opinion, that the app gets relaunched if it was force-closed.
In general, if you wan't to use the push notifications for VoIP functionality, e.g. to notify about an incoming call, use PushKit. It was developed for this purpose. For all other cases, use regular push notifications. Your app won't go through the review if you use PushKit for an app without VoIP functionality anyways.
Related
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.
if My app works at background, can I use silent push to wake app and get the VOIP call?
I used "jpush" to post a silent push which can work when connecting my idevice with Xcode and run APP.
If my idevice doesn't run APP with Xcode, I can not receive the silent push at background (only receive at foreground.)
Is it possible to use silent push to wake up APP and get VOIP call?
Did I get something wrong??
Yes. If your application does VoIP calling then it's possible to use PushKit:
Overview
The PushKit framework sends specific types of notifications — such as VoIP invitations, [...] — directly to your app for processing. [...]
Unlike user notifications, which are supported by the UserNotifications framework, PushKit notifications are never presented to the user — they don't present badges, alerts, or sounds.
PushKit notifications offer the following advantages over user notifications:
If your app isn't running, the system automatically launches it upon receiving the notification. [...] For more information, see Local and Remote Notification Programming Guide.
Your app is given runtime to process the notification, even if it's running in the background.
[...]
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.
I am developing a VOIP app, and planning to use PushKit as our push engine. We are using it to send VOIP related push to application, allowing us to setup the call.
However, are we allowed to use the same push engine for other type of messages? like a trigger to refresh news, local database, etc in the background thread.
I mean will they approve this kind of "mixed usage" on app store?
Thanks
Starting on iOS 13, you are no longer able to do so.
Now you must always report a new incoming call when you receive a voip push notification. Not doing so will cause a crash. Repeatedly failing to do so will make your app ignore subsequent voip pushes.
From documentation for setKeepAliveTimeout:handler: method of UIApplication:
In iOS 8 and later, voice-over-IP (VoIP) apps register for UIRemoteNotificationTypeVoIP push notifications instead of using this method. Using push notifications eliminates the need for a timeout handler to check in with the VoIP service. Instead, when a calls arrives for the user, the VoIP service sends a VoIP push notification to the user’s device. Upon receiving this notification, the device launches or wakes the app as needed so that it can handle the incoming call.
But I can't find anything about it. Is this a thing?
If someone is also confused by this documentation, they probably mean PushKit Framework and PKPushTypeVoIP presented in WWDC 2014, Writing Energy Efficient Code, Part 2