iOS multitasking is often misunderstood because it deliberately doesn’t work like desktop multitasking. Apple designed iOS from the very beginning around a core constraint: mobile devices have limited battery, limited RAM, and limited thermal headroom, and users generally care more about long battery life and a smooth, responsive foreground app than about arbitrary background apps running freely. This article explains, in depth, exactly how iOS manages background execution and multitasking, from the early single-app-at-a-time model to the sophisticated system of background modes, task assertions, and scheduling APIs used today.
The Foundational Philosophy: Foreground-First
Unlike desktop operating systems such as Windows, macOS, or Linux — where any process can, in principle, run indefinitely in the background consuming CPU — iOS treats the app the user is actively looking at (the foreground app) as the highest priority resource consumer, and treats every other app as a guest that must justify why it needs to keep running. This is a fundamental architectural choice, not just a policy setting.
When you press the Home button, swipe up, or switch to another app, the app you left doesn’t necessarily keep running in the traditional sense. iOS decides, based on a combination of rules and system state, whether that app should be:
- Suspended: frozen in memory, consuming no CPU, but instantly resumable
- Allowed limited background execution: given a short window or specific permission to keep doing something
- Terminated: removed from memory entirely to free up resources for the foreground app
App States in iOS
iOS defines several distinct execution states for every app, and understanding these states is the key to understanding background process management:
- Not Running: The app has not been launched, or was terminated by the system or the user.
- Inactive: The app is in the foreground but not currently receiving events (e.g., during a transition, or when an interruption like a phone call occurs).
- Active: The app is in the foreground and running normally, receiving user input.
- Background: The app is not visible on screen, but is executing code — either because it registered for a background task, or because it’s momentarily finishing up work before suspension.
- Suspended: The app is in memory, but is not executing any code at all. The OS can purge suspended apps from memory at any time without warning, without calling any app code, if the system needs the RAM for something else.
This last state, Suspended, is critical to understanding iOS: the vast majority of apps you’ve “left” but not force-quit are actually sitting frozen in RAM, not actively consuming CPU or battery, ready to be instantly resumed exactly where you left off — until the OS decides it needs that memory and purges the app silently.
Background Execution: Why Most Apps Don’t Just Keep Running
By default, when a user leaves an app, iOS gives it a short grace period (historically around a few seconds) to save state and clean up, and then suspends it. If an app wants to do more than that — download a file, play audio, track location — it must explicitly use one of Apple’s sanctioned background execution APIs. This is a deliberate whitelist approach: nothing runs in the background unless the developer requested a specific, documented capability, and the user (in some cases) granted permission.
Legacy Background Task API
beginBackgroundTask(withName:expirationHandler:) lets an app request a limited amount of extra time (historically up to a fixed number of minutes) to finish a specific, short operation — such as completing an upload that was in progress when the user left the app. iOS tracks this as a “background task assertion.” When the time expires, or the task completes, iOS suspends the app.
Declared Background Modes
Apps can declare specific background modes in their configuration (the Info.plist file, under UIBackgroundModes), each unlocking a narrow, purpose-built capability:
- Audio: Apps that play audio (music players, podcast apps) can continue running in the background specifically to keep audio playback going.
- Location updates: Apps with a legitimate need for continuous location tracking (navigation apps, fitness trackers) can request background location updates, subject to explicit user permission prompts.
- VoIP: Apps supporting internet calling can maintain a persistent connection to receive incoming call notifications.
- Background fetch: Apps can periodically wake up briefly to fetch new content, with the OS deciding the actual schedule based on usage patterns and battery conditions, not a fixed developer-defined interval.
- Remote notifications: Apps can wake briefly upon receiving a silent push notification to fetch new data before displaying a local notification.
- Bluetooth accessory communication: Apps interacting with paired Bluetooth accessories can maintain that connection in limited circumstances.
Each of these is narrowly scoped. An app cannot simply declare “let me run forever in the background doing arbitrary work” — it must fit into one of these specific, system-mediated categories, and the system retains ultimate control over scheduling and can throttle or suspend the app regardless of its declared intent if resources are constrained.
Background App Refresh
Background App Refresh is the user-facing setting (Settings → General → Background App Refresh) that governs whether apps are allowed periodic background fetch opportunities at all. iOS uses on-device machine learning to predict when you’re likely to open a given app next, and preferentially grants background refresh time to apps it predicts you’ll use soon — rather than treating all apps equally. This means two users with the same apps installed may see very different background refresh behavior based on their individual usage patterns.
Background Processing Tasks (BGTaskScheduler)
Modern iOS (since iOS 13) consolidated much of this under the BackgroundTasks framework, specifically BGTaskScheduler, which offers two main task types:
BGAppRefreshTask: Short, quick background updates, similar to the older background fetch mechanism.BGProcessingTask: Longer-running maintenance-style tasks (e.g., database cleanup, machine learning model updates) that iOS schedules opportunistically — typically when the device is plugged in, connected to Wi-Fi, and idle overnight — rather than whenever the app requests it.
This scheduler-based model reflects Apple’s broader philosophy: developers request background work with hints about what’s needed, but the OS makes the final call about exactly when that work actually executes, based on system-wide resource optimization.
The Role of Push Notifications in Reducing Background Work
A major architectural technique iOS uses to minimize unnecessary background execution is offloading “is there anything new?” checks to Apple’s servers via the Apple Push Notification service (APNs). Rather than every app polling its own server every few minutes (which would be a battery and network disaster at scale), a server-side event triggers a push notification, which briefly wakes the relevant app (if the app supports “remote notifications” background mode) to fetch and display new content. This shifts the “polling” burden off the device entirely and onto the network/server infrastructure, dramatically reducing background CPU and radio usage on the device itself.
Multitasking UI: The App Switcher
The visual multitasking interface — swiping up and holding to see the App Switcher’s card stack — is a user-facing view of recently used apps, most of which are actually suspended, not actively running. Swiping a card away in the App Switcher force-terminates that app, removing it from memory entirely (and, for apps using specific background modes like audio or location, actually stopping that background activity). This is different from simply switching away from an app, which merely triggers eventual suspension, not termination.
Split View, Slide Over, and Stage Manager (iPadOS)
On iPad, true simultaneous multitasking (multiple apps visibly active on screen at once) is supported through Split View, Slide Over, and, on more capable hardware, Stage Manager, which allows several resizable app windows and even external display support. Even here, though, Apple’s underlying resource management principles apply: apps not currently visible in this configuration are still subject to the same suspension/background execution rules as single-app multitasking on iPhone, just with more of them potentially visible (and thus foreground-active) simultaneously.
Comparison: iOS vs. Android vs. Desktop Background Models
| Aspect | iOS | Android | Desktop (Windows/macOS/Linux) |
|---|---|---|---|
| Default background behavior | Suspended (frozen), not running | Cached/frozen with more granular process states | Fully running unless closed |
| Arbitrary background CPU work | Not allowed without a declared background mode | More permissive historically, now restricted (Doze, App Standby) | Fully allowed |
| Background scheduling control | OS decides exact timing (BGTaskScheduler, background fetch) | OS + WorkManager-style scheduling with more developer control | User/app has direct control |
| Silent app termination for memory | Yes, at any time, no warning | Yes, via the Low Memory Killer/ActivityManager | Rare; usually requires explicit user action or crash |
Practical Example
Consider a podcast app: while playing audio, it continues running because it declared the “Audio” background mode. If you switch to a different app afterward without stopping playback, the podcast app remains in the Background execution state, actively using CPU/audio hardware. If you pause playback and switch away, iOS will typically suspend it shortly after. If, days later, you open many memory-heavy apps, iOS may silently purge the suspended podcast app from memory entirely — the next time you open it, it will cold-launch rather than resume instantly, though it will typically restore your playback position via saved state, since well-behaved apps persist state to disk, not just memory.
Best Practices for Developers
- Use the most specific background mode that matches your actual need — don’t request “audio” background mode just to sneak in unrelated background work, as Apple’s App Review process screens for this.
- Persist critical state to disk regularly, since suspension (and especially termination) can happen without warning; never rely on in-memory-only state surviving indefinitely.
- Use
BGTaskSchedulerfor maintenance-style work rather than trying to keep the app alive continuously — fighting the system’s scheduling model generally fails and drains battery unnecessarily on the rare occasions it does briefly work. - Prefer push-notification-triggered fetches over app-initiated polling wherever a server-driven event model is feasible.
Troubleshooting Tips
- App loses state after backgrounding: Usually indicates the app isn’t persisting state to disk proactively and is relying on memory surviving suspension, which iOS does not guarantee.
- Background App Refresh not triggering: Check Settings → General → Background App Refresh is enabled both globally and for the specific app; also note that Low Power Mode disables background refresh system-wide.
- Excessive battery drain from a specific app: Check Settings → Battery for per-app background activity breakdown, which can reveal an app abusing (or being throttled for abusing) a declared background mode.
FAQs
Q: Does closing an app from the App Switcher save battery? A: Generally no, for most suspended apps, since they weren’t consuming meaningful battery while suspended. It can help in specific cases where an app is misbehaving and stuck in an active background state.
Q: Can an app run indefinitely in the background on iOS? A: Not through officially sanctioned APIs, except in narrow cases like continuous audio playback or approved continuous location tracking, both of which are visible to the user (e.g., a status bar indicator).
Q: Why do some apps refresh content instantly while others take a while? A: iOS uses on-device prediction of your usage patterns to allocate background refresh opportunities preferentially to apps it expects you to open soon.
Q: Is iOS multitasking “less capable” than Android’s? A: It’s differently designed — iOS trades some background flexibility for stronger battery life and predictability guarantees, while Android has historically allowed more background latitude at a potential battery cost, though both platforms have converged somewhat over time with Android’s own aggressive battery optimization features.
Summary
iOS manages background processes and multitasking through a carefully controlled, whitelist-based system: apps are suspended by default the moment they leave the foreground, and can only continue executing in the background if they declare a specific, narrow background mode (audio, location, VoIP, background fetch/processing, remote notifications) or hold a short-lived background task assertion. The OS, not the app, retains ultimate control over scheduling, using on-device prediction and system-wide resource state to decide when and how much background execution to grant. This foreground-first philosophy, combined with heavy reliance on push notifications to avoid unnecessary polling, is central to how iOS achieves industry-leading battery efficiency and consistent foreground app responsiveness.
References
- Apple Developer Documentation — App States and Multitasking: https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle
- Apple Developer Documentation — BackgroundTasks framework: https://developer.apple.com/documentation/backgroundtasks
- Apple Developer Documentation — Background Execution: https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background
- Apple Human Interface Guidelines — Multitasking (iPadOS): https://developer.apple.com/design/human-interface-guidelines/multitasking