Background Work on Mobile
Work scheduled outside the foreground session, which mobile operating systems aggressively restrict to protect battery life.
The recurring mistake is designing background behaviour as though the application controls its own execution. It does not. Both major mobile platforms will defer, batch or refuse background work based on battery state, network conditions, and how recently the user opened the application — and an app the user rarely opens gets progressively fewer opportunities to run.
What follows for architecture: background sync must be treated as opportunistic and unpredictable rather than scheduled. Anything time-critical needs a server-initiated push, and even a push is a hint rather than a guarantee — delivery is best-effort, may be delayed, and can be dropped entirely.
Consequences to design in. Never assume a background task completed; the application must reconcile on next foreground. Batch work into infrequent larger operations rather than frequent small ones, which is both what the operating system rewards and what preserves battery. Make every background operation resumable and idempotent, because it will be killed mid-execution routinely.
And for anything that genuinely must happen — a payment confirmation, a safety alert — the server must own the outcome and the device must be a notification target rather than the executor. Systems that put the critical step on the device discover the gap in the field, unevenly, and blame the network.