An app goes to the background. What can it still do, and how do you choose a mechanism?
Predict first
You must keep downloading a 2 GB file after the user leaves the app. What do you use?
// A: beginBackgroundTask
// B: a background URLSession
// C: a Timer- A
- B
- C
Mental model. The background is a set of service hatches, each for one purpose. You pick the right hatch and hand in your request, and the staff decide when to deal with it.
Within seconds of backgrounding the app is suspended: it executes nothing and holds no CPU. To do more, you use one of a small set of sanctioned mechanisms, and the right one depends on what the work is. To finish something already in progress (saving, a request) you start a background task with beginBackgroundTask, which grants a short grace period (about half a minute) and an expiration handler. For periodic refresh, BGAppRefreshTask; for long maintenance (syncing, indexing, ML), BGProcessingTask, which the system runs when the device is idle or charging. For network transfers that must continue even if the app is not running, a background URLSession.
Other mechanisms exist for specific kinds of app: silent push (content-available) wakes you briefly, location, audio, Bluetooth and VoIP modes keep an app alive for their purpose and are reviewed for genuine use. The unifying rule: the system schedules by battery, thermal state and user behaviour, nothing is guaranteed, and work you cannot finish must be resumable. Design every background job as “do a bit, save progress, expect to be stopped”.
A background session hands the transfer to a system service, so it continues even if your process is suspended or terminated.
| Use it for | Time you get | |
|---|---|---|
beginBackgroundTask | finishing work already started | about 30 seconds |
BGAppRefreshTask | short, periodic content refresh | about 30 seconds, system-timed |
BGProcessingTask | long maintenance, sync, indexing | minutes, when idle or charging |
background URLSession | uploads and downloads | transfer continues without your process |
| silent push | a wake-up when something changed | brief, and throttled |
| location, audio, VoIP, Bluetooth | features that genuinely run continuously | while the feature is active |
Common traps
- Starting a background task and never ending it. The system terminates the app when time runs out, and counts it against you.
- Declaring a background mode “just in case”. App Review checks that the mode is really used.
They might follow up with
- What is the grace period for? Finishing in-flight work cleanly, such as writing a file or ending a request, not for new long jobs.
- Which one for “sync every hour”? A refresh task requested through the scheduler, understanding the system chooses the time.
Related questions
- 6.5.3 How does BGTaskScheduler work, and why does your task not run when you ask?
- 6.5.4 How does a background URLSession keep working when the app is not running?
- 6.2.1 What are the app states, and which callbacks fire as you move between them?
What do the audio, location, VoIP and remote-notification background… →