Native app vs web app vs PWA: which to build

Build a native app when a known audience uses it often and needs the phone’s hardware or a store listing. Build a web app when a wide audience does an occasional job. Build a progressive web app (PWA) when you want home-screen presence from one web codebase. The wrong choice costs you in the build and again in yearly maintenance, which is why this is the first question we ask about any app development in Dublin.

What native apps, web apps and PWAs are

Native app. Built for iOS and Android, as two builds or one cross-platform codebase, and installed from the App Store or Google Play. It has the fullest access to the device (camera, biometrics, background processing, push) and lives by the stores’ rules and release cycles.

Web app. Runs in the browser, with one codebase, nothing to install and updates live on deploy. Its pages can be indexed by search engines, which a native app’s screens cannot. Portals, booking systems, dashboards, member areas and internal tools 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 (WebKit, September 2025).

Native app vs web app: the decision tree

Answer these six in order.

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

Daily or weekly use by a known group (staff, members, subscribers) suits a native app, which sits on the home screen and can notify. Occasional use by a wide public suits a web app.

2. Does it have to work offline?

Offline use, such as engineers in plant rooms or event check-in when the venue Wi-Fi fails, points to native or a carefully built PWA. If “offline” means “copes with a slow connection”, a well-built web app handles it.

3. Which device features does it need?

A photo from the camera, a location for a map and sharing a link all work in the browser. Background processing, Bluetooth hardware on iPhone and deep operating-system integration are native territory. Biometric sign-in works on the web through passkeys.

4. Does store presence matter to the buyer?

For a membership body, a professional network or a consumer brand, a listing 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, and a link beats an install.

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

A native app is two builds, or one cross-platform build with two store submissions and two sets of device testing. A web app is one build, and the gap persists into later years.

6. Who maintains it?

Operating systems change every year and the stores enforce new requirements on their own schedule, so a native app needs someone watching. A web app needs hosting and updates too, but no store can pull it.

Where a progressive web app fits

Progressive web apps suit retail, field teams, event apps and content products. The user saves the link, it opens full-screen, loads from cache and copes with patchy connections, and nothing is installed from a store. iPhone support lagged Android for years: web push for Home Screen web apps arrived in iOS 16.4 in March 2023, and Declarative Web Push in iOS and iPadOS 18.4 (WebKit, March 2025). On iPhone the user still installs a PWA by hand from the share sheet, so it gets no store discovery.

Are websites moving towards web apps?

Yes. Browsers have gained the capabilities, and business sites now take bookings, log members in and show accounts. A brochure site should still stay fast, simple and indexable, but it should be built so it can grow into an application without a rebuild. That is the case for owning your code from the start.

Which route our two builds took

ESMA International Network: store apps on top of a platform

ESMA is an FMCG trade network, founded in 1976, with more than 200 member companies across 62 countries. We built it a custom membership platform: a public website, a member dashboard, and iOS and Android apps on the same data, with in-app messages and guest browsing, live on the App Store and Google Play.

The decision tree pointed to store apps: a known membership that returns, member messages worth having on the phone, and an app in the stores as part of the network’s credibility. The platform came first, and the apps are one surface on it. Read the ESMA case study.

ERP HEADtoHEAD: a web build with its own booking engine

ERP HEADtoHEAD is Lumenia Consulting’s event, run in Dublin and Birmingham. We rebuilt the site and wrote a booking and payments plugin for WordPress, on WooCommerce and Stripe. It is built to bill each event from its own company and currency, through separate Stripe accounts.

Here a native app 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. Read the ERP HEADtoHEAD case study.

Cost and maintenance: how the three compare

Two store fees 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 else 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

Budget for the upkeep row. As a guide, our iOS, Android and web app projects start from €10,000, and an app on both platforms sits above that floor.