Mobile app backend, APIs and offline sync: an architecture for apps that keep working

This guide is for CTOs, technical leads and product owners planning the server side of an app. Our mobile product development guide covers the whole road from discovery to scale in brief; this page goes deeper into the backend, the API contract and offline sync. How the app itself is built is compared in native vs cross-platform mobile development.

In this guide

• What a mobile backend must handle that a website does not
• The API contract for mobile clients
• Offline sync: four models
• Conflicts and who decides
• Sign-in, push and device security
• Backend routes: alternatives and selection criteria
• AI features and the backend
• A build plan
• How Netbase builds mobile backends
• What delivery record exists, and what does not
• Limits of this guide
• Frequently asked questions
• Next step

What a mobile backend must handle that a website does not

A website changes for every visitor the moment you deploy. A mobile app does not: people update when they choose, and some never do. Three consequences shape the backend.

• Many client versions at once. The server must answer every app version you still support, so a renamed field or a new required parameter can break thousands of installed apps overnight.
• Networks that fail halfway. A request can reach the server and lose its answer on the way back. The app retries, and a careless backend creates a second order or a second payment.
• Work that happens away from the server. Field staff, travellers and shoppers in basements open the app with no signal and expect it to work, then expect their changes to arrive later without overwriting anyone else's.

The API contract for mobile clients

Treat the API as a product with its own rules, not as a by-product of the web front end.

• Version deliberately. Add fields freely, but never remove or rename one while a supported app version reads it. Put breaking changes behind a new version, publish a minimum supported app version, and let the backend tell older apps to update.
• Shape responses for the screen. A backend-for-frontend layer, a thin service that assembles exactly what one screen needs, saves round trips on slow networks and keeps internal systems out of the app's view.
• Page with cursors. Page lists with a cursor rather than an offset, so records added while a user scrolls are not shown twice or skipped.
• Make creates safe to repeat. RFC 9110 defines POST as not idempotent, so every create carries an idempotency key generated on the device; the server stores it with the result and returns the first result to a retry.
• Send what the device needs. Resize images per device, compress responses and send only changed records since the app's last sync marker.
• Return errors the app can act on. A stable error code tells the app whether to retry, re-authenticate or stop.

When the same backend also serves the website, partners and internal systems, the rules for those flows are in our enterprise systems integration guide.

Offline sync: four models

Pick a model per kind of data: a catalogue, a draft form and a payment need different guarantees.

• Online only, with a read cache. The app shows the last data it fetched and blocks changes while offline. Right for prices, stock and anything that must be current.
• Queued writes. Changes are stored in an outgoing queue and sent in order when the connection returns. Android's offline-first guide lists this pattern for data such as analytics events and logs.
• Local-first data. The app reads and writes a local database, and a sync process exchanges changes with the server. Android's guide calls the local source "the canonical source of truth for the app"; this suits notes, inspections and field records.
• A managed sync service. A platform keeps a local database and the server copy in step and supplies conflict handling, at the price of adopting its data model.

Sync itself runs either on demand (pull) or with the server notifying the app of changes (push); Android's guide recommends pull for short gaps and push for long offline periods and related data.

Conflicts and who decides

When two people change the same record while one of them is offline, something has to win. Decide it per field, in writing, before the first build.

• Last write wins. Each change carries a timestamp and the newer one is kept. Simple, and right for data one person owns, such as a profile or a draft.
• Server rules. The backend accepts a change only if the record still has the version the device saw; otherwise the app shows the current state and asks the user.
• Merge by field. Changes to different fields both survive; only a clash on the same field needs a rule.
• Never offline. Payments, stock reservations and approvals are confirmed by the server while online, whatever the rest of the app does.

Keep a server sync log of device, user, version and outcome, so support can explain what happened to a record.

Sign-in, push and device security

Sign-in. A mobile app cannot keep a secret: IETF RFC 8252 classifies native apps as public clients and requires the PKCE extension for OAuth, with the sign-in page opened in the system browser rather than an embedded web view. Use short-lived access tokens with refresh tokens kept in the platform's secure storage, and offer biometric unlock on top.

Push. Firebase Cloud Messaging describes itself as a cross-platform messaging solution, with notification messages the system shows and data messages the app handles itself. Send data messages to tell the app to sync, notifications for what the user must see, and ask for permission at a moment the user understands.

Security. The OWASP Mobile Application Security Verification Standard groups the controls for storage, cryptography, authentication, network communication and resilience. On the server, every endpoint checks the user's rights itself, whatever the app shows or hides.

Backend routes: alternatives and selection criteria

Four criteria settle it: who owns the data today, how much of the product works offline, how many systems the app must reach, and who will run the backend at night. When the backend must also talk to a store, an ERP and a CRM, design those flows first with ERP, CRM and e-commerce integration architecture; Netbase's systems and API integration service builds that layer.

How Netbase builds mobile backends

Netbase builds cross-platform apps with React Native, a role it has long hired for, on the stack described on our backend platforms page. Teams of 3 to 30 combine analysts, architects, developers, QA and designers, and work typically starts within 1 to 2 weeks after discovery. Most Netbase projects are delivered on fixed-price contracts agreed after discovery (see dedicated team vs fixed price), and in custom development the client owns the IP created for it. Security practice covers secure code review, TLS in transit and AES at rest, role-based access control and MFA for admin dashboards. See the mobile app development service, or the mobile product accelerator when reusable building blocks fit.

What delivery record exists, and what does not

• What exists. The RB Marketplace record describes a customer shopping app built on the marketplace's own API after an API audit, with push notifications, a wishlist synced to the server and offline browsing, for Android with iOS in the extended scope. The Dey Page record describes one React Native app for iOS and Android on the same backend as the web directory, with phone OTP accounts, push and deep links; its field capture with offline sync runs in the mobile web app. The reward shop record describes mobile UI components for the client's own apps and sync with the client's systems by webhooks and a scheduled sync; the client is not named.
• What does not. None of these records publishes downloads, usage, uptime, sync volumes or error rates, and the RB Marketplace record names no framework. None is offered as proof that one sync model or backend route performs better.

Limits of this guide

• Platform statements come from the Android, IETF, Firebase and OWASP pages on the access date; platforms change, so check the current versions.
• The sync models suit business, commerce and field apps; real-time collaboration and games need their own design.
• Security practices reduce risk; they are not a guarantee about any app or backend.

Next step

Share which data your app must keep offline, the systems it reads from and the app versions already in use, and we will book a solution review to map the API contract and a sync model per data type. You can also see mobile app development or more Netbase insights.

Related services and solutions