What is a progressive web app? A plain guide to PWAs, how they work, and when to build one

A progressive web app is a website that behaves like an installed app. You open it in a browser, and if it is built right, you can add it to your home screen, launch it without an address bar, use it on a train with no signal, and get a push notification later. No app store, no download bar, no 150 MB install. That is the whole idea of a progressive web app, and it is one of the most misunderstood options in software today.

We build both websites and mobile apps at Zarle, so clients ask us this a lot: "Can we just make it a PWA and skip the app stores?" Sometimes yes. Sometimes that is exactly the wrong call and it costs them later. This guide explains what a progressive web app actually is, the pieces that make it work, how it stacks up against a native app and an ordinary responsive site, and how we decide which one a business should build.

The short version

A PWA is a normal web app plus three things:

• A web app manifest, so the browser knows the app has a name, an icon, and can be installed to the home screen.
• A service worker, a small script that sits between the app and the network and can serve cached files, work offline, and handle push notifications.
• HTTPS, because service workers only run on a secure connection.

Add those to a decently fast, mobile-friendly site and you have a progressive web app. Take them away and you have a website. The line is thinner than most people think, which is both the appeal and the trap.

How a progressive web app actually works

Let me break down the moving parts, because "it works offline" gets thrown around like magic and it is not magic.

The web app manifest

The manifest is a small JSON file linked from your pages. It tells the browser the app's display name, its icons at different sizes, a theme colour, a start URL, and a display mode. When you set the display mode to standalone, an installed PWA opens in its own window with no browser chrome, so it looks like a real app instead of a tab.

On Android and desktop Chrome, a valid manifest plus a service worker triggers an install prompt. The user taps "Install" and the app lands on the home screen next to native apps. On iOS the flow is different, and I will get to that honestly in a minute.

Service workers

The service worker is the engine. It is a JavaScript file that runs separately from your web page, in the background, and acts as a network proxy. Every request the app makes, for a page, an image, an API call, passes through the service worker first. The service worker decides what to do: fetch it fresh, serve a saved copy from the cache, or fall back to something when the network is dead.

That is how offline works. On the first visit, the service worker caches the app shell, the HTML, CSS, JS, and icons that make up the interface. Next time, even with no connection, it serves that shell instantly from cache and the app opens. Your data still needs the network, but the app does not sit there blank.

Service workers also handle:

• Background sync, so an action you took offline (adding an item, saving a note) gets sent when the connection returns.
• Push notifications, so you can re-engage a user who closed the app, within the platform limits.
• Precaching and runtime caching, which is why a well-built PWA feels faster than the same site without one.

The catch worth stating plainly: a service worker that caches badly will serve people stale content and confuse them. Caching strategy is real engineering, not a checkbox.

HTTPS and the install

None of this runs over plain HTTP. Service workers demand HTTPS because a script that can intercept every request is dangerous on an insecure connection. Once you are on HTTPS with a manifest and a registered service worker, the browser treats your site as installable, and modern browsers will surface an install option to the user.

PWA vs native app vs responsive website

This is the comparison clients actually want, so here it is without the sales gloss.

A responsive website is your baseline: it renders on any screen but stops at the browser. A native app is the full-power option, built with Swift, Kotlin, or a cross-platform framework like Flutter, installed from the store, with complete access to the device. A progressive web app sits in between and, honestly, that middle spot is either perfect or frustrating depending on what you need.

What a PWA is genuinely good at

The business case for a PWA is strongest in a few clear situations.

Reach over installed footprint. People will use a link far more readily than they will install an app. Starbucks built a PWA that is a fraction of the size of its native app, roughly 200 KB against nearly 150 MB, and doubled its daily active web users. When your audience is on cheap Android phones with full storage, an app they do not have to download is a real advantage.

Content and commerce that lives on the open web. A PWA is still a website, so Google crawls it and, increasingly, AI answer engines can cite it. You keep your SEO. You keep your shareable links. Ecommerce brands have seen strong numbers here: Alibaba reported a large jump in conversions across browsers after moving to a PWA, and several fashion retailers have posted conversion lifts well above 100% with faster load times. Pinterest rebuilt its mobile web experience as a PWA and lifted core engagement by around 60%.

Speed and re-engagement without a store. Caching makes repeat visits fast, and push notifications (on supported platforms) let you bring people back, the way an app would, without asking them to install anything first.

For a lot of Indian businesses this matters even more, because a big share of traffic is on mid-range Android devices and data-conscious users who abandon heavy downloads. A PWA gets you app-like behaviour on those phones for a fraction of native cost, often in the 3 to 8 week website range rather than a multi-month app build.

Where PWAs fall short, and iOS is the honest part

I am not going to pretend a progressive web app does everything. It does not, and the biggest gaps are on Apple's platform.

• iOS install is manual. There is no automatic install prompt on iPhone. A user has to open the site in Safari, tap Share, then "Add to Home Screen." That extra friction quietly kills install rates for a general audience who does not know the trick.
• iOS push is conditional. Web push works on iOS 16.4 and later, but only after the user has added the PWA to the home screen, and only when the permission request comes from a clear tap inside the app. An open Safari tab cannot send push. In the EU, Apple's changes under the Digital Markets Act made standalone PWA behaviour messier still.
• Deep hardware access is partial. Advanced Bluetooth, NFC, precise background location, and some camera and sensor features are still native-only or patchy on the web. If your product depends on those, a PWA will fight you.
• App store presence. Some users only trust and only look in the App Store or Play Store. A PWA is not there. For certain brands, that absence signals "not a real app," fair or not.

So when someone says "just make it a PWA and skip native," the honest answer is: it depends heavily on whether your audience is iPhone-heavy and whether you need those deep device features.

How we decide at Zarle: right-sizing, not upselling

We would happily sell anyone a native app. We usually do not lead with it, because the right-sized build keeps clients longer, and 95% of ours stay. Here is roughly how we think it through.

Build a PWA when:

• Your product is content, booking, dashboards, or standard ecommerce.
• Reach and low friction matter more than deep hardware access.
• Your audience skews Android or web, and budget or timeline is tight.
• You want one codebase, instant updates, and to keep SEO working.

Build native (or native plus a PWA) when:

• You need heavy device integration, top-tier animation, or offline-first with large local data.
• Your users are iPhone-heavy and you depend on reliable push and installs.
• App store presence is part of how customers judge you.
• Retention from your best users is the whole game.

Often the smart move is a sequence. Start with a fast responsive site or a PWA to validate demand and capture organic traffic, then add a native app once the numbers justify it. When we built the web platform for Optima Learning, an AI-driven CAT-prep product, the priority was getting an SEO-ready experience that pulled organic traffic within weeks, not shipping to an app store on day one. For Fit Mom by Pooja Batra, the audience and feature set pointed the other way, toward native apps that crossed 10,000 downloads in the first month on both iOS and Android. Same agency, opposite calls, because the products were different.

A short checklist to build a PWA properly

If you have decided a progressive web app is right, do not stop at "we added a manifest." A cut-rate PWA is just a slow site with an icon. Cover these:

1. Serve over HTTPS. Non-negotiable.
2. Ship a complete web app manifest. Name, full icon set, theme colour, standalone display, and a sensible start URL.
3. Register a service worker with a real caching strategy. Decide per resource: cache-first for the shell, network-first for fresh data, and clear rules for when to update the cache.
4. Design an offline state. Show something useful when there is no network, not a dead screen.
5. Handle push correctly per platform. Assume iOS needs home-screen install first, and only ask for permission after a clear user action.
6. Test on real mid-range Android and on iPhone. Not just your fast laptop and fast Wi-Fi.
7. Measure. Track install rate, repeat-visit speed, and whether offline is actually being used. Cut what nobody uses.

Frequently asked questions

Is a progressive web app the same as a normal website?

No, though it starts as one. A website becomes a PWA when you add a web app manifest, register a service worker, and serve it over HTTPS. Those additions let it install to the home screen, work offline, and send push notifications, which a plain website cannot do.

Do PWAs work on iPhone?

Yes, but with limits. iPhone users can add a PWA to the home screen through Safari's Share menu, and push notifications work from iOS 16.4 onward once the app is installed that way. There is no automatic install prompt, and some deep device features remain native-only, so iOS is where PWAs feel most constrained.

Can a PWA be listed in the App Store or Play Store?

Not by default, because a PWA lives on the web, not in a store. You can wrap a PWA in a lightweight native shell (using tools like Trusted Web Activities or Capacitor) to publish it, but that adds a native layer and store review back into the picture.

Is a PWA cheaper than building a native app?

Usually, yes. A PWA is a single codebase that runs everywhere and updates instantly, which trims both build cost and ongoing maintenance versus separate native apps. In India, that often means a website-scale budget and a few weeks of work rather than a multi-month, per-platform app build.

Will a PWA hurt or help my SEO?

It helps, because a PWA is still a real website that Google can crawl and index, and faster load times from caching tend to support rankings. You keep shareable links and organic discovery, which is a genuine edge a native app does not have.

How long does it take to build a PWA?

For a focused product, it often fits the same 3 to 8 week window as a standard website build, since much of the work is normal web development plus the service worker and manifest layer. Complex offline logic, background sync, and heavy caching strategy add time.

When should I choose native over a PWA?

Choose native when you need deep hardware access, reliable push and installs on an iPhone-heavy audience, top-tier performance and animation, or an app store presence your customers expect. If none of those are dealbreakers, a PWA usually gets you there for less.

Where to start

If you are weighing a progressive web app against a native build, the useful first step is being honest about your audience, your must-have features, and your budget, before anyone writes code. That is the conversation we have with clients before we recommend anything.

We build both, and we will tell you which one your product actually needs, not which one bills more. If you want a second opinion on that call, take a look at how we approach website development and bring us the real constraints. We will right-size it with you.