Web app or mobile app: decide by where the user is

Web app or mobile app is not a technology question — it is settled by the place where the user reaches for the product. A web app runs in a browser at a web address and needs no installation; a mobile app is downloaded from a store, sits as an icon on the phone and can reach the features of the device. Below you get a decision rule built on the user’s situation, and the part most guides leave out: what to design today so that adding a mobile version next year does not mean rewriting the backend.

What separates a web app from a mobile app in daily work

The difference comes down to three things: how a new version reaches people, what hardware you can touch, and who stands between you and the user.

• Releases. In a web app you deploy a fix and everyone has it on their next refresh. In a mobile app every release goes through a store review, and then you wait for users to update it on their own devices. For a while several versions are live at once, and the backend has to cope with that.
• Hardware. A browser handles the camera and basic location, but background work, continuous GPS reading, NFC, Bluetooth and full offline working with a local database belong to an installed app.
• The middleman. A mobile app lives under Google’s and Apple’s rules. A web app lives on your domain, and nobody can take it down from there.

There is a third form — a web app installed onto the phone’s home screen — with its own rules and its own limits, covered separately in the guide to what a progressive web app can do on iOS.

Where is the user physically standing when they open the app

The place of use is the strongest selection criterion, because it determines everything else: session length, how many hands are free, connection quality, and whether the user is even looking at the screen. Before you compare technologies, describe one scene: where that person is standing, what they are holding and how much time they have.

Ask three questions:

1. How long is one session? Fifteen seconds, dozens of times a day, is a mobile profile. Forty minutes on a single task is a desk profile — nobody keys in invoice data on a phone screen when a monitor is sitting next to them.
2. Does the user have both hands free? A warehouse worker holding a parcel, a technician on a ladder and a driver at unloading have one hand and often gloves. That forces large touch targets, scanning a code instead of retyping it, and the smallest possible number of fields.
3. What happens when there is no signal? If the answer is “the process stops and somebody loses an hour”, you need local storage and synchronisation once the network returns — and that is an argument for an installed app.

The second version is a decision you can test. The first is a wish, and it comes back at every meeting that follows.

User situation, recommendation, and what to prepare for later

The table below pairs typical situations with a recommendation and with what is worth protecting in the architecture, even if you are not building the mobile version today.

Which architecture decisions let you add mobile without rewriting the backend

Whether you can add a mobile app later is decided by four choices made while the web version is being designed — all of them cheap now and expensive to retrofit.

A shared API rather than a backend that renders pages. The backend should return data in a client-neutral format and keep the business rules in one place: who sees what, when an order changes status, how a discount is calculated. If those rules sit inside page templates, the mobile app has nothing to consume and you end up with a second implementation of the same logic. The same principle governs data exchange between systems in a company, which is a subject of its own.

Token-based authorisation, not just a cookie session. A mobile app has no browser session, so it needs a token it stores and refreshes itself. Bolting that on afterwards means rebuilding login, permissions and every place that assumed a cookie was present.

A versioned interface. Mobile releases reach users with a delay, so the backend has to serve an older and a newer version at the same time. Give the API address a version from the start and adopt the rule that fields get added, and only removed after notice and a transition period.

One shared design system. Colours, typography, spacing and component states stored as tokens, rather than hard-coded into the website’s stylesheet, let you rebuild the same product on a phone without designing it again from scratch.

Put that sentence in your brief and in the scope of work. It is short, and it decides whether a year from now you are talking about a new client of the same system or about a second project.

What entering the app stores really costs, and staying in them

The account fees are token amounts: Google Play Console is a one-off USD 25, the Apple Developer Program USD 99 a year. The cost is the process that starts once the account is paid for.

Every release goes through verification: Apple checks apps by hand under App Review, Google leans more on automation. A rejected release means a fix and another attempt, so a publication schedule is planned with slack rather than for the day before a campaign. On top of that comes the obligation to keep pace with platform requirements — from 31 August 2026, new apps and updates on Google Play must target Android 16 (API 36). That is work which adds no feature for the user and still has to be done and paid for.

A web app has none of this: you deploy when you want, and nobody reviews your release. If you want to see how the form of the app feeds into the budget, the components are broken down in the guide to mobile app development cost.

One codebase or two native apps

Once the decision on a mobile version is made, the second question is how many codebases you keep. The options are cross-platform frameworks — React Native, Flutter and Kotlin Multiplatform, stable since November 2023 — or two separate native apps for Android and iOS.

A shared codebase makes sense when both platforms are meant to do the same thing and the interface is built from standard screens, lists and forms. Two native apps win when the product leans hard on one system’s capabilities, uses unusual animations, or talks to hardware in a way no ready-made bridge between technologies covers.

Ask that question only after the place of use and the scope are settled. The order matters, because the technology decision follows from the feature list and not the other way round — which is why you first close the scope of the first release and pick the stack afterwards. The remaining stages, from design through to launch, are laid out in the guide on how to build a mobile app. If you would rather sort these decisions out before the first conversation with a supplier, describe who will use the product and where — that is exactly the material a recommendation on the form of the app comes from.