It’s been years of someone saying, “Hey, can we make this app installable and work offline too?”
Cue the slow, painful descent into the PWA rabbit hole: flaky service worker setups, cache chaos, App Router breaking things, and users stuck with old versions unless they manually summoned the Cache Gods. It always felt like trying to glue offline support together with hope and stack overflow threads.
So I did what any reasonable dev with too much coffee and not enough patience would do: I built my own damn package.
Introducing: next-pwa-pack
It’s a drop-in wrapper for Next.js (yep, works fine with App Router) that gives you full PWA support by just wrapping your layout with one provider. You literally write:
import { PWAProvider } from "next-pwa-pack";
export default function layout({ children }) {
return <PWAProvider>{children}</PWAProvider>;
}
And boom! Тow your app installs like a native one, works offline, caches pages, syncs tabs, and even ships with a built-in dev panel so you don’t have to guess if anything’s working.
Just drop it in and move on with your life.
Why I Built This
Every time a client asked for “offline-first” or “PWA features,” I died a little inside. I’d reach for next-pwa, only to find it didn’t support the latest App Router, or I’d try to roll my own and end up rage-refreshing the page to see if the service worker actually updated. It felt like I was building the same brittle SW setup over and over again.
Eventually, I realized what I wanted was a no-brainer setup. Something that just gave me a working service worker, pre-caching, update logic, and version control — and got out of the way. Something that I could plug into any Next.js project and trust.
So I built that.
What’s Actually Going On
Under the hood, next-pwa-pack ships a default sw.js, manifest.json, and offline.html into your public/ folder if they don’t already exist. That sw.js handles HTML and static asset caching with a sane default — HTML responses get a 10-minute TTL, and assets like JS, CSS, and images get stored permanently.
To keep all browser tabs in sync, it uses localStorage events to broadcast updates across the session. If you go offline, it serves a lightweight offline.html so users don’t face the dreaded white screen.
And since it’s not just about “being offline,” I also added a tiny API so you can interact with the caching layer. Want to purge all cached data after a logout? There’s a clearAllCache() call. Want to prefetch some pages after publishing new content? updateSWCache(["/blog", "/dashboard"]) does the trick. There’s also usePWAStatus() if you need to track install state or listen for new versions.
Dev Mode Goodies
If you enable devMode in the provider, you get a floating PWA debug panel right in your app. It shows your online/offline status, lets you clear or refresh the cache, unregister the service worker, and even toggle caching on or off while you’re testing. No more digging through Chrome DevTools or manually unregistering service workers every five minutes.
A Few Things to Keep in Mind
It’s not magic, so you’ll still need to customize your manifest.json and upload icons if you want install banners to look good. We cache only GET requests — no mutation or sensitive POST data — and if you want to change the HTML TTL or other caching rules, you’ll need to tweak the sw.js directly (for now — a config system is coming).
But performance-wise, the impact is minimal, and if anything, returning visitors will see a speed boost from the cached responses.
What’s Next
The roadmap includes support for config-based TTL rules, push notifications, smarter cache strategies based on URL patterns, integration with ISR (Incremental Static Regeneration), and even a built-in dashboard to track cache hit/miss metrics in real time.
TL;DR
I built next-pwa-pack because I was done hand-wiring service workers and debugging stale caches in production. It works out of the box, plays nice with the latest Next.js features, and helps your app stay fast, installable, and resilient — without wrecking your dev sanity.
It’s open source, you can try it out here:
Use it, fork it, break it — and tell me what you think.
Stay cached!