WorkManager vs BGTaskScheduler: Android and iOS

In short: WorkManager promises to run your work later, when its rules are true. BGTaskScheduler promises no exact time, and iOS decides for you.

The question

Many people ask for "the iOS version of WorkManager". I think this question hides the real problem. The two systems make different promises, so one cannot replace the other.

On Android, you hand the system a job and a set of rules. The system keeps the job and runs it when the rules are true. On iOS, you ask for a chance to run. The system may give it to you, or it may not. [Opinion]

This guide names the promise of each tool. Then it shows how I choose. I use the same words as the chat app case. A background task here means code that runs when the user is not looking at the screen.

The two promises side by side

Question	Android WorkManager	iOS tools
Does the work survive a restart?	Yes. The work stays saved across app restarts and phone restarts.	The system keeps your request, but it may never run it. Your app keeps its own list of work.
Who chooses the time?	Your rules and the system together.	The system alone.
Can I set rules?	Yes: network type, battery, charging, idle.	Only hints, such as needs network or needs power.
Retry after failure?	Built in, with backoff.	You write it.
Work that must start now?	Expedited work, with a quota.	Not promised. Start it while the app is on screen.
Long work?	Foreground service, with time limits.	`BGProcessingTask`, or a background `URLSession`.

[Opinion] This table is my summary. The facts behind each cell are in the next two sections.

When I would choose which

I start from the user and the data, not from the tool.

A message or order the user just made. Android: expedited work, with a normal work fallback. iOS: send it now, and keep it in your own saved list until the server confirms it.
A large upload that the user started. Android: a foreground worker, or a user-initiated data transfer job. iOS: a background URLSession, or BGContinuedProcessingTask on iOS 26.
A backup the user did not just ask for. Android: constrained WorkManager work. iOS: a background URLSession, and no promise about when it ends.
Small updates to fresh content. Android: periodic work. iOS: BGAppRefreshTask, and treat it as a bonus.
Heavy work such as hashing or cleaning a database. Android: a worker with constraints. iOS: BGProcessingTask.
A server that must wake the app. Android: a high priority FCM message. iOS: a visible push, not a silent push.

In every row, the correct result must not depend on the background run. The next time the user opens the app, it must catch up. [Opinion]

Mistakes I see

This is my reading of how people design these systems. It is not a claim about any company.

They write one design for both platforms. The Android design assumes a saved job. The iOS version then loses work.
They use a silent push to carry data. A silent push is only a hint (more below).
They promise a delivery time. On both platforms the system can delay your work.
They forget that a retry can repeat a request. The server must treat a repeat as the same request (idempotent: doing it twice has the same result as once).
They keep a foreground service just to hold a connection open. It costs battery and can break store rules.
They test only with the app open and the phone charging. The real rules appear when the phone is idle.

[Opinion] for the whole list.

On Android

WorkManager is the tool Google recommends for tasks that continue after the app leaves the screen. It stores work so that the work survives app restarts and phone restarts (Task scheduling). [Verified: developer.android.com, 2026-10-14]

The rules are called constraints. They include the network type, a battery that is not low, and other states (Define work). [Verified: developer.android.com]

The exact run time still depends on your constraints and on system optimizations, and a periodic job cannot repeat faster than every 15 minutes (Define work). [Verified: developer.android.com]

When a worker returns a retry result, WorkManager waits and tries again. The default is exponential backoff (the wait grows after each failure) from 30 seconds. The smallest wait is 10 seconds (Define work). [Verified: developer.android.com]

Expedited work is for important tasks that finish within a few minutes. A system quota decides if it can start. You can ask for normal work when the quota is used up. In the foreground, the quota does not limit it (Define work). [Verified: developer.android.com]

For work that can run longer than 10 minutes, a worker calls setForeground(). WorkManager then runs a foreground service for you. On Android 16, such long workers can use up the job quota of the app. For a transfer that the user starts, Google suggests a user-initiated data transfer job instead (Long-running workers). [Verified: developer.android.com]

On Android 15, a dataSync foreground service may run for 6 hours in 24 hours. Then the system calls onTimeout(), and the service must stop (Foreground service timeouts). [Verified: developer.android.com]

On Android 16, the run time quota of regular and expedited jobs depends on the standby bucket of the app. This affects WorkManager. Google advises that you log WorkInfo.getStopReason() (Android 16 behavior changes). [Verified: developer.android.com]

While Doze (the deep sleep of an idle phone) is on, WorkManager tasks do not run, because WorkManager uses JobScheduler (Doze and App Standby). [Verified: developer.android.com]

On iOS

BGTaskScheduler lets an app ask the system for background time. Its page says background tasks let code run even when the app is suspended (BGTaskScheduler). [Verified: Apple documentation JSON, 2026-10-14]

BGAppRefreshTask is for small updates, such as the latest stock values (BGAppRefreshTask). Apple says the system decides the best time and gives up to 30 seconds (Choosing background strategies). [Verified: Apple documentation]

BGProcessingTask is for long data work and maintenance. It can run for minutes, but the system can interrupt it. It runs only when the device is idle. The system ends it when the user starts to use the device (BGProcessingTask). [Verified: Apple documentation]

BGContinuedProcessingTask starts in the foreground and can continue in the background. It is new in iOS 26. The system shows its progress in a Live Activity, and the person can cancel it. The system can end it at any time, and it ends tasks with little progress first (BGContinuedProcessingTask). [Verified: Apple documentation]

A background URLSession hands a transfer to the system. The transfer continues while your app is suspended. If the system ended the app, it starts the app again, and you must create the session again with the same identifier. Uploads must come from a file (Downloading files in the background). [Verified: Apple documentation]

The isDiscretionary setting lets the system pick a better time, such as Wi-Fi and power. It has no effect on transfers that start while the app is in the background (isDiscretionary). [Verified: Apple documentation]

A silent push (a push with no alert) has low priority, and Apple does not guarantee it. The system may slow it down. Apple advises no more than two or three per hour. If the user force-quits the app, the system discards a held silent push (Pushing background updates). [Verified: Apple documentation]

See it in a case

Chat app: WorkManager sends the pending message. On iOS I keep my own outbox. See the case and the build guide.
Photo and file sync: the choice by who started the upload. See the case and the build guide.
Analytics SDK: a flush that cannot rely on a background run. See the case and the build guide.
Push SDK: token upload and the limits of silent push. See the case and the build guide.
Tool: the retry simulator shows how many copies of a message the server saves when a reply is lost and the app retries.

Words used here

Sources

Words on this page (10)

BGProcessingTask: A kind of iOS background task for long work. The system decides when it runs, often when the phone is idle.
Doze: The deep-sleep mode of an idle Android phone. It pauses network access and delays background work.
Exponential backoff: Waiting longer after each failure. For example, wait 1 second, then 2, then 4.
FCM: Firebase Cloud Messaging, the push service from Google. On iOS it passes the push to APNs.
Foreground service: An Android service that shows a notification while it works. The system is less likely to stop it.
Idempotent: Doing it twice has the same result as doing it once. This makes a retry safe.
Outbox: A saved list of changes that the server has not confirmed yet. The app sends them later, even after it restarts.
SDK: Software development kit. Code that other developers add to their own apps.
Silent push: A push with no visible alert. The system can delay it or drop it, so treat it only as a hint.
WorkManager: Android's tool for background work that must run later. The work survives when the app closes or the phone restarts.

Read the whole glossary

Verification notes (last reviewed 14 Oct 2026)

written on 2026-10-14. Each claim has a tag. Verified means I fetched the raw page text on 2026-10-14 (HTML from developer.android.com, the JSON endpoints behind developer.apple.com) and read the sentence. I verified: WorkManager persistence across restarts, constraints, the 15 minute periodic minimum, the backoff defaults (30 s, 10 s minimum), expedited work and its quota, the 10 minute long-running note and the Android 16 quota note, the 6 hour dataSync limit, the Android 16 job quota change, Doze and WorkManager, the BGTaskScheduler task types, the 30 second app refresh time, the BGContinuedProcessingTask text and iOS 26 start version, background URLSession behavior, isDiscretionary, and the silent push text. I did not verify: that a force-quit stops background URLSession transfers (the page I read does not say it), how Android treats a force-stop for WorkManager, exact iOS scheduling rules or how often iOS runs a refresh task, and whether the foreground service store-rule risk is real (that line is an opinion). The comparison table, the choices and the list of mistakes are my opinion and do not describe any company. The case pages were read in the repository and not fetched again.

Keep reading

Get the free one-page cheat sheet

One page: the five steps, a 45-minute time plan and two checklists. Print it or keep it on your phone.

We email you the cheat sheet after you confirm your address. You can also open it now from the Start here page. You get a short note when a new case is published. Unsubscribe any time. Privacy.