Thank you, Quinn and Kevin, for the detailed inputs.
To clarify what we’ve already tested:
Socket Defuncting (Quinn’s point)
We checked whether the UDP socket becomes defunct when the app goes to the background.
The same socket can still send packets after the PushKit wake.
Outbound DTLS handshake packets are sent successfully.
However, no inbound handshake responses are received until the app moves to the foreground.
We also tried opening a new socket during PushKit wake and observed the same result.
So the issue doesn’t appear to be the socket itself, but rather background network delivery behavior.
App Suspension Timing (Kevin’s point)
To avoid premature suspension, we call:
beginBackgroundTask(withName:)
immediately inside the PushKit callback.
Background task remains active (~30 seconds).
DTLS handshake attempts run within this window.
App is not being suspended before the handshake runs.
Yet the handshake only completes once the app is foregrounded.
This suggests the runtime is available, but inbound DTLS packets are not delivered during background state.
Additional tests we tried
Partial handshake before background
Keeping DTLS/RTP engine alive briefly
Creating a fresh socket
Forcing handshake from a secondary thread
Service Extension path (not viable—no DTLS + port sharing not allowed)
All lead to the same outcome:
DTLS handshake only succeeds once the app is foregrounded.
Topic:
App & System Services
SubTopic:
Networking
Tags: