Progressive Web App vs Building a Native App

Most businesses that decide they "need an app" do not need a native app at all. They need the thing that comes after the download: an icon on the customer's home screen, a full-screen experience that loads instantly, and a one-tap return visit that skips the search results where competitors are waiting. A progressive web app, or PWA, delivers exactly that by upgrading the website you already run, with no app store, no review queue, and no second codebase. Customers rarely install anything new, comScore has repeatedly found that about half of US smartphone users download zero apps in a typical month, but they will add a site they use to their home screen in a tap or two. A PWA is your existing site plus three small pieces: a manifest, a service worker, and HTTPS. That is the whole trick, and it is usually a project of weeks, not months.

The short version

The app store was never the prize. What you actually want is the home-screen icon and the instant return visit, and you can have both without shipping anything to a store.
Customers do not download new apps. With about half of US smartphone users installing zero apps in a typical month, chasing a download is chasing the hardest yes there is.
A PWA is three additions to your site. A manifest names and icons it, a service worker caches it for instant and offline loads, and HTTPS you almost certainly already have.
The payoff concentrates on repeat business. The coffee roaster, the Friday-night takeout regular, the B2B account reordering the same SKUs: wherever the same customer comes back, the icon earns its place.
A PWA is only as good as the site beneath it. If the first visit is slow, fix speed before installability, because caching cannot rescue a page that takes eight seconds to render.
One codebase, no review queue. Update the store and every customer has the new version on their next visit, with no approval delay and no lagging second app.

Why won't customers download your app?

comScore's Mobile App Report measured what US smartphone users actually do with their phones, and the finding that reshapes this whole decision is blunt: about half of US smartphone users download zero new apps in a typical month. Not few. Zero. That is not because people dislike apps; it is because they already live inside the handful they use, and the bar for adding another is enormous. A download means finding your app in a crowded store, waiting for it to install, surrendering space on a full phone, and trusting one more company with an account and a password. For the app they open forty times a day, people crossed that bar once, years ago. For a store they buy from a few times a year, most of them simply never will.

So when a business commits to "an app," look at what it is actually signing up for: a store listing, a review queue with its own rules and delays, usually a second codebase to build and maintain alongside the website, an update treadmill for every small change, and marketing spend to talk customers into a download that most of them no longer perform for anyone. All of that ordeal, to chase a prize that was never the real one. The store was only ever the toll booth. What you wanted was on the other side of it.

What is a progressive web app, in plain language?

Strip away the jargon and a PWA is three things layered onto a site you already have. A manifest is a small file that tells the phone your site's name, icon, and colors, so it can sit on a home screen like any other app. A service worker is a script that caches your pages and assets on the device, so repeat visits load from local storage and feel instant, and so the site keeps working when the connection is weak or briefly gone. And HTTPS, the secure connection you almost certainly already run, is the third requirement. Those two files are the whole mechanism the browser looks for; the official MDN guide to making PWAs installable confirms that a manifest plus a service worker is exactly what converts a normal site into an installable one.

From the customer's side, the experience is simple. They visit your store in their browser and add it to their home screen in a tap or two. From then on, your icon sits beside their other apps. Tapping it opens your store full screen, with no browser bars, loading from cache so it appears immediately. On the subway with one flickering bar of signal, the products they browsed still render, because the service worker that Google's web.dev documentation describes as the middleware between your app and the network is serving them from the device. On modern Android and iOS, a PWA can even send push notifications once the customer opts in, so "your order shipped" can land on the lock screen. One website, one codebase, no review queue, no waiting for approval to fix a typo. When you update the store, everyone has the new version on their next visit, automatically.

Who gets the most out of a PWA?

This matters because the payoff is not evenly spread. It concentrates wherever the same customer comes back: the coffee roaster whose customers reorder beans every few weeks, the takeout spot whose regulars order every Friday, the salon whose clients book monthly, the B2B supplier whose accounts reorder the same forty SKUs. For these businesses, the gap between "customer opens a browser, types your name, hopefully spells it right, and scrolls past competitors" and "customer taps your icon" is the gap between renting the relationship from a search engine and owning it outright.

A first-time visitor will never install anything, and does not need to. The regular will, precisely because the icon saves them work they repeat every month. If a meaningful slice of your revenue is repeat business, you have the exact audience the install button was made for, and owning that return path is the same instinct behind building a client portal worth its keep: stop paying, over and over, to reacquire people who already chose you once.

What are the honest tradeoffs?

We would be selling you something if we pretended a PWA does everything a native app does, so here is the other side of the ledger. If your product needs deep access to the phone's hardware, certain Bluetooth accessories, advanced background processing, or tight integration with other apps on the device, native still wins, and on iOS in particular the browser is granted less than on Android. If your business case depends on being found inside the app stores themselves, a PWA will not put you there. And if a partner or platform contractually requires a store presence, that settles it.

There is also a subtler prerequisite: a PWA is only as good as the website underneath it. The service worker makes repeat visits fast, but it cannot rescue a first visit that takes eight seconds to render. If your store is slow today, the honest first project is speed, not installability, which is why the groundwork in how to speed up WooCommerce and the deeper store speed and Core Web Vitals guide usually comes before any PWA conversation with us. Installing a slow site on the home screen just gives customers a faster route to a bad experience. And if your traffic is thin and your repeat-purchase rate is low, fix the funnel before you polish the icing, because an install prompt shown to a hundred visitors a month is not where your next dollar lives. For most retail and service businesses, though, none of these caveats bite, and what they need is exactly what the PWA delivers.

How do you ship a PWA, step by step?

Because a PWA builds on your existing site, the project is smaller than people expect, and we structure it to stay that way.

Audit the site on a real phone. Days, not weeks: measure how fast the store actually loads on a mid-range device, check what the current architecture allows, and find anything, a fragile theme, a plugin conflict, an aging platform, that would fight a service worker. You get the findings in plain language either way.
Fix speed first if it needs it. If the first visit is slow, that becomes the project before installability, because caching only helps the second visit, not the one that decides whether there is a second visit.
Add the manifest. Give the phone your name, icons, colors, and display mode, so the installed app looks like yours rather than a bookmark.
Add a service worker with sensible caching. Cache the shell and assets so repeat visits load instantly, and define an offline fallback so a weak connection degrades gracefully instead of failing.
Build the install experience. Prompt the return visitor to add the store at a natural moment, not on their first second on the page, and make the added icon and full-screen launch feel deliberate.
Prove it on your own phone, then real customers. The milestone demo is concrete: take out your phone, add the store to your home screen, turn on airplane mode, and watch it still work. Then a handful of real customers use it before anything wider.
Layer on notifications only if the numbers justify it. Push for order updates and back-in-stock alerts is a second phase, funded by evidence from the first, not assumed up front.

Each phase is a working deliverable and a clean decision point, and you own all of it, code and configuration alike, with nothing locking you to us. Stores built on a modern headless stack, like the setups in headless WooCommerce with Next.js, get much of the PWA foundation almost for free, which is one more reason that architecture keeps earning its keep.

A checklist before you build a PWA

Does a meaningful share of your revenue come from customers who return, not just first-time buyers?
Is your first-visit load already fast on a mid-range phone, or does speed need to come first?
Do you actually need home-screen presence and offline resilience, rather than app-store discovery?
Are you free of any contract that requires a native store listing?
Will you own the manifest, service worker, and configuration outright, with no lock-in?
Is there a concrete milestone demo, install it and use it offline, that defines "done"?
Have you separated the must-have first phase, install and offline, from the maybe-later push notifications?

Common pitfalls

The ways a PWA disappoints are almost always about sequence and expectation, not the technology itself.

Installing a slow site. A service worker speeds up the return visit and does nothing for the first one. Ship installability onto a sluggish store and you have simply made a poor first impression faster to reach.

Expecting native powers. Treating a PWA as a drop-in replacement for a native app invites frustration at the edges, hardware access and store discovery, where native genuinely leads. A PWA wins on the return visit, not on deep device integration.

Prompting the install too early. Shoving an "add to home screen" prompt at a first-time visitor who has spent four seconds on the page is asking for the yes before you have earned it, and it trains people to dismiss the prompt reflexively.

A concrete case. A specialty food store, details changed, came to us convinced they needed a native app because regulars kept saying they wished reordering were easier. Their real problem was two-fold: the mobile site took roughly seven seconds to become usable, and there was no fast path back for the customers who bought monthly. A native app would have cost months and still sat behind a download most of them would never do. We fixed the speed first, which was the honest first project, then added the manifest, a service worker with offline fallback, and an install prompt shown to returning visitors after a second successful order. Within a couple of months the regulars had the icon on their home screens and were reordering in a tap, mobile conversion rose because the site was finally fast, and the business had spent weeks rather than the better part of a year. The app they thought they needed was a symptom; the return visit they actually wanted was the cure.

The meeting, revisited

Next time "we should have an app" comes up, put two paths on the whiteboard and price them honestly. Path one is months of native development, a second codebase forever, a review queue between you and your customers, and a marketing budget dedicated to begging for a download that half of US smartphone users no longer grant to anyone in a typical month. Path two is the website you already have, upgraded in weeks to install in one tap, open instantly, work on a weak connection, and sit on the home screen where the return visit begins. Whether the right answer is a PWA, a native app, or neither yet is a genuine decision, and it is the same buy-versus-build reasoning we apply to any tool in custom software vs off-the-shelf. But for most retail and service businesses, the native app is a commitment their customers keep declining, and the installable website is a yes those customers will actually give.

If you want a straight answer on which path fits your store, tell me what you sell and what your customers do on their phones and I will give you an honest read: PWA, native, or neither yet, and what the smallest sensible first phase would look like.

FAQ

Is a progressive web app as good as a native app?

For most retail and service businesses it is better, because it delivers the part that matters, the home-screen icon and the instant return visit, without the app store standing in the way. Native genuinely leads in a few areas: deep hardware access, advanced background processing, tight integration with other apps, and discovery inside the stores themselves, and on iOS the browser is granted less than on Android. If your product depends on those specific capabilities, build native. If what you want is a fast, installable version of the store your customers already use, a PWA gives you that in weeks instead of months.

What exactly makes a website a PWA?

Three things layered onto a normal site: a web app manifest that provides the name, icons, colors, and display mode so it can live on a home screen; a service worker that caches pages and assets so repeat visits load instantly and the site works offline; and an HTTPS connection, which most sites already have. The manifest and service worker are the two files browsers look for before offering to install the site. Everything else, the branding, the offline behavior, the install prompt, is configuration on top of those foundations.

Can a PWA send push notifications and work offline?

Yes to both, with one platform nuance. The service worker caches your store on the device, so previously visited pages render even on a weak or dropped connection, and you can define a graceful offline fallback for anything not cached. Push notifications work on modern Android and, more recently, on installed PWAs on current iOS, once the customer explicitly opts in, which lets messages like "your order shipped" or "back in stock" reach the lock screen. Because support and behavior differ slightly across platforms, notifications are best treated as a second phase you add once the core install experience is proven.

Do I need to be on the App Store or Google Play?

Only if your business genuinely depends on store discovery or a contract requires a listing. A PWA installs straight from the browser, so customers add it to their home screen without ever visiting a store, which sidesteps the review queue and the download friction entirely. The trade is that you will not appear in store search results, and you lose store-specific features. For a store whose customers already know your name and come back to reorder, that trade is almost always worth making, because those customers were never going to find you by browsing an app store anyway.

Will a PWA slow down or speed up my store?

Done right, it speeds up the return visit, because the service worker serves cached pages and assets from the device instead of fetching them fresh. What it cannot do is fix a slow first visit, since there is nothing cached yet when someone arrives the first time. That is why the honest sequence is to make the site genuinely fast before adding installability; a PWA layered onto a slow store just delivers a poor experience more quickly. Fix the underlying speed first, and the PWA then makes every subsequent visit feel instant.

How long does it take to build a PWA?

For a store with a reasonably healthy site underneath, the core install-and-offline phase is typically a matter of weeks, not the months a native app demands, because it builds on the website you already run rather than starting a second codebase. The timeline stretches only when the audit finds that speed has to be fixed first, or when the existing platform fights a service worker. Push notifications and deeper offline features come afterward as a separate, evidence-driven phase, so the first working, installable version lands quickly and later additions are decided on results rather than guesses.

The Installable Website: Why a Progressive Web App Beats Building "An App