Background Tasks and App Lifecycle: What iOS and Android Allow Now
On a fitness tracking app that needed to log GPS data during a background run, we initially relied on iOS's legacy background location updates alone and found the OS silently reduced update frequency after about 10 minutes to preserve battery, even with 'Always' location permission granted. The fix was switching to CLLocationManager's significant-change and region-monitoring APIs combined with the 'fitness' background mode entitlement, which iOS treats as a genuine ongoing-activity signal rather than opportunistic background work.
BGTaskScheduler on iOS replaced the older background fetch API, and it's a request, not a guarantee — the system decides when, or if, a scheduled refresh task actually runs, based on usage patterns it learns per app. We stopped assuming a 15-minute sync interval and instead designed the sync logic to be idempotent and safe to run whenever the OS grants a window, sometimes hours apart for infrequently opened apps.
Android's Doze mode and App Standby Buckets sort apps into activity tiers — active, working set, frequent, rare, restricted — that throttle background execution and network access accordingly. An app a user hasn't opened in two weeks gets bucketed into 'rare,' where background jobs might only run once a day. For our fitness app's Android build, this meant WorkManager jobs needed explicit user-facing messaging — 'sync happens when you open the app' — rather than promising silent background sync we couldn't reliably deliver.
Push-triggered background execution is the more reliable pattern on both platforms now. A silent push — content-available on iOS, high-priority FCM data message on Android — wakes the app for a short execution window to fetch fresh data, which held up far better in our testing than relying on scheduled background tasks alone, though iOS caps how many silent pushes per hour it'll actually honor before rate-limiting them.
The overall shift we've internalized across projects is to treat background execution as best-effort enhancement, never a dependency for core functionality. Anything the user actually needs — an alert, a critical data sync — should have a foreground or push-notification path that doesn't rely on the OS deciding to grant background time.
