Background Execution in Mobile Development — Essence, Limitations, and Working Principles

What Is Background Execution in Mobile Apps?

Background Execution is the ability of an app to continue running code after the user has minimized it or switched to another app. Without special mechanisms, the mobile OS puts the app into a Suspended state within a few seconds of going into the background, freeing up CPU and memory for active apps.

App States in the Background

A mobile app goes through several lifecycle states: Foreground (active), Background (in the background), Suspended (paused), and Terminated (ended). Background is the only state where the app can execute code without a visible interface. iOS and Android define the duration and available operations in this state differently.

Main Use Cases

Background execution is needed for data synchronization, content downloading, Push notification processing, background geolocation, and audio playback. Synchronization is the most common scenario: the app sends data to the server or downloads updates without user involvement.

• Synchronization — uploading and downloading data when network state changes.
• Geolocation — tracking location in fitness trackers and navigation apps.
• Media — playing audio and video in the background (music, podcasts).
• Notifications — processing Push and local notifications.
• Downloading — downloading large files (podcasts, videos) in the background.

Why Mobile OSes Limit Background Execution

Limitations on background execution are driven by three factors: power consumption, device performance, and user privacy. The CPU and radio modules (Wi-Fi, cellular data) consume the most energy — every background process reduces battery life.

Power Consumption and Battery Life

Google studies show that apps running background tasks every 5 minutes reduce device battery life by 20–30% over a day. Even optimized background operations running once an hour have a noticeable impact if there are more than two such apps.

RAM and Performance

Each background app takes up RAM. When RAM runs low, the system unloads apps from memory, causing a restart when the user returns. iOS uses the Jetsam algorithm — a mechanism that forcibly terminates background processes when the memory limit is exceeded. Android uses LMK (Low Memory Killer) with a similar principle.

User Privacy

Starting with Android 10 and iOS 13, the system requires apps to declare the purpose of background work. Android introduced restrictions on launching Broadcast Receivers in the background. iOS requires specifying Background Mode in project Capabilities. Users can disable background execution for any app in settings.

Background Execution on Android: WorkManager and Foreground Service

Android provides several mechanisms for background execution, each solving a different category of tasks. WorkManager is the recommended API for deferred and periodic tasks. Foreground Service is for immediate execution with a visible notification. JobScheduler is a lower-level alternative to WorkManager.

WorkManager — Universal Solution

WorkManager is part of Android Jetpack, providing background task execution with completion guarantees even after device reboot. The API chooses the optimal execution time based on network state, battery level, and Doze mode. WorkManager is compatible with API 14+ and replaces the deprecated AlarmManager and JobScheduler.

Foreground Service — For Long-Running Operations

When an app needs to perform a task visible to the user (music playback, geolocation recording), Foreground Service is used. The service shows a persistent notification in the status bar and has a higher priority — the system will not terminate it until the task is complete. Starting with Android 13, the POST_NOTIFICATIONS permission is required.

Doze Mode and Battery Optimization

Starting with Android 6.0, the device enters Doze mode when idle. In this mode, network operations, synchronization, and JobScheduler are deferred. WorkManager automatically adapts to Doze — tasks are executed during the next Maintenance Window when the device wakes up for servicing.

Background Execution on iOS: Background Tasks and App Refresh

iOS uses a more strict approach to background execution. Background App Refresh is the primary mechanism for periodic data updates. BGTaskScheduler is the API for scheduling tasks based on system state. For long-running operations, Background Modes are available: audio, location, voip, fetch, and processing.

Background App Refresh

Background App Refresh allows the app to wake up every 15–30 minutes to synchronize data. Wake time depends on user behavior — the system analyzes how often they open the app. Users can disable this feature for individual apps in Settings — General — Background App Refresh.

BGTaskScheduler — Modern Approach

Starting with iOS 13, BGTaskScheduler replaced the deprecated performFetch and beginBackgroundTask. The app registers tasks with an identifier and minimum interval, and the system determines the optimal execution time. Tasks are divided into two types: BGProcessingTask (long-running, 10+ minutes) and BGAppRefreshTask (short, up to 30 seconds).

Execution Time Limits

iOS allocates limited time for background task execution — up to 30 seconds for BGAppRefreshTask and up to 10 minutes for BGProcessingTask. When the limit is exceeded, the system forcibly terminates the task. The developer must call the expiration handler to save intermediate results.

Code Examples: Android WorkManager

Let’s look at a practical implementation of background execution on Android using WorkManager. A data synchronization example every 8 hours with network state awareness. WorkManager guarantees task execution even after device reboot.

class SyncWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        return try {
            syncDataToServer()
            Log.d("Sync", "Data synchronized")
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Run periodic task every 8 hours
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(false)
    .build()

val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(
    8, TimeUnit.HOURS
).setConstraints(constraints).build()

WorkManager.getInstance(context).enqueue(syncRequest)

Foreground Service with Notification

For long-running operations visible to the user, use Foreground Service. A file download example with progress in notification. The service calls startForeground() with a notification that cannot be dismissed. When the download completes — stopForeground(STOP_FOREGROUND_REMOVE).

class DownloadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, id: Int): Int {
        startForeground(NOTIFICATION_ID, createNotification())
        downloadFile()
        stopForeground(STOP_FOREGROUND_REMOVE)
        stopSelf()
        return START_NOT_STICKY
    }
    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, CHANNEL_ID)
            .setContentTitle("Download file")
            .setSmallIcon(android.R.drawable.ic_download)
            .build()
    }
}

Code Examples: iOS BGTaskScheduler

On iOS, background execution is configured through BGTaskScheduler. An example of registering and executing a content update task. The app must register the task identifier in Info.plist and call submit when the task should be scheduled.

import BackgroundTasks

func registerBackgroundTask() {
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.app.refresh",
        using: nil
    ) { task in
        self.handleAppRefresh(task: task as! BGAppRefreshTask)
    }
}

func scheduleAppRefresh() {
    let request = BGAppRefreshTaskRequest(
        identifier: "com.app.refresh"
    )
    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

func handleAppRefresh(task: BGAppRefreshTask) {
    scheduleAppRefresh()
    task.expirationHandler = {
        // Save intermediate data
        cacheCurrentState()
    }
    fetchLatestData {
        task.setTaskCompleted(success: true)
    }
}

Background Processing Task

For long-running operations (cache cleanup, data processing), use BGProcessingTask. The system gives up to 10 minutes for execution. It only runs when the device is charging and connected to Wi-Fi. Requires a separate identifier in Info.plist and registration via register(forTaskWithIdentifier:).

func scheduleProcessing() {
    let request = BGProcessingTaskRequest(
        identifier: "com.app.cleanup"
    )
    request.requiresExternalPower = true
    request.requiresNetworkConnectivity = true
    request.earliestBeginDate = Date(timeIntervalSinceNow: 24 * 60 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

Comparing Android and iOS Approaches

Android and iOS differ fundamentally in their background execution philosophy. Android provides flexible tools with greater control but requires the developer to choose the right API. iOS limits capabilities but guarantees stable performance and battery life for the user.

When to Choose Android WorkManager

WorkManager is optimal for tasks that must be completed regardless of app state: data synchronization, analytics delivery, queue processing. The API guarantees execution even after device shutdown — the task is rescheduled after boot.

When to Choose iOS BGTaskScheduler

BGTaskScheduler is suitable for tasks the system can perform at any convenient time: downloading new content, updating widgets, clearing cache. Not suitable for urgent operations — the system delays the task if the device is in Doze or has low battery.