Can't keep connection in background with PushKit

Topic: Responding to VoIP Notifications from PushKit

Quote source: https://developer.apple.com/documentation/pushkit/responding_to_voip_notifications_from_pushkit


"After sending the initial push notification, don’t send additional push notifications to cancel the call or communicate new details to your app. Instead, communicate with the app directly over the network connection you established between it and your server"


How do I keep the WebSocket connection for receiving the "call cancellation signal" while the current call is onscreen, whether my user already has answered it or it's still riging? Typically, my WebSocket delegate stops receiving anything after app has gone into background state, even if I configure it with voice, VOiP, background, or callSignaling flags, and bind it to DispatchQueue with qos:background.

Replies

Typically, my WebSocket delegate stops receiving anything after app has gone into background state …

Correct. Shortly after an app is moved to the background, the system suspends it, and network activity on a TCP connection won’t resume it [1]. See Technote 2277 Networking and Multitasking for more.

The standard approach here is to make a new network connection once you’ve resumed in the background because of the VoIP push.

Just as an aside, with regards this:

bind it to

DispatchQueue
with
qos:background
.

you are, alas, off in the weeds. The

.background
QoS means that the queue is doing background work that doesn’t care if it’s delayed for a long time. It has nothing to do with executing in the background.

For detailed information on these queue values, check out the comments in the

<sys/qos.h>
header.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] In fact, on modern system you’ll see socket resource reclaim (per TN2277) triggered immediately by the suspension.

Thank you!


Same time, I've found an interesting approach sending the call cancellation push as background push like so:

content-available=1, sound=silence.


Basically, it could run the app within few minutes.

But in case of call ringing, the app is already in run, so this push delivers immediately.

Gonna check its behavior as it is a bit simplier than recreating the connection in my case.