A progressive web app, or PWA, is a website built so that it can feel like an app. A visitor opens it in the browser like any other site. If they come back often, they can add it to their home screen, and from then on it opens full screen with its own icon, loads fast and may keep working when the connection drops.

The idea matters to sellers because it sits between two options that are usually presented as opposites: a mobile website and a native mobile app. A PWA promises some of the benefits of an app without the app store, the review process or the store commission. Knowing what it really delivers helps you judge an agency proposal or a platform's claims.

What is a progressive web app?

A PWA is a regular web application that meets a few technical conditions allowing browsers to treat it like an installable app. The word "progressive" means it improves step by step: it works as a normal website in any browser and unlocks extra abilities where the browser supports them.

In practice, a PWA has three ingredients:

  • HTTPS. The site must be served over a secure connection. Browsers refuse to install anything that is not. See HTTPS and TLS.
  • A web app manifest. A small file that gives the app its name, icons, colors and how it should open, for example full screen without the browser bar.
  • A service worker. A script that runs in the background of the browser. It can store pages and files for offline use, speed up repeat visits and, where supported, receive push notifications.

A PWA is not a native app. It is not downloaded from an app store in most cases, it does not go through Apple's or Google's review, and it has more limited access to the phone's hardware. It is also not just a responsive website. Any site can adapt to a small screen, but only a PWA can be installed and can work offline.

Related vocabulary: add to home screen, offline mode, caching, web push and Trusted Web Activity (a way to publish a PWA in Google Play).

Why it matters

The appeal of a PWA is simple: one codebase, one URL, and app-like behavior for the customers who want it. Updates go live the moment you publish them. There is no store to approve them and no customer who forgets to update.

Here is a worked example. A cosmetics brand has 20,000 monthly mobile visitors, converts at 1.5% on mobile and has an average order value of $40. That is 300 orders and $12,000 a month. The agency quotes $50,000 for a native app or $15,000 to turn the existing store into a PWA with offline catalog and faster repeat loads.

Suppose the PWA's faster loading on repeat visits lifts mobile conversion from 1.5% to 1.65%. That is 30 extra orders, or $1,200 a month, reaching every visitor instead of only those who install an app. The $15,000 is recovered in about a year on gross revenue. The native app might bring deeper engagement from a small loyal group, but at more than three times the cost.

There are limits. Speed gains depend on how slow the site was to begin with. A store that already loads quickly will see a smaller lift. And the installation step itself is rarely used by casual shoppers. The main benefit for most stores is performance and resilience, not the home screen icon.

How it works

Here is what happens when a customer uses a PWA:

  • First visit. The page loads like any website. In the background, the browser registers the service worker and reads the manifest.
  • Caching. The service worker saves key files, like the layout, styles, logo and perhaps recent product pages, in the browser's storage.
  • Repeat visits. Those files load from the phone instead of the network, so pages appear much faster, even on a weak 4G signal.
  • Installation. On Android, Chrome may suggest installing the app, or the user chooses "Install" from the menu. On iPhone, the user taps Share and "Add to Home Screen". The icon then sits next to native apps.
  • Offline behavior. If the connection drops, the service worker can show cached pages or a friendly offline screen instead of the browser's error page. Checkout still needs a connection, since payment must reach the payment provider.
  • Updates. When you change the site, the service worker fetches the new version on the next visit. No store review is involved.

Platform support is uneven. Android and desktop Chrome support PWAs broadly. Apple has added support in steps, including web push for home screen apps since iOS 16.4, but some features remain more limited on iPhone. It is worth testing any promised feature on the devices your customers actually use.

Benchmarks and examples

Realistic ranges help you judge claims:

  • Cost. Adding PWA features to an existing, well-built site often takes a developer from a few days to a few weeks. Rebuilding a store as a PWA from scratch costs about as much as a full custom web build.
  • Installation rates. Only a small share of visitors install a PWA, often a low single-digit percentage. Do not base a business case on installs.
  • Speed. Repeat visits served from cache commonly load noticeably faster, which helps conversion rate on mobile, especially where networks are weak.

Typical situations:

  • A creator selling digital downloads. A fast hosted page is enough. The PWA install step adds little for occasional buyers.
  • A brand with a loyal, repeat audience. A PWA can offer an app-like reorder experience without a store listing.
  • A store serving regions with poor mobile coverage. Offline caching and faster reloads bring the clearest gains here.

Common mistakes

  • Expecting app-store visibility. A PWA does not appear in the App Store by default. People find it through your website.
  • Promising offline checkout. Browsing can work offline, but payment always needs a connection.
  • Caching too aggressively. A badly configured service worker can show old prices or out-of-stock products. Stock and prices must stay live.
  • Ignoring iPhone limitations. Test notifications and installation on iOS before promising them to a client or customers.
  • Treating PWA as a fix for a slow site. Caching helps repeat visits. The first visit still depends on a light, well-built page.

Best practices

  • Get the basics fast first. Optimize images, remove heavy scripts and simplify pages. A PWA adds on top of good performance, it does not replace it.
  • Cache the frame, not the data. Store layout, fonts and icons. Always fetch prices, stock and cart contents from the server.
  • Design a useful offline screen. Show recently viewed products and a clear message instead of a browser error.
  • Ask for installation at the right moment. After a second visit or a first purchase, not on the first page load.
  • Measure before and after. Compare load times and mobile conversion over the same period length to see if the work paid off.
  • Keep one catalog. The PWA should run on the same product, stock and order data as the rest of your store.

In Roctify

Roctify storefronts are not PWAs and cannot be installed on the home screen as apps. What Roctify does provide is a store optimized for mobile browsers, served over HTTPS with a free SSL certificate, with a cart and one-page checkout designed for phones. Roctify hosts and maintains it, so performance and security updates are handled for you.

For most creators and small brands, that covers what a PWA project would aim for: a fast mobile experience that customers open from a link in bio, an email or a message. If your business needs a custom app-like experience, integrations beyond the built-in features are discussed on the Enterprise plan.

FAQ

Can a PWA be published in the App Store or Google Play?

In Google Play, yes, through a wrapper called Trusted Web Activity. Apple's App Store is stricter and usually rejects apps that are only a website, so a PWA on iPhone is mostly installed from Safari. Most PWAs are simply used and installed from the browser.

Is a PWA cheaper than a native app?

Usually, yes. You maintain one codebase for all devices, and updates do not go through a store. If you already have a solid website, adding PWA features costs a fraction of building a native app, though a full rebuild is a larger project.

Do PWAs support push notifications?

On Android and desktop browsers, yes. On iPhone, web push works since iOS 16.4, but only after the user has added the PWA to the home screen. That extra step means fewer people receive them than with a native app.