A mobile app does not usually contain your business logic or hold your data. Instead, it acts as a specialised interface that talks to the same server-side system your web application uses. The connection between them is an API — a set of rules that lets the mobile app request data, submit changes and trigger processes on the backend.

From the backend's perspective, a request from a mobile app looks much the same as a request from a web browser. Both send structured messages, typically in JSON format, over HTTPS. The backend processes the request, checks permissions, runs the relevant logic and returns a response. The difference lies in how each client is built and how it handles things like authentication, offline states and device-specific features.

This shared-backend approach is what allows a business to run a CRM system where office staff use a web browser and field workers use an iPhone app, both working with the same customer records, workflows and audit trail. The backend is the single source of truth; the mobile app is simply another way to interact with it.

The role of authentication tokens

Web applications often use session cookies managed by the browser. Mobile apps typically use token-based authentication — the user logs in, the backend issues a token (commonly a JWT), and the mobile app includes that token with every subsequent request. These tokens expire, so the app must also handle refresh logic without forcing the user to log in repeatedly. This is a practical detail that affects user experience and needs to be planned rather than left as an afterthought.

API design for multiple clients

If a backend was originally built to serve a single web application, its API may return more data than a mobile screen needs, or it may be structured around page loads rather than discrete actions. When a mobile app is added later, the API often needs adjustment: endpoints may be refined, pagination added, and response payloads trimmed to reduce mobile data usage. In some cases, businesses choose to build a separate mobile-specific API layer that sits in front of the existing backend, translating between what the mobile app needs and what the legacy system provides.

When a mobile frontend adds genuine value

Not every web application needs a mobile companion. A mobile app is justified when users need to interact with the system in contexts where a laptop is impractical: inspecting assets on site, capturing signatures, scanning barcodes, receiving push notifications about time-critical tasks, or working in areas with intermittent connectivity. If the mobile use case is simply "viewing a dashboard on a smaller screen," a responsive web application may suffice.

Offline capability and data synchronisation

Many conventional web applications are designed around a live connection. Browser applications can support selected offline and background behaviour through service workers and related APIs, but that capability must be designed explicitly rather than assumed. Mobile apps frequently lose signal. If field workers need to complete forms, record measurements or log activity while out of coverage, the mobile app must store data locally and synchronise with the backend when connectivity returns. This introduces questions about conflict resolution — what happens if two users edit the same record offline — and requires the backend to handle sync requests that arrive out of order. These are not theoretical concerns; they need explicit design decisions before development begins.

Push notifications

Push alerts are a common reason businesses add a mobile app to an existing web system. A CRM might notify a sales rep when a hot lead opens an email; a logistics portal might alert a driver about a schedule change. Push notifications are delivered through platform-specific services (Apple Push Notification Service and Google's Firebase Cloud Messaging), which means the backend must integrate with both, and the mobile app must handle registration, permissions and notification display. This is separate from in-app messaging and needs its own planning.

Real-time data

Some business processes benefit from live updates — a dispatch board showing vehicle positions, a support queue displaying new tickets, or a collaboration tool reflecting edits as they happen. Web applications can use WebSockets or server-sent events. Mobile apps can use the same technologies, but the implementation must account for mobile network handoffs, battery consumption and operating-system restrictions on background connections. The backend needs to support persistent connections for mobile clients alongside standard request-response patterns for the web.

File handling and media

Mobile devices are often used to capture photos, scan documents or record audio as part of a workflow. The mobile app needs to handle file compression, upload progress indication and retry logic for large files on unreliable connections. The backend must accept these uploads, validate file types and sizes, process them (resizing images, extracting text from scans) and store them in a way that the web application can also retrieve and display.

Assuming the existing API will work unchanged

One of the most frequent oversights is treating the mobile app as a thin skin over the web API. In practice, mobile apps often need different endpoints, leaner responses, batch operations and more granular error codes. Before committing to a build, request a review of the existing API against the planned mobile workflows. Identify where the API falls short and budget for the necessary backend changes.

Ignoring token lifecycle and security on the device

Storing authentication tokens on a mobile device carries risks that differ from browser-based sessions. If the device is lost or compromised, those tokens could grant access until they expire. Practical mitigations include short token lifetimes with silent refresh, secure storage on the device, and the ability to revoke sessions from the backend admin panel. Certificate pinning — restricting which server certificates the app will accept — adds another layer but increases maintenance burden when certificates are renewed. These are trade-offs to discuss with a developer, not details to leave unaddressed.

Underestimating API versioning

Once a mobile app is in users' hands, you cannot force everyone to update immediately. App store review processes introduce delays, and some users will remain on older versions for weeks or months. If the backend API changes in a way that breaks those older app versions, users will encounter errors. A versioning strategy — whether through URL paths, headers or a separate gateway — needs to be in place before the first mobile release, not retrofitted after the first breaking change causes complaints.

Not planning for different release cadences

Web application updates can be deployed continuously. Mobile app releases may pass through store review and staged distribution, and the backend must expect some users to remain on older versions during the rollout. This means the backend must remain compatible with the current mobile app version for a meaningful period. If a critical business rule changes on the web, the mobile app may not reflect it until the update is approved and adopted. Build this asymmetry into your deployment planning rather than discovering it during a live incident.

Key questions to put to a supplier

  • How will the mobile app authenticate, and what happens when a token expires mid-task?
  • Which existing API endpoints need modification to support the mobile workflows?
  • How is offline data handled, and what is the conflict-resolution strategy?
  • What is the plan for API versioning once multiple app versions are in circulation?
  • How are push notifications implemented, and can they be targeted by user role or workflow state?
  • What happens to the mobile experience if the backend is temporarily unavailable?
  • Who manages the Apple and Google developer accounts, and what is the process for releasing updates?

Limitations to accept upfront

A mobile app connected to a web backend cannot exceed the capabilities of that backend. If the underlying system lacks audit logging, role-based access control or the data fields the mobile workflow requires, the mobile app will not compensate for those gaps. Similarly, if the backend was not designed for concurrent access from multiple client types, adding a mobile app may expose performance or locking issues that were hidden when only web users were involved. Treat the mobile app as a window into the backend: if the view is limited, the window cannot fix that.

The practical next step is to map out the specific mobile workflows you need, compare them against what the existing backend and API can support today, and identify the gap. That gap — in endpoints, authentication, offline handling or data structure — is what needs to be designed and costed before any mobile development begins.