Anyone planning an app soon comes across terms like native app, web app or progressive web app. They stand for different ways of getting an application onto a phone. Each has its strengths, and none is better in principle. This article explains the differences in plain words and lists the questions that help you decide.

The three options

Native app

A native app is installed from the Apple App Store or Google Play and runs directly on the device’s operating system. It has full access to what the phone can do: camera, location, Bluetooth, notifications, payment with Apple Pay or Google Pay, work in the background.

“Native” used to mean developing the same app twice: once for iPhone, once for Android. Today most apps are developed on a shared technical basis for both platforms. Most of the work is done once, and only device-specific parts are adapted per platform. Users cannot tell the difference: they download an app from their store, and it feels like any other.

Web app

A web app runs in the browser. The user opens an address, signs in and gets to work. There is nothing to install and no store reviewing every version. A new version reaches all users as soon as it is released.

Progressive web app

A progressive web app is a web app that behaves like an app: it can be added to the home screen with an icon, opens without the browser bar, works partly offline and on many devices can send notifications. But it remains a web app - with the limits the browser sets. Those limits are tighter on the iPhone than on Android.

The differences at a glance

Native app Web app / progressive web app
How users find it in the store, through search and recommendations through a link, a website or a QR code
Installation from the store none, or an icon on the home screen
Device features full access limited, depending on device and browser
Notifications reliable possible, with restrictions on the iPhone
Offline readily possible possible to a limited extent
New version after review by Apple and Google immediately
Paying for digital content generally through the store through your own payment provider
Usable on a computer only as a separate application yes, in the browser

When a native app fits

  • Your users should find the app in the store. People looking for a solution look there. A web app does not appear in the stores.
  • The app is used daily or regularly. An icon on the home screen and reliable notifications bring users back.
  • You need device features. Bluetooth to a device, location in the background, paying by phone, a camera that reads codes reliably.
  • The app has to work offline. Downloadable content, data capture without a signal.
  • Users buy content or subscriptions in the app. The stores’ payment systems are familiar to users and quick.

When a web app is enough

  • Users arrive through a link. From an email, your website or a QR code, for example, and use the application only occasionally.
  • Most of the work happens at a desk. Then the browser is the right place anyway.
  • Users should not have to install anything. For a one-off registration, a booking or a survey, every installation is a hurdle.
  • You want to ship changes immediately. Without a store review.

That is why many customer portals are web apps. How a portal is structured and what it needs is described in a customer portal.

Often the answer is: both

Many projects end up needing two interfaces. The app on the phone for users, plus an admin area in the browser where you maintain content, manage users and see reports. Both work with the same data on the same server.

The order is also a choice. Some projects start with a web app to test the idea quickly and add the native app once it is clear that users keep coming back. That saves effort at the start but means paying for part of it a second time later. Whether that is worthwhile depends on how sure you are of your idea. More on this in testing an app idea.

What the choice means for running the app

A native app needs accounts with Apple and Google, and every version goes through their review. With every new version of the operating systems it has to be checked and often adjusted. What that involves is covered in publishing an app in the stores.

A web app does not need these accounts, but it has to work in the common browsers, and those change too. Neither option is maintenance-free.

Questions for your decision

  • How do your users find the app - in the store, through a link or through you?
  • How often do they use it: daily, monthly, once?
  • Which phone features does it really need?
  • Does it have to work without a signal?
  • Do you sell digital content or subscriptions in the app?
  • Is the work done mostly on the move or at a desk?

Once you have answered these questions, the decision has usually made itself. If it is still open, there is a lot to be said for starting with the option that reaches your users fastest.