What do the audio, location, VoIP and remote-notification background modes allow, and what is the catch?
Predict first
A VoIP push arrives and the app does not report an incoming call to CallKit. What happens?
// A: nothing, the push is ignored
// B: the app is terminated and VoIP pushes to it are withheld
// C: the call is shown automatically
- A
- B
- C
Mental model. Each mode is a special pass for one purpose, like a delivery driver’s pass. It works for deliveries, and the building checks that you are really delivering.
Declaring a mode in UIBackgroundModes lets the app keep running (or be woken) for that purpose. Audio: the app can keep playing while backgrounded, only while an audio session is active. Location: continuous updates in the background (with “Always” authorisation), or cheap wake-ups from significant-change and region monitoring. Bluetooth: wake to handle events from a connected peripheral. Remote notification (content-available pushes): a short wake-up to fetch fresh data, throttled by the system. VoIP is the strictest: since iOS 13, a VoIP push through PushKit must immediately report an incoming call to CallKit, or the system terminates the app and stops delivering VoIP pushes to it.
The catch is that these are purpose-bound and reviewed. Using the audio mode to keep a timer alive, or location to stay running, violates the rules and invites rejection or removal. They also cost battery, so use the lowest-power form that does the job (significant-change instead of continuous location). Legacy fetch (performFetch…) is deprecated in favour of BGAppRefreshTask. Always handle the case where the system never wakes you, because every one of these is best effort.
The system treats it as abuse of the VoIP channel, so it kills the app and stops delivering further VoIP pushes.
Common traps
- Using VoIP pushes for ordinary notifications. The app must report a call every time, or it is terminated and cut off.
- Asking for “Always” location when “While Using” is enough. Users deny it, and review pushes back.
They might follow up with
- Where are the modes declared? In the target’s Background Modes capability, which writes
UIBackgroundModesintoInfo.plist. - What replaced background fetch? The
BGTaskSchedulerrefresh and processing tasks.
Related questions
- 6.5.1 An app goes to the background. What can it still do, and how do you choose a mechanism?
- 6.7.1 What is Info.plist for, and which keys matter most?
← An app goes to the background. What can it still do, and how do you… How does BGTaskScheduler work, and why does your task not run when… →