Difference between voip push and regular push when waking app from background

Question

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?

Buzzard

I do not think wifi is completely disconnected when your iOS device goes in sleep mode. Wifi chip on iOS might follow Wake on Wireless LAN etc. The reason Voip Push is always delivered is because VOIP is guaranteed to be that way, real time! All other non-voip pushes including silent notifications are not reliable & iOS might be dropping them selectively to conserve battery in sleep mode. – Fawnia

Answer 1

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.

Elbert

from documentation: "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." – Haunch

So, it is safe to assume that normal push notifications are useless because there are chances that your app is in killed stage with screen locked and push notification will not awake the device. Whereas VOIP is always the best but apple reject the app if VOIP is used as push. What to do now? – Mattingly

@Mattingly VoIP pushes should only be used to report incoming calls, normal push notifications should be used for everything else. To use VoIP pushes your app must be eligible for that (e.g.: messaging apps with VoIP calls), so apple will reject apps that use it without being eligible to do so. Also, iOS 13 brought new restrictions to VoIP pushes, rendering them useless for reporting things that are not incoming calls. – Toadinthehole

Answer 2

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.

Stpierre

So, it is safe to assume that normal push notifications are useless because there are chances that your app is in killed stage with the screen locked and push notification will not awake the device. Whereas VOIP is always the best but apple reject the app if VOIP is used as the push. What to do now? – Mattingly