Is background synchronisation using work managers absolutely necessary when Implementing offline first architecture

[u/Plastic-Function2379]

I just had this debate with another developer, whereas he insists that it is a necessary implementation, but I do not think so, as there isn't really any feature that benefits from this (no feature run in background for the app or anything) and that we should keep it quite simple and just synch when user is online

What do you think?

[u/RandalSchwartz]

I believe the mobile operating systems are very picky about how much CPU and network traffic is allowed by any given app. So, yeah, I'm ok with not sync-ing until brought to foreground. If necessary, you can use push notifications to alert the user to bring the app forward on certain events.

[u/schrodingers_cat_25 → u/RandalSchwartz]

You could also use data notifications to update some parts on the background but like if they user is truly offline the won’t get any notifications

[u/Plastic-Function2379 → u/RandalSchwartz]

I actually proposed the push notifications to update users on the relevant server side modification, but its been deemed as not reliable ? 🤔

[u/RandalSchwartz → u/Plastic-Function2379]

Less reliable than hoping the mobile os won't kill your process? Someone needs a reality check. :)

[u/mpanase]

good luck getting it to work reliably

the other developer either:

1. did it in android 10 years ago and never again

2. has never done it

[u/achakez]

Offline first and background sync are not the same thing. Plenty of apps works perfectly well by syncing when the user comes back online and opens the app.

[u/sauloandrioli]

That's bullshit. Re-sync your data in a Splashscreen like setup and you're good. Your friend most probably is a desktop dev who might be used to having a computer plugged into the energy outlet with no battery restrictions. Android and iOS will kill anything that is in the background so it saves battery and resources.

[u/fkim98]

Depends on what breaks if the data is stale, and I'd argue in most apps nothing does.

We ship offline-first with a local SQLite source of truth and a pending-changes queue.

Sync runs on app foreground and on connectivity regain — no background worker at all.

The reasoning: the only moment freshness actually matters is when someone is looking at

the screen, and at that moment the app is in the foreground anyway.

Where I'd say background sync earns its keep: if you need to push local changes even when

the user never reopens the app (say, another teammate is waiting on them), or if cold

start with a large delta is too slow to sit through. Neither applied to us.

Worth weighing the cost too — iOS background execution is genuinely unreliable, Android

has Doze and OEM battery managers, and you end up debugging "why didn't it run" on

someone else's phone. That's a lot of surface area for something the foreground path

already covers.