·9 min read·

Progressive Web Apps are real now.

Service workers, offline-first, installable web apps, push notifications. We've been quietly shipping PWAs in production for six months — here's what works, what doesn't, what we'd tell a client today, and where we think the platform is heading.

We've been shipping Progressive Web Apps in earnest since the start of the year. The tech finally feels usable: service worker APIs have settled, Chrome and Firefox treat them seriously, the install banners are starting to feel like a real channel rather than a curiosity, and the tooling has crossed the threshold from 'enthusiast project' to 'safe to put on a client invoice'. Some honest field notes after six months.

What a PWA actually is

Stripped of buzzwords, a Progressive Web App is a website that opts into three browser features: a service worker (a small piece of JavaScript the browser keeps around in the background to intercept network requests), a manifest file (telling the browser the site can be installed and what icon to use), and HTTPS (mandatory for service workers to function). With those three pieces in place, the same URL that a desktop user types into Chrome becomes an installable, offline-capable, push-notification-receiving app on Android — without rewriting the codebase.

The 'progressive' part of the name matters. The same site falls back gracefully to a normal website on any browser that doesn't support the new APIs. There is no 'PWA version' separate from 'web version'. They are the same site.

What works in 2017

  • 01Offline-first content sites. News, docs, anything reference-shaped. Cache the article shell and the network becomes optional after the first visit.
  • 02Add-to-home-screen flows where the brand wants 'app feel' without the app store fees or the App Store review.
  • 03Push notifications, where used sparingly. Used heavily, they kill user goodwill within a week.
  • 04Background sync — queuing user actions (form submissions, content uploads) when the network is down and replaying them when it returns.
  • 05Performance work. The discipline of building for offline forces you to take the critical rendering path seriously — every PWA we've shipped also has a lighter Lighthouse score than the site it replaced.
  • 06Caching strategies that used to require complex CDN configuration are now a fifteen-line service worker file.

What we've actually shipped

  • 01A booking flow for a retail client that survives subway commute drop-outs and queues bookings until the train re-surfaces.
  • 02A reference site for an industry trade body where every previously-viewed page is available offline, instantly.
  • 03An internal field-ops tool where engineers need to log site visits in basement networking cabinets — service worker caches the form, syncs when they emerge.
  • 04An events-week installation companion app where the venue Wi-Fi was unreliable and we couldn't trust the network to be there mid-session.

What doesn't work, yet

  • 01iOS support. Safari still treats service workers like radioactive material. If iOS parity matters, build the native app too.
  • 02Anything that needs deep hardware — Bluetooth, advanced camera, NFC payments.
  • 03App-store discoverability. Google's working on it (the Trusted Web Activity proposal is on the way); Apple isn't.
  • 04Background work beyond sync — true background processing while the app is closed isn't there yet.
  • 05Geolocation in the background — only available while a tab is open and active.
  • 06Anything where users expect to find your app by searching the iOS App Store. They won't find your PWA there.

The Android vs iOS asymmetry, in plain terms

On a Chromebook or an Android phone, a PWA is a near-perfect citizen of the platform. Install prompt, home-screen icon, push notifications, splash screen, full screen, the lot. On iOS, you can pin a site to the home screen and that is essentially it. No push notifications, no background sync, no install prompts, no offline beyond what the browser cache happens to keep. This gap is the single largest reason 'PWA-first' isn't yet 'web-only-and-we're-fine'.

We don't expect Apple to close this gap fast. Their incentives align with the App Store, not with the open web. The realistic plan for any client on iOS-heavy markets is: PWA + native shell, with the native shell being thin enough that the PWA is doing the real work.

PWAs are great for the 80% of products where the web is already the right answer. They make that web product feel premium. They don't replace native — they raise the floor of what the web alone can be.

What this changes in our process

  • 01Every Nuxt project we start now has @nuxtjs/pwa added at scaffold time. Even if the brief never asks for offline, the manifest and icons cost almost nothing and quietly improve the Lighthouse score.
  • 02We treat 'works offline' as a discoverable feature, not a hidden one. The user gets feedback when they're offline, sees queued actions, knows what's been synced.
  • 03Push notifications are gated behind user intent. Nobody gets prompted on first visit. We ask after a user has demonstrated they want updates from this product, and we make it easy to unsubscribe.
  • 04We measure repeat-visit time-to-interactive separately from first-visit. PWAs make the first visit slightly heavier (service worker registration) and the second visit dramatically faster.

What we'd tell a client today

  • 01PWAs are great for the 80% of products where the web is already the right answer. They make that web product feel premium.
  • 02They don't replace native — they raise the floor of what the web alone can be.
  • 03If you want a Google Play listing without two codebases, watch the Trusted Web Activity proposal. It's not stable enough to commit to today; it might be next year.
  • 04If iOS is your primary market, ship the native shell. Don't fight the platform.
  • 05If you're optimising for re-engagement and you can be tasteful about push notifications, the channel is real and underused.

Where we think this is heading

The web has been losing distribution to native for nearly a decade. PWAs are the first credible counter-attack — not because they replace native, but because they recover the slow erosion of capability the web had given up. In 2014, no website could send a push notification. In 2017, most can. In 2020, we suspect most will install as first-class apps on the operating systems that allow it.

Microsoft's recent moves to add PWAs to the Windows Store, and Google's work on TWAs, suggest the next eighteen months are about distribution as much as capability. Apple is the lone holdout. They might stay that way. But on every other platform, 'website' and 'app' are converging fast — and the products that bet on that convergence early will be ahead.

Talk to Remiam about a system like this.