Native app vs web app vs PWA: which do you actually need?

Native app vs web app vs PWA: the short version

The native app vs web app question comes up in almost every first conversation we have about a product. It usually arrives as “we need an app”. The answer is that native apps, web apps and progressive web apps are three different tools for three different jobs, and picking the wrong one costs you twice: once to build it, and again every year to maintain it.

Below: the six questions we ask, two of our own builds that landed on opposite answers, and where the cost actually sits.

The three options, defined

Native app. Built for iOS and Android and installed from the App Store or Google Play. Fullest access to the device (camera, biometrics, background processing, push); lives by the stores’ rules and release cycles.

Web app. Runs in the browser. Nothing to install, one codebase, reachable by a link, updated the moment you deploy. Portals, booking systems, dashboards and member areas are usually web apps.

Progressive web app (PWA). A web app built to behave like an installed one: a service worker for caching and offline behaviour, a web manifest for the icon, name and full-screen launch, and push notifications on supported platforms. Android has prompted installs for years; since Safari 26 any site on iOS or iPadOS can be added to the Home Screen and opens as a web app, with the manifest improving the result rather than gating it (WebKit, September 2025).

Native app vs web app: the decision tree

Six questions. Answer them in order and the choice usually makes itself.

1. Who is the audience, and how often will they come back?

Daily or weekly use by a known group (staff, members, subscribers) rewards a native app: it sits on the home screen, it can notify, it feels like part of the phone. Occasional use by a wide public rewards a web app. Nobody installs an app for something they do twice a year.

2. Does it genuinely have to work offline?

Real offline use, such as engineers in plant rooms or event check-in where the venue Wi-Fi fails, points to native or to a carefully built PWA. If “offline” really means “must not fall over on a slow connection”, a well-built web app handles that.

3. Which device features does it need?

A photo from the camera, a location for a map, sharing a link: the browser does all of these. Background sync, Bluetooth hardware, device biometrics and deep operating-system integration are native territory.

4. Does store presence matter to the buyer?

For a membership body, a professional network or a consumer brand, being in the App Store and Google Play is a trust signal and a discovery channel. For an internal tool or a B2B portal it is friction: a link beats an install.

5. What is the budget, this year and next?

A native app is at least two builds (iOS and Android), or one cross-platform build with two store submissions, two review processes and two testing matrices. A web app is one build, and the gap persists into years two and three.

6. Who maintains it?

Operating systems change every year and the stores enforce new requirements on a schedule you do not control, so a native app needs someone watching that. A web app needs hosting and updates too, but it is never pulled from a store because a library went out of date.

When each one earns its place: native apps, web apps and progressive web apps

Native is the right call when the phone itself is part of the product: a camera or scanner in constant use, biometric login, background work, notifications people actually want. It is also right when the store listing is part of the pitch, as it is for a membership organisation whose members expect “the app” to exist.

Web is the right call for most business software, and the one thing it does that native cannot is be found. It is the only one whose content search engines can index. A native app gets you a store listing in the results; a web app gets you every page.

Progressive web apps give you home-screen presence without a second and third codebase: the user saves it, it opens full-screen, loads from cache and copes with patchy connections. Retail, field teams, event apps and content products often land here. Note the difference from a native event app: the delegate is not installing anything from a store, only keeping a link on the home screen for the two days it matters.

Two caveats. iPhone support lagged Android for years and the catch-up has been incremental: web push for Home Screen web apps landed in iOS 16.4 in March 2023, Declarative Web Push in iOS and iPadOS 18.4 (WebKit, March 2025), and Safari 26 removed the installability requirements altogether (WebKit, September 2025). The second caveat has not moved: on iPhone the user still installs it by hand from the share sheet, so a PWA gives you no store discovery.

Are websites moving towards web apps?

Yes, and quietly, for years. The line has blurred because the browser gained the capabilities, and because the jobs a business asks its site to do have grown: take a booking, log a member in, show an account, run a workflow. The moment a site needs any of that, it is an application with a marketing front.

That does not mean every website should become an app. A brochure site should stay fast, simple and indexable. It means the site should be built so it can grow into an application when the business needs it, rather than hitting a template’s ceiling and being rebuilt. That is the case for owning your code from the start, and it is the pattern behind the second example.

Two real builds, two different answers

ESMA International Network: native apps on top of a platform

ESMA is a fifty-year-old FMCG trade network. We built it a custom membership platform: a public website, a member dashboard and native iOS and Android apps on the same data and design system, with push notifications and guest-mode browsing in the app. The apps are live in both stores.

Run the decision tree and native was the right answer: a known membership that returns, useful notifications about events and regulatory updates, and, for a network built on exclusivity, a real app in the stores as part of the credibility. The important detail is the order: the platform came first and the apps are one surface on it. Read the ESMA case study.

ERP HEADtoHEAD: a web build with a custom booking engine

ERP HEADtoHEAD is Lumenia Consulting’s flagship event, run in Dublin and Birmingham. We rebuilt the site and wrote a booking and payments engine from scratch as a WordPress plugin, with Stripe and headless WooCommerce underneath. It runs two events in two countries and two currencies through two merchant accounts, and issues each delegate a QR code for check-in.

Run the same tree and native would have been a mistake. Delegates book once or twice a year, arrive from an email or a search, and nobody installs an app to register for a conference. Even the check-in runs in the browser. Read the ERP HEADtoHEAD case study.

Cost and maintenance: how the three compare

Scope decides the number, so here is where the cost actually comes from. Two running costs are fixed and public: the Apple Developer Program is $99 a year (Apple) and a Google Play developer account is a one-off $25 (Google). Everything above that moves with scope, and we set out the Irish bands in how much an app costs to build in Ireland.

Scroll the table sideways for the full detail

The upkeep row is the one to budget for. Neither commitment is free, and they are not the same size. As a guide, our projects start from €10,000, and a native app on two platforms sits above that floor.