Mobile App Backend Development: APIs, Auth and Offline Sync
A mobile backend is not a web backend with a different client. It answers requests from devices that lose signal mid-write, run a version of your app from eight months ago, and expect their data to be there when the tunnel ends.
Discuss your projectWhat we build
An API shaped for mobile
Endpoints that return a screen's worth of data in one request rather than making the app assemble it from six. Every round trip costs battery and happens over a connection that may not finish.
Authentication that survives real use
Short-lived access tokens with refresh, credentials in the Keychain or Keystore rather than in app storage, biometric unlock, and social or Sign in with Apple where you offer third-party login. Sessions that do not silently expire and log a field worker out mid-job.
Offline sync
A local database as the app's source of truth, a queue of pending changes, and a defined rule for what happens when the same record changed in two places. Covered below, because it is where these projects succeed or fail.
Push notifications
APNs and FCM behind one sending interface, with device token lifecycle handled — tokens rotate, devices are wiped, users revoke permission. Stale tokens are the usual reason notifications quietly stop.
File and media handling
Direct upload to object storage with pre-signed URLs, so photos do not pass through your application server. Resumable uploads, because a 40MB video on a weak connection will be interrupted.
API versioning
Old app versions keep working. Users do not update promptly, and some cannot — a corporate fleet may be pinned for months. The backend has to serve them while moving forward.
Offline sync, and the question that decides it
Offline support means the app reads and writes a local database and reconciles with the server when a connection returns. The hard part is not the queue. It is deciding what happens when a record was changed on the device and on the server while they were apart.
There are only a few honest answers, and the right one depends on the data. Last write wins is simple and acceptable for a status field where only one person realistically touches a record. Field-level merge works where two people edit different parts of the same record and neither change should be lost. Server authority is correct for anything the server computes, such as price or stock. And for genuinely contested data, the only safe answer is to surface the conflict to a person and ask.
Most offline projects that go wrong went wrong here: a conflict rule was never chosen, so the default — whichever write arrived last — silently destroyed the other one, and nobody noticed for weeks. We agree the rule per record type in writing before building, and we write tests for the conflict cases specifically.
A related point worth settling early: deletes. A record deleted on the server while a device was offline, then edited on that device, needs a defined outcome. Soft deletes with a tombstone make this tractable; hard deletes make it ambiguous.
Firebase or a backend of your own
Firebase is a good product and often the right starting point. This is where the trade changes.
| Firebase / managed BaaS | Custom backend | |
|---|---|---|
| Time to first version | Days | Weeks |
| Cost at low volume | Often free | Hosting, modest |
| Cost at high volume | Rises with reads and writes | Scales with infrastructure |
| Complex queries and reporting | Awkward, often needs data exported | Native to SQL |
| Business logic | Cloud Functions | Anywhere you want it |
| Data residency | Limited regional control | Your choice |
| Leaving later | Export and rebuild the data layer | Not applicable |
| Offline support | Built in, with its own conflict behaviour | Built to your agreed rules |
Our usual advice: start on Firebase if speed to market is what matters and your queries are simple. Build your own when the bill becomes noticeable, when you need reporting the document model fights, or when data residency is a requirement rather than a preference. Pre-emptively avoiding Firebase for a product with no users yet is a false economy.
Hosting
Chosen against what your team can operate once we have handed over, not against what is most interesting to build.
- Managed platforms — Render, Fly.io, Railway, App Engine — where you want a database and a web service and no infrastructure to think about.
- AWS or Google Cloud where you need specific services, a committed-spend agreement, or compliance that names a provider.
- PostgreSQL as the default database, with its own constraints enforcing correctness rather than trusting application code alone.
- Redis for caching and as a job queue broker, once there is enough traffic to justify it.
- Object storage for user media, never the application server's local disk.
Common questions
Related in Mobile App Development
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch