What Is a PWA? The Middle Road Between a Website and a Native App

"Do we need an app?" is one of the questions we get asked most. And between "build a native app" and "just have a website," there's a middle road: the PWA (Progressive Web App) — still fundamentally a website, but one that can be added to the phone's home screen with its own icon, launch full-screen, and work partially offline. The experience approaches an app, without ever going through App Store review. This article lays out what it can do, what it can't, and when it's the smartest choice.

What a PWA is: a website wearing an app's clothes

A PWA isn't a new programming language — it's a set of web standards that make a website behave more like an app. The core is three things:

• Add to home screen: via a configuration file (the manifest), users can install the site to their phone's home screen; it opens full-screen with no browser address bar — it looks like an app.
• Offline and caching: a Service Worker (a script running in the background) stores pages and assets on the device, so previously loaded content stays browsable on a flaky connection, and repeat launches get noticeably faster.
• Push notifications: the site can send push notifications with the user's consent. Android support is mature; on iOS, since 16.4, PWAs added to the home screen can receive push too, though overall support remains more conservative than Android.

The PWA sweet spot: no store, one codebase all the way

A PWA's biggest advantage is skipping the entire app distribution chain: no annual developer-account fees, no review queues, no begging users to download a multi-megabyte installer from a store, and updates go live the moment you ship. For users, "open a URL → it works well → add to home screen" is a far lower bar than "go to the store → download → register." And because it's a website, its content is indexable by search engines — content inside an app is invisible to Google, while every PWA page is an SEO asset.

An app's download barrier is paid for in conversion rate. A PWA puts "start using it" before "install it first" — and for many businesses, that's the right order.

The honest limits: a PWA can't replace every app

The cold water must be poured too. PWA capabilities are bounded by the browser, and these scenarios don't fit:

• Heavy hardware and system integration: deep Bluetooth device pairing, continuous background location, health-data integrations like HealthKit / Google Fit — browsers grant limited permissions, especially on iOS.
• The iOS experience discount: Apple's PWA support has always been conservative — no store visibility, the install entry buried in the share menu, some APIs missing. If your audience is iPhone-heavy, price this discount in.
• You need the store channel itself: for some products, being discoverable in the App Store is the acquisition channel, or you need in-app-purchase subscriptions — then you still need to publish.
• Extreme-performance games or media processing: native still wins.

If the evaluation concludes you do need both stores, that still doesn't mean maintaining two teams — wrapping web technology into store-publishable apps with a cross-platform framework is another pragmatic route; our experience is written up in one codebase, both stores: Capacitor in practice. And that road isn't mutually exclusive with a PWA: the same codebase can run as a PWA first for validation, then be wrapped for the stores when the need is real.

Which businesses fit a PWA

Back to the decision: services with moderate usage frequency, features centered on content and transactions, and a desire to lower the entry barrier are the PWA sweet spot — e-commerce (home-screen shortcut for repurchases, restock push notifications), membership services (digital member cards, points lookup), booking systems, internal tools. Conversely, products opened daily with deep phone integration should go straight to evaluating native or cross-platform apps.

A pragmatic adoption sequence

One of the PWA's virtues is being progressive — it's right there in the name. You don't need everything at once: first get the site's mobile experience and speed right (that's the foundation; without it nothing else matters), then add the manifest to make the site installable, and when capacity allows, bring in offline caching and push. Every step delivers value on its own. If you're stuck between "build an app" and "build a website," talk to us about your usage scenario first — very often the answer is: build a website good enough to grow into a PWA, and save the store launch for the day you truly need it.