Mobile app or PWA in 2026

“Should we build an app?” is one of the first questions founders ask us, and it is the wrong question. The right one is: what do we need the phone to do that a website cannot? Answer that honestly and the platform decision usually makes itself. Here is the framework we use, with the state of the options as they stand in 2026.

The options, briefly

A responsive web app or PWA

One codebase, deployed to the web in seconds, no store review. A progressive web app adds an install prompt or an “Add to Home Screen” step, an icon, full-screen launch, offline support through a service worker, and push notifications on Android and, since iOS 16.4, on iPhones once the app has been added to the home screen. On Android it can also be listed in Google Play through a Trusted Web Activity, so a store presence is not out of reach.

What it cannot do, or cannot do reliably: use Bluetooth, NFC and some sensors (support varies and is largely absent in Safari), run in the background for long periods, track location while closed, ship home-screen widgets, or appear in the Apple App Store as itself. iOS installs are manual: Safari does not prompt, so the user has to find the share menu. Safari can also clear a site’s stored data after seven days without interaction; installed home-screen apps are exempt, but a PWA that users only ever open in a browser tab can lose its offline cache.

A cross-platform native app

React Native (usually with Expo), Flutter or Kotlin Multiplatform give you one main codebase producing real native apps for both stores, with full device access and native UI. The cost is a build and release pipeline, two platforms to test, store review on every release, and native modules when you need something the framework does not cover. Over-the-air updates can push JavaScript-level changes without review, within the limits the stores allow.

A fully native app

Swift on iOS and Kotlin on Android: two codebases, the best possible performance and platform fidelity. For an early-stage company this is justified only by a specific need such as heavy media or camera work, augmented reality, wearables, widgets, or deep integration with the operating system.

A wrapped web app

Capacitor and similar tools put your web app in a native shell with plugins for device features. It is the cheapest route from a working PWA to a store listing, and a reasonable stepping stone. It is not a way to get native performance.

The eight questions that decide it

Where will users find you? If acquisition happens through links, ads, search, sales calls and partnerships, the web is where users arrive and a store listing adds a step. If your category is one people search for in the App Store, store presence is part of the product.
What device capabilities do you actually need? Write the list. Camera and photo upload, foreground location, payments, notifications and offline reading are all available to the web. Background location, Bluetooth, NFC, widgets, watch apps, CarPlay and Android Auto, persistent background sync and native share targets are not.
How often will the product change? Web deployments are instant and reach everyone. Store releases take review time, and users update slowly. A product that is changing every day is easier to run on the web.
How much offline and how much data? Both paths can work offline. Large offline datasets, background synchronisation and conflict resolution are easier in a native app with a real local database.
How does the money flow? The stores take a commission on digital goods and subscriptions sold inside an app, with reduced rates for smaller businesses and rules that keep shifting under regulation in several jurisdictions. Physical goods, services and business-to-business billing are not affected and can use web payments anyway.
Who will build and maintain it? A web team can ship a PWA this quarter. A JavaScript team can reach the stores with React Native. Hiring native specialists for two platforms is a different budget.
How demanding is the interface? Smooth animation at 60 frames per second, real-time audio or video processing and games favour native. Forms, lists, dashboards and content do not.
What do your customers expect? In some markets, banking and health among them, a store app signals seriousness. That is a real factor and a weak one at the earliest stage.

Reading the answers

If two or more of the capabilities you need fall in the native-only list, or store discovery is genuinely your primary acquisition channel, build a cross-platform native app and accept the release overhead. Otherwise build for the web first, make it installable, and keep the option open.

Most B2B products, marketplaces, internal tools, booking and ordering products, and content products are better served by a fast, installable web app in their first year. Most hardware companions, consumer social and media products, and anything built around sensors are not.

The path most startups should take

Ship a responsive web app first, designed for the phone from the start and installable as a PWA. Validate that people want it. Then add the store listing when there is evidence it will pay: Android through a Trusted Web Activity, which is cheap; iOS through a wrapper or a React Native client when the case is made.

The decision that makes all of this cheap is to build the backend API-first from day one. If every client, web or native, talks to the same API, switching or adding a client is a front-end project, not a rewrite. Do not build two clients at once in the first year; you will maintain both and finish neither.

When to go native from day one

The product depends on hardware: a companion app for a device, fitness with Bluetooth sensors, point-of-sale with a card reader.
Store discovery is the growth engine and you have the marketing budget to feed it.
The core experience is media-heavy or real-time: video editing, augmented reality, games.
A regulator or a platform requires device-level features such as attestation. Check the actual requirement; it is often narrower than people assume.

What each path costs later

Moving from web to native means rebuilding the user interface, not the product, provided the backend was built API-first. Cross-platform frameworks in TypeScript let you carry over logic, validation and API clients.

Maintenance is the cost people forget. Native apps need attention every year: new operating-system versions, updated SDK targets that the stores make mandatory, policy changes and expiring certificates. A PWA needs browser compatibility checks and a service-worker update strategy that does not strand users on an old version. Neither is free; budget for it.

A short checklist

Write down the device capabilities you need, not the ones you might want.
Name your primary acquisition channel.
Decide how often you expect to ship in the first six months.
Build the API so that any client can use it.
Write the platform decision down with its reasons, and revisit it at a milestone, not in a panic.

If you would like a second opinion on a decision like this, get in touch. We build all three kinds and have no reason to steer you towards one.