Web app or native app: which should you build first?

Start with the job, not the app store

Start with a web app when people need to open a link and complete a task across phones and computers. Investigate a native app when a tested requirement depends on device features, background behaviour or a distribution route that the web cannot reliably provide on your target devices. Neither route wins by default.

The decision is about where people work, what they must do and who will maintain it. An app-store listing is a distribution choice, not evidence that a product will be useful. Equally, a browser-based prototype is not proof that every production requirement can stay on the web.

Write down these six requirements

Use this checklist before asking for a platform recommendation. Record the answer and how you will test it, rather than ticking features from a brochure.

• Reach: who needs access, on which devices, and can they follow a link? Include shared computers, managed work phones and accessibility needs.
• Installation: must the task work immediately, or will people accept an installation step? Check whether workplace policy allows it.
• Hardware: which exact camera, scanner, NFC or other device interaction is essential? Test the required operation on representative hardware.
• Connectivity: what must work without a connection, for how long, and what happens when the connection returns?
• Distribution: do you need public stores, private organisational distribution, or simply a URL? Who owns those accounts and approvals?
• Upkeep: who funds security updates, device testing, support and releases after the first version?

A hypothetical customer booking service may favour a link because visitors arrive occasionally and do not want another installation. A hypothetical field inspection tool may need reliable offline capture and later synchronisation. These are decision examples, not customer builds or automatic platform verdicts.

Compare the actual routes

A web app can give one linked entry point across devices and let the team update the hosted application without asking each user to download a store release. It still needs testing across supported browsers, screen sizes and input methods. Cached versions and interrupted sessions also need sensible update behaviour.

An installable web app can offer a home-screen entry point where the browser and operating system support it. Installation prompts, notifications and hardware access differ between platforms. Do not assume a progressive web app gets every capability available to native software, or that a native app is necessary for every camera or location task.

Native development can make platform-specific interfaces and device integration appropriate, but the implementation still needs permissions, compatibility tests and a recovery path when access is denied. Store distribution introduces listing, review and release administration. It does not guarantee discovery or adoption.

Supporting both Android and iOS may mean two codebases. A shared cross-platform approach can reduce duplicated code, but it does not remove platform-specific work or testing. If a web version remains alongside store apps, budget for that surface too. Ask which parts are shared and who maintains each release route.

Define offline behaviour precisely

Separate opening a saved screen from completing useful work. If offline use is essential, specify which data is stored locally, how it is protected, which actions are queued and how conflicting changes are resolved after reconnection. Also decide what a user sees when stored information is stale.

Native apps can depend on online services too. Web apps can support selected offline tasks when deliberately designed and tested for them. Neither the native label nor a home-screen icon is an offline acceptance test.

Scan Login displays authorised login values for a compatible handheld scanner to read. It does not bypass passwords, SSO or multi-factor authentication. Users must follow workplace policy and check scanner compatibility. A visible barcode exposes its value; main app storage is encrypted, while widgets and notifications use a separate unencrypted, app-private copy. Those limitations matter more than using either product as an argument that one platform always wins.

Choose the smallest route you can prove

Take the hardest requirement into a short technical trial before committing to the whole build. Test the real device, poor connectivity, denied permissions and the installation journey. Agree the pass criteria and the ongoing support owner.

If browser reach fits the job, explore our bespoke web apps and dashboards service. If a requirement fails on the web, record the evidence and compare native options against it. Choose from demonstrated constraints, not from the prestige of an app icon.

Related capability

Web Apps & Dashboards

Bespoke operational tools for teams ready for a focused interface beyond generic SaaS.