What your API needs before we build a mobile app

Sign-in, data access, permissions and a backend owner: what an existing product needs before a mobile app is built on it, and what if the API falls short.

Before a mobile app is built on an existing product, three things need to be in place: an API that covers the tasks the app will perform, a way for users to sign in that works on a phone, and someone on your side who can explain and change the backend. If the API falls short, that is a scope question rather than a dead end. An app-facing layer can be discussed for the specific project, but its job is to serve the app, not to replace or rebuild your product.

This article walks through what we ask before building on a client's system, and why each question matters. The same questions appear in shorter form on our mobile app development page.

Start from the tasks, not the endpoints

An API is only "ready" relative to what the app needs to do. A list of endpoints says little on its own; a list of tasks says a lot. Write down the three to five things a user must be able to do in the first release, for example check an account balance, approve a request or record a site visit, and then check each one against the API.

For each task, ask:

• Can the app read the data the screen needs in one or a few requests, without downloading far more than it shows?
• Can the app make the change the user makes, with clear success and error responses?
• Are the rules that decide whether the change is allowed enforced on the server?

The usual gap is a task that the current web application performs through server-rendered pages or internal calls. The data exists, but there is no endpoint a mobile app can call.

Sign-in that works on a phone

Signing in to a mobile app works differently from a browser session. Before building, it helps to know:

• How users sign in today: email and password, a company identity provider, single sign-on or something else.
• Whether the backend issues tokens the app can store securely and refresh without asking the user to sign in again every time.
• How a session ends, and whether access can be revoked for a single device, for example when a phone is lost.
• Whether any sign-in step depends on a browser feature that needs a different flow on mobile.

If your organisation already uses an identity provider, the app should normally use it rather than introduce a second set of credentials.

Data access and permissions

A mobile app runs on a device you do not control. Anything the API returns can be read by someone who inspects the traffic, and any check that runs only inside the app can be bypassed. Permissions therefore belong on the server.

The useful questions are who can see which records, who can change them, and whether the API applies those rules for each user or relies on the web application to hide what a user should not see. If it is the latter, the API needs to take on that responsibility before a mobile client uses it.

It is also worth agreeing early which data the app may keep on the device, for how long, and what happens to it when the user signs out.

Who can change the backend?

This is the question that decides most projects built on an existing product. The app will need small changes to the API: a missing field, a new filter, an endpoint shaped for a phone screen. Someone on your side needs to be able to explain how the backend works and to make or approve those changes.

In practice that means:

• A named person or team responsible for the backend, with time set aside for the project.
• Documentation or an API description that matches what is actually deployed.
• A test environment the app can use, with test accounts and data that is realistic but is not production customer data.
• An agreed way to request and release backend changes, so the app and the API move together.

Without this, even a well-designed app can end up waiting on questions nobody is able to answer.

What if the API falls short?

Sometimes the gaps are larger than a few changes. The API may have been built for internal use, return data in a shape that does not suit a phone, or be difficult to change quickly.

There are then two broad options. The backend owner can extend the API, which keeps everything in one place. Or, where that is not practical, a separate app-facing layer can sit alongside your system: it serves the app, calls your existing system and leaves your product as it is. This layer is not a way to replace or rebuild your product. Whether it is needed is decided for the specific project, and when it applies, the proposal defines what the layer does, which data it can access and who is responsible for it.

A brand-new product with no existing system is a different case. There, what the app needs on the server side is agreed as part of the project scope.

A short checklist

Before asking for a proposal for an app on an existing product, try to answer:

1. Which tasks must the first release support, and does the API cover each of them?
2. How do users sign in, and can the backend issue and revoke tokens for each device?
3. Does the API enforce permissions for each user?
4. Who can explain and change the backend, and how are changes released?
5. Is there a test environment with test accounts and non-production data?

You do not need every answer to start a conversation. Unknowns are fine as long as they are written down as unknowns, so the scope can account for them. For the wider picture of what belongs in a brief, see what to send before asking for a mobile app proposal. If you are also deciding how the app itself should be built, React Native for business apps covers what one codebase for iOS and Android does and does not remove.

Next step

If you are planning an app on top of an existing system, a short summary is enough to begin: what the app should do, what your API supports today and who looks after the backend. You can send it through the contact page. Please keep credentials and customer data out of the first message; they are not needed to discuss fit.