On this page
No store, still an icon on the home screen
A PWA, a progressive web app, puts your website on the phone as an app, without the App Store or Google Play. You open a link, tap "Add to Home Screen", and from then on it starts like any other app.
The word progressive says how it works: the site runs in every browser, and where the browser can do more, you get more. On an old computer it is an ordinary website, on a recent phone an app with an icon. Under the hood it stays a web application: one codebase for iPhone, Android and desktop.
Alex Russell and Frances Berriman, June 2015
On 15 June 2015 Alex Russell published Progressive Web Apps: Escaping Tabs Without Losing Our Soul on his blog Infrequently Noted. The name came from Frances Berriman. Russell described a kind of site that already existed but had no name: it fits every screen, works offline thanks to a service worker, always runs safely over TLS, sits on your home screen without a store, and stays shareable with a plain link.
Apple lagged for years. Only with iOS and iPadOS 16.4, announced by WebKit on 16 February 2023, can web apps on an iPhone home screen send push notifications, and since that version you can add them to the home screen from Chrome, Edge and Firefox as well, not just Safari.
Web app or store app, for the same job
- Build
- PWAOne codebase for iPhone, Android and desktop
- Native appOne app for iOS and one for Android, or a shared codebase with two builds
- Reaching users
- PWAOpen a link, add it to the home screen
- Native appSearch and install in the store
- Updates
- PWAFor everyone, the next time the app opens
- Native appThrough store review, and the user must update
- Notifications on iPhone
- PWASince iOS 16.4, once on the home screen
- Native appAlways, after permission
- Deep phone access
- PWACamera, location and files through the browser, varying by device
- Native appFull access, including Bluetooth and sensors
- Fixed costs
- PWAHosting, no store account
- Native appApple 99 dollars a year, Google 25 dollars once, plus hosting
For an app your staff or clients use to report and follow up, a PWA is nearly always enough. Native pays when the app must reach deep into the phone or be found in a store.
The manifest in four parts
manifest.json, linked from every page, served over https
{
"name": "Site Planner Utrecht",
"short_name": "Sites",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192" },
{ "src": "/icon-512.png", "sizes": "512x512" } ],
"start_url": "/today",
"display": "standalone"
}
- The nameWhat shows under the icon on the home screen; short_name when the full name is too long.
- Two iconsChrome, Edge and Samsung Internet ask for one of 192 and one of 512 pixels.
- Where it opensThe first page after a tap on the icon, here straight to today's plan.
- No address barStandalone opens the site in its own window, like an app. On an iPhone it can then send notifications too.
The way onto the phone
Native app
- Search and install in the store
- One app for iOS and one for Android
- Every update through store review
- Apple 99 dollars a year, Google 25 dollars once
A service worker makes it an app that also works without signal. It is not required to install, but it is why a PWA feels like an app.
Twelve site managers, one app without a store
Take a construction company with twelve site managers who should see their site, crew and materials on their phone every morning, and log their hours at night. Half carry an iPhone, half an Android phone, two have a tablet in the van.
As native apps, that is two apps, an Apple developer account at 99 dollars a year and a Google one at 25 dollars once, and every update through review at two stores. As a PWA it is one web address. The company texts the link, every site manager adds it to the home screen in three taps, and a change reaches everyone the next morning. Building the screens for planning and hours costs about the same per screen either way; native builds them twice, or in a shared codebase with two builds to test and submit. For a team spread over several countries, the link works the same in every app store region, with no store listing per market.
What works on iPhone, Android and desktop
| Device and browser | Install | How |
|---|---|---|
| Android, Chrome with Google services | Yes, as a real app | Chrome's install prompt, after a tap and 30 seconds on the page |
| Android, Samsung Internet on a Samsung | Yes, as a real app | Like Chrome, as a WebAPK |
| Android, Firefox or Edge | Shortcut | An icon that opens the site in the browser |
| iPhone and iPad, iOS 16.4 or later | Yes, on the home screen | Share menu in Safari, Chrome, Edge, Firefox or Orion |
| Windows, Mac and Linux, Chrome or Edge | Yes, in its own window | Any PWA with a manifest |
| Mac, Safari 17 or later | Yes, in the Dock | Add to Dock, even without a manifest |
| Desktop, Firefox | No | Works as a normal website |
On an iPhone a PWA can only send notifications once it sits on the home screen, and the permission request has to follow a tap by the user. So show your users how to install it on day one; that single screen of help decides whether your app gets used. Good UX starts there.
Ready to install: what must be right
- The whole app runs over https, with a valid SSL certificate.
- Every page links to the manifest, with name or short_name, start_url and display standalone.
- There are two icons, of 192 and 512 pixels, plus an apple-touch-icon for iPhone.
- A service worker stores what the app needs to open without signal, and shows a clear message when something fails.
- The notification prompt only comes after a tap on a button, never on opening.
- There is a short guide per device: how to put the app on your home screen.
- Tested on a real iPhone and a real Android phone, not only in a desktop browser.
One codebase instead of three
A PWA costs what a good web application costs, plus a modest piece of work for the manifest, the icons and the service worker. What you save: a second app, Apple's 99 dollars a year, review at every update, and the day half your team still runs an old version. What you gain: an address you share with a link, and pages search engines can read if you want them to, which a store app does not have; it all runs over https with a valid SSL certificate. Speed counts double in a PWA; check your current site with our website speed test. We build client sites on Next.js, and the same stack serves a PWA.
A PWA also makes a good first version. Want to know whether your staff or clients really use an app? Build an MVP as a PWA first. If you later need Bluetooth, the NFC chip or a place in the store, build the native app on the same custom platform behind it. If the app becomes a product you sell to other companies, the PWA is the front of your SaaS.
About installing, notifications and offline
What is the difference between a PWA and a native app?
A native app is installed from the App Store or Google Play and built separately per operating system. A PWA is a website you add to your home screen from the browser; one codebase works on every device. Native reaches deeper into the phone, a PWA is cheaper to build and updates at once.
Does a PWA work on an iPhone?
Yes. You add it to the home screen from the Share menu in Safari, and since iOS 16.4 from Chrome, Edge, Firefox and Orion too. It can send notifications once it is on the home screen and the user allowed it after a tap.
Does a PWA need https?
Yes. A browser only installs a PWA served over https, or from your own machine while you build it. The service worker that lets the app open offline also needs a secure connection. A valid SSL certificate is the first step.
Can a PWA go in the App Store or Google Play?
Not as a PWA. You can wrap it in a native shell and submit that, but then the store's rules and fees apply again. For an app for your own staff or clients you usually do not need a store at all.