Background Tasks and App Lifecycle

An app that needs to finish uploading a file, sync offline changes, or refresh cached data cannot assume it gets to keep running once the user leaves it — both iOS and Android treat a backgrounded app as a guest whose welcome expires, on a timeline the app does not control and cannot extend by simply asking nicely. Code that works perfectly while the app is in the foreground and silently fails to complete the moment the user switches apps is one of the most common sources of "it works on my machine" bugs in mobile development, because the foreground testing loop most developers actually run in never exercises the constraint that's actually failing.

The core fact driving everything in this lesson is that neither platform treats "the app should keep doing work" as a request the app gets to grant itself — iOS and Android each expose a small, specific set of mechanisms for background work (a short grace period after backgrounding, a scheduled deferred task, a persistent foreground service), each with real limits on duration, frequency, or user-visibility, and work that doesn't fit one of those mechanisms simply doesn't happen once the app leaves the foreground, no matter how the code is written.

This lesson covers what `AppState` tells you about the app's own lifecycle, what each platform actually allows once the app backgrounds, and the concrete mechanisms — `BGTaskScheduler`-backed background tasks on iOS, `WorkManager` and foreground services on Android — for doing real, deferred, or continuous work correctly within those limits, tying together the push-notification-driven background sync case from Lesson 22 with the constraints that actually govern it.

Analogy🏏Cricket

🏏 Think of it like cricket: A team's twelfth man is allowed onto the field for narrowly defined reasons — carrying out drinks, fielding as a substitute under specific match regulations — and the moment that specific, permitted reason ends, they are expected off the field promptly; they do not get to simply decide, on their own authority, to keep doing extra tasks out there because it seemed useful. A twelfth man who lingered on the field past their permitted window, doing whatever they judged worthwhile, would be overstepping a boundary the match officials actively enforce, not a boundary that's merely a suggestion. A backgrounded app is exactly that twelfth man: it gets a specific, narrow, platform-granted window to finish a specific kind of task, and the moment that window closes, the OS actively suspends or kills its ability to keep running — this is enforced, not requested. Just as the twelfth man's permitted actions are a short, specific list (drinks, a defined fielding role) rather than "anything the team judges useful," a backgrounded app's permitted actions are a short, specific list of platform mechanisms — a background task, a foreground service, a scheduled deferred job — rather than "whatever code happened to still be running." The insight is that operating in someone else's space, on borrowed and time-limited permission, means working within the specific grant you were actually given, not the scope of work you'd ideally like to finish.