← All articles
8 min read

Progressive web app: when is a PWA better than a native app?

Workflows

In short

  • A progressive web app (PWA) is a website you install as an app: with its own icon, its own window and, if you want, offline use.
  • Choose a PWA for business tools where reach and a single codebase matter. Choose a native app if you need deep device features, the app store or reliable background tasks.
  • Test on your own users' devices, especially iPhones. Installing and notifications work differently there than on Android.

A progressive web app is a website you install as an app. It gets its own icon, opens in its own window and, if you want, keeps working without a connection. Our rule of thumb: choose a PWA if you want one solution for every device and the browser's capabilities are enough. Choose a native app if the app itself is the product, or if you need features the browser cannot deliver reliably.

What a PWA can do depends on the user's browser and device. So start with how the app will be used, and look at the technology after that.

What is a progressive web app (PWA)?

A PWA is an app built with web technology that still feels like an app made specifically for the device. It runs from a single codebase on several operating systems and is reachable directly on the web, like any website. You can install it, it gets an icon next to the other apps, it opens without browser chrome and it can work offline and in the background. The web standards behind it are well documented, for example in MDN's explanation.

Technically a PWA remains a website, so a browser engine always runs underneath. Two components make it a PWA. The web app manifest is a JSON file that says what the app is called, which icon it uses and how it opens. Without a manifest a web app cannot be installed. The service worker is a script the browser can start in the background, for example to keep pages for offline use or to handle a push message. Installation does not require one, but nearly every PWA uses one for offline support.

What does a PWA need at minimum to be installable?

These are the minimum requirements for browsers built on Chromium (Chrome, Edge and Samsung Internet); see also MDN's installability guide:

  1. The site is served over https (testing on localhost is also allowed).
  2. The manifest contains a name or short_name.
  3. The manifest contains a 192 pixel icon and a 512 pixel icon.
  4. The manifest contains a start_url.
  5. The manifest contains a display setting, for example standalone for a window without browser chrome.

That is the technical floor. What makes a PWA good lies in the rest: does it load quickly, does it stay usable without a connection and does the user know why they would install it?

PWA, website or native app: what is the difference?

The table lists the differences that weigh most in a business decision. An ordinary website falls outside it: it is not on the device and depends entirely on the connection. A PWA changes that without making you build two separate apps.

CriterionPWANative app
InstallingThrough the browser, or packaged for an app storeThrough the app store
CodebaseOne for all platformsOne per platform, using the Apple or Google SDK
Offline and backgroundPossible with a service worker, support differs per browserSupported by the platform itself
Device featuresWhat the browser offersAccess through the SDK, such as camera, GPS and sensors
DiscoverabilityThrough search engines and a link, optionally the store tooMainly through the app store

When do you choose a progressive web app?

A PWA is usually a good choice when several of these points hold:

  • You want one solution that works on iPhone, Android and laptop, without three separate build projects.
  • The users already know you or receive a link from you: employees, customers with an account, partners. They do not need to find the app in a store first.
  • The functions are web-like: forms, lists, dashboards, approvals, status overviews, simple camera or file uploads.
  • You want to adjust quickly. A change to a web application does not have to pass a store review.

A fictional example: suppose an installation company gives its technicians a tool to fill in work orders, add photos and report a status. The technicians receive a link, install the app from the web and see their own icon on the phone. The company maintains one solution and changes it without every technician having to fetch an update from a store. For this kind of work a PWA is often enough.

When do you choose a native app after all?

The boundary lies where the browser stops. Lean towards a native app when:

  • the app itself is the product and users must be able to find it in the store;
  • you need deep device features a browser cannot reach;
  • you rely on dependable background processing, such as continuous location tracking or a synchronisation that must always succeed. Background operation is a strength of native apps, and the background APIs for PWAs are not supported by every browser;
  • your users are mostly on one platform and you want to stay as close as possible to its own interface.

There is also a middle road. A PWA that meets the installability requirements can be packaged and offered in app stores. That works for the Google Play Store and the Microsoft Store, and with a tool called PWABuilder for the Apple App Store as well. That lets you combine web technology with the discoverability of a store. Check each store's current terms, because they sit outside the PWA technology itself.

What happens on iPhone and Android?

This part is missing from most sales articles about PWAs. Installation and features differ per browser and per device.

On the iPhone you install a PWA from iOS 16.4 through the share menu in Safari, Chrome, Edge, Firefox and Orion. On iOS 16.3 and earlier only Safari can do it. A custom install button in your app, using the beforeinstallprompt event, is not supported on iOS. You have to explain to users yourself how to add the app to their home screen.

Push messages work on the iPhone since iOS 16.4 for web apps on the home screen. WebKit, Apple's browser engine, requires the user to give permission first, after a direct action such as tapping a button. Without that permission, or without installation on the home screen, no message comes through. This comes from the 2023 WebKit post in which Apple introduced the feature. Check the current situation before you build on it.

On Android, a PWA only gets a real installation as a "WebAPK" in Chrome on devices with Google Mobile Services and in Samsung Internet on Samsung devices. Other browsers add a shortcut that opens the site in the browser.

On a computer, Chromium-based browsers install PWAs on all supported operating systems. Safari on macOS has "Add to Dock" from Safari 17. Firefox on desktop does not install PWAs from a manifest.

So design a PWA with progressive enhancement. The core always works as an ordinary website, and extras such as offline use and push messages are added where the browser supports them.

How do you decide which form suits you?

Answer these five questions, in this order:

  1. Who uses it? Your own employees on managed devices are easier to steer than anonymous consumers. For the first group a PWA is often enough.
  2. Which device features are essential? Make the list concrete. Anything a browser can handle can go into a PWA. Anything beyond that points towards native.
  3. How often does the user come back? Daily use justifies an installed app. Occasional use works fine as an ordinary website or as a PWA without an install requirement.
  4. Does the app have to be in the store? Then you choose native, or a PWA packaged for the store.
  5. What will maintenance cost over three years? One codebase is cheaper and simpler to manage than two. Weigh that against the functions you give up.

Then test the critical path on real devices: installing, logging in, receiving a message, completing a task without a connection. A prototype quickly shows whether the browser does what you need. That is cheaper than finding out afterwards that it cannot.

Does a PWA suit an internal tool or customer portal?

For internal tools and portals a PWA is often a logical form. The users are known and the functions are web-like. Hello Growth builds this kind of web environment, such as the secure online BI portal for Coinage, which according to the case page more than twenty employees use several times a day. In the AI workplace employees log in through their own company domain, with roles and permissions per person. Whether an installable PWA layer around it adds value depends on the five questions above.

Sources

Newsletter

The AI news that matters, once a month

One email a month with the most important developments in AI and what they mean for your organisation. No noise.

You will receive the Hello Growth newsletter, about once a month. First you get an email to confirm your subscription. You can unsubscribe at any time with the link under every newsletter. Read how we handle your data.

Let us begin

Want this in your own organisation?

We build it, or we teach your team to. Either works.