VoIP push notification without VoIP funcionality

First, to get the VoIP question out of the way - No, you cannot use VoIP push notifications for any purpose other than reporting VoIP calls. That is no longer an App Review issue, but your app will be terminated if you receive a VoIP push that does not end up in a call, and will be blocked from receiving further VoIP pushes after a while.

As for unreliability of normal push vs. VoIP push, that is a myth. Normal push notifications sent at high priority (priority 10) use the same channels as VoIP pushes and have the same reliability.

If you are sending normal high priority pushes and they are not arriving reliably or in a timely manner, that would be a push service app/server/network side issue you need to resolve on your end.

If you are sending content-available pushes, keep in mind that those will always be delivered as low priority.

While researching VoIP push notifications we can across this thread. You mention in your reply that “your app will be terminated if you receive a VoIP push that does not end up in a call, and will be blocked from receiving further VoIP pushes after a while”.

We would just like to confirm our assumption that as long as an inbound VoIP call is announced to the user (system call UI) then regardless of the outcome (answered, rejected, or ignored) then the device will continue to be able to get VoIP pushes and wake up the app in the background. Also if for some reason the user presses accept and the call does not start (server error, etc) will iOS start to block that app?

Thank you!

I know this is an old thread, but you're not able to send a background push with a priority of 10 today. What this means is sure, your app cannot refresh content until the user has unlocked their phone (when on cellular), but this also means that background apps with the proper entitlements, cannot receive a reliable push on when to do something.

For example, an audio app in the background cannot receive a reliable way to stop playing. A new push category for such a use case 'background-entitled' or something would be a good addition.

Unless someone has a better idea.

Today, the only way to do this is with a WebSocket connection, but that too is problematic. Its killed after just 10 seconds of inactivity, so you need to constantly send a ping / pong. This actually makes battery consumption vastly worse than if Apple would kindly allow background apps a new push category, or allow them to receive a background (content-available) push, since they're already running.

Unfortunately it doesn't seem to be the case, when on Cellular. On WiFi they are in fact delivered to the app immediately. Even including a foreground notification before a background one doesn't work, and despite the app already running, it will not receive the background notification.