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?
Silent Notification
Silent push notifications are supported for non-VoIP apps, you just have to accept that they are delivered with lower priority. Specifically, silent push notifications are subject to a budget and if you exceed that budget the delivery of the notification from the system to your app (which involves either resuming or relaunching your app in the background) will be delayed.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
We currently have a VoIP app enabled app that requires silent push notifications. This works perfectly at development environment, but fails in production. Nevertheless the apns server reports a Succeeded notification, but it never gets delivered.
Is this a bug? any ideas how to get around this?
Thanks!
I had spent weeks looking for ways to make the silent notification more reliable as one of my app's functionality critically depends on it. So far, I couldn't find a satisfactory solution. During the course of it, I find that indeed the notifications are delivered and reach the device, but on the device, a daemon plays a gatekeeper and rejects it unless the device is in a state that meets multiple criteria. To check this in detail, connect your device to the console, and in its search box, add "dads" (it's the name of the daemon) & "your apps name".
Use your app or a 3rd party app such as "Push Hero" (that allows easy generation of app targetted push notifications both alert- and silent-type) and examine what is printed out on the console under the set search criteria. You will find messages like:
com.apple.pushLaunch.<your App ID>:627306:[
{name: DeviceActivityPolicy, policyWeight: 5.000, response: {Decision: Can Proceed, Score: 0.67}}] sumScores:95.343333, denominator:97.010000, FinalDecision: Can Proceed FinalScore: 0.982820}
I found numerous criteria (CPU Usage, Device Polity, Thermal, ThunderingHerdEvents, DataBudgetPolicy, BatteryLevelPolicy...) that will affect "FinalDecision" to become "Should Not Proceed". That is when your silent notification (already on your device) is silently ignored to wake up the App. This is probably to prevent apps from abusing APNs to drain the battery or deteriorate performance, but even for a very small amount of tiny APNs, it gets harder than for a camel to pass through the eye of a needle. Virtual useless as far as my app is concerned. What a shame it is... Please post a reply if you came across a more up-to-date resolution for this issue. I'd appreciate it.
Yes, but today there are many use cases for a background app to want a "reliable" / "instantaneous" background notification... I wish Apple would either:
- Add a new APNS push type for apps that need this type of functionality, with justification
- Allow background apps that are already running to receive their background notifications
It seems these background pushes are also designed to be very limited in number (just ~ 3 per hour)... But what is a background app to do? Take Spotify for example, if you want to stop the music remotely, change the song, adjust the volume, playlist etc?
It's a bit strange, because Android doesn't have such tight restrictions with respect to push messages or background apps and their battery life is quite good. There are many iOS "silos" which make routine programming difficult and the user experience worse...
Does anyone have a better idea for the Spotify example? You could use a WebSocket, but that too is closed immediate upon entering the background, and connecting again it's just closed after just 5-10 seconds on iOS... Push seems like the most power efficient way, but seemly it can't be done?