SveltePWA

SveltePWA addresses something most Svelte starters ignore entirely: what happens when your user loses internet. Built as a progressive web app from the ground up, it treats offline capability as a first-class feature rather than an afterthought.

The service worker setup uses Workbox under the hood but abstracts the complexity into a configuration file. Asset caching uses a stale-while-revalidate strategy for static files and a network-first strategy for API calls. The result is an app that loads instantly from cache on repeat visits and degrades gracefully when the connection drops.

What stands out

The offline experience is well-thought-out. When the app detects no connectivity, it switches to an offline-aware UI state — forms queue submissions via Background Sync, lists display cached data with a “last synced” timestamp, and a subtle banner informs users they’re offline without blocking interaction. When connectivity returns, queued actions replay automatically.

Push notifications are pre-wired with the Web Push API. The starter includes a subscription management component where users can opt in or out, and the service worker handles incoming notifications with custom actions. The notification permission flow is respectful — it doesn’t prompt immediately on page load but waits for a user-initiated action.

The install experience is polished. The web app manifest is pre-configured with icons, theme colors, and display mode settings. A custom install prompt component detects the beforeinstallprompt event and shows a non-intrusive banner, resulting in an experience that feels close to a native app store install.

Where it could improve

There’s no backend. The push notification system includes the client-side subscription flow and service worker handler, but the actual push server — the thing that sends notifications — is left as an exercise. A simple example using web-push with a Node endpoint would have made this considerably more useful out of the box.

Service worker debugging remains a pain point, and the starter doesn’t do enough to help. Cache invalidation issues, stale content, and “why isn’t my latest code showing up” are common frustrations. Better developer tooling guidance or a debug mode that bypasses the service worker during development would improve the experience.

iOS Safari support is a real limitation of the PWA platform, not this starter specifically. Push notifications on iOS require Safari 16.4+ and behave differently from Android. The starter documents these limitations but can’t solve them. If your target audience is primarily iPhone users, test thoroughly before committing to a PWA approach.