Progressive Web App (PWA): definition, how it works, when to use it

You have almost certainly used a progressive web app without realising it. When an online store offers to "add to home screen", when the icon then sits on your phone next to your other apps, and when opening it shows no address bar and no browser tabs: that is a PWA. Technically you are still on a website. In practice, you are using an application.

This guide gives the exact definition of a progressive web app, explains what separates it from a plain responsive site, covers what it can and cannot do, especially on iPhone, and helps you decide whether it is the right format for your project.

Definition: what is a progressive web app?

A progressive web app (PWA) is a web application, built with standard web technologies (HTML, CSS, JavaScript), that uses modern browser capabilities to deliver an experience equivalent to a mobile app: installation on the home screen, full-screen launch, fast loading, partial offline support and push notifications.

The term was introduced by Google in 2015. The word "progressive" comes from progressive enhancement: the same URL works everywhere, and each browser takes as much as it can from it. On an older browser the user sees a regular website. On a modern one they get an installable application. There is never a second version to maintain.

What separates a PWA from a normal mobile site?

A responsive site adapts to screen size, and that is all. A progressive web app adds three things a regular site does not have: it is installable (its own icon, its own launch), it is reliable (it shows something useful even on a poor or missing connection), and it can work in the background (notifications, synchronisation).

• Responsive site: opens in the browser, depends on the network, no icon, no notifications.
• Progressive web app: installs, launches full screen, caches its data, can send notifications.
• Native app: downloads from a store, accesses all device hardware, built specifically for iOS and Android.

How a progressive web app works?

Three building blocks turn a website into a progressive web app. They do not depend on your framework, which means an existing site can be turned into a PWA without a rewrite.

1. The web app manifest

A small JSON file that describes your app to the operating system: its name, the short name shown under the icon, icons in several sizes, theme colour, start page and display mode. This is what lets the browser offer installation, and what removes the address bar at launch.

2. The service worker

This is the technical heart of a PWA: a script running in the background, separately from the page, acting as a proxy between the app and the network. It intercepts requests and decides whether to serve a cached version or fetch fresh data. That is what delivers near-instant loading on the second visit, a usable screen when the network drops, and push notifications while the app is closed.

3. HTTPS

A service worker only runs over a secure connection. HTTPS is therefore not optional for a progressive web app: it is a prerequisite, just as it is for search visibility.

Checklist: what makes a real PWA

Plenty of sites call themselves progressive web apps without meeting the conditions. Here is what to verify before using the term.

• The site is served entirely over HTTPS.
• A valid manifest is present, with at least a name, a 512×512 icon and a start page.
• A service worker is registered and handles at least one offline scenario.
• The interface is usable on mobile with no zooming or horizontal scrolling.
• Mobile performance is under control (Core Web Vitals: LCP, INP, CLS).
• Every important screen still has a clean URL that Google can index.

The real advantages of a progressive web app

• One codebase. The same product serves as your website, your Android app and your iPhone app, instead of three projects to fund and maintain.
• No install friction. Users arrive from a link and start using the app immediately. No store detour, no multi-megabyte download.
• Instant updates. You deploy, and everyone gets the new version on the next load. No review to wait for, no user base stuck on an old build.
• Search visibility retained. Unlike a native app, which is invisible to Google, a progressive web app remains an indexable site that can attract search traffic.
• No store commission. Payments go through your own web checkout, with no cut taken on in-app purchases.

Limits you should know before choosing

A progressive web app is not a native app in disguise. Three limits shape the decision.

• The App Store stays closed to PWAs. Apple does not accept a progressive web app submitted as is: an app judged to offer nothing beyond a website gets rejected. On Android, by contrast, a PWA can be published to the Play Store through a Trusted Web Activity. If your growth depends on App Store visibility, a PWA alone will not be enough.
• iOS lags behind. Web push notifications have existed on iPhone since iOS 16.4, but only when the user has actually added the app to the home screen, an extra step that Safari promotes far less than Chrome does on Android. Several advanced APIs also remain unavailable.
• Hardware access is partial. Camera, microphone and geolocation work well. Bluetooth, NFC, advanced biometrics, heavy video processing or deep system integration still belong to native.

PWA, native app or WebView: the comparison

When a progressive web app is the right call?

A PWA is rarely a compromise you settle for: for a whole category of products it is objectively the best format.

• An MVP or a product you need to validate quickly, where double native development cannot be justified.
• An internal tool, client portal or business back-office, where nobody will ever search a store for it.
• An e-commerce or booking service, where every extra step before purchase costs conversion.
• A media or content service whose growth relies on organic search.

Go native instead if your product depends on advanced hardware use, a heavily animated experience, or if App Store presence is your main acquisition channel.

How to build a progressive web app?

The process comes down to five steps, in this order. For deeper technical guidance, web.dev's PWA documentation remains the canonical reference.

• 1. Build a solid web base. Mobile-first interface, clear navigation, careful performance work: a slow PWA is still a slow app.
• 2. Add the manifest. Name, icons, colours, display mode and start page.
• 3. Set up the service worker. Decide what gets cached and what must come from the network, then design the offline screen.
• 4. Serve everything over HTTPS. On your own domain name, which matters for trust and for search.
• 5. Test on real devices. Check installation on Android and iPhone, offline behaviour and Core Web Vitals.

Progressive web apps and SEO

This is the format's main strategic advantage: your application is still a website. Every page keeps an indexable URL, its own title and meta description, and can carry structured data. The speed gained from caching feeds directly into Core Web Vitals, which are part of Google's page experience signals. A native app, by contrast, brings no search visibility at all.

One caveat: if content is rendered entirely on the client, make sure crawlers can still reach it. Server-side rendering or static generation avoids trading search visibility for app-like behaviour.

Where Cadrant fits?

With Cadrant you describe your application in plain language and get a real, mobile-first web base, with code you own. You iterate prompt after prompt, publish on your own domain over HTTPS, and keep a product Google can index.

And if your project eventually requires an App Store presence, you are not locked in: Cadrant also generates mobile applications with automated publishing (certificate, signing profile, production build and upload to App Store Connect). You can start with a progressive web app to validate the market, then add the store channel once it pays for itself.

Conclusion

Keep the simple definition: a progressive web app is a website that installs and behaves like an app. It gives you one codebase, preserved search visibility, instant updates and a far lower entry cost than native, in exchange for partial hardware access and no App Store listing.

For most projects getting off the ground, it is the most rational format: it puts the product in real users' hands without tying up months of budget, and keeps the native option open for the day it genuinely pays off.