Laravel Pwa Laravel Package

Product Decisions This Supports

• Native app vs. PWA (roadmap gating decision): This package lets you ship an installable, app-like experience on top of the Laravel app you already have instead of funding an iOS/Android build. It is the cheapest possible test of "do our users actually want an icon on their home screen?" — a question worth answering for tens of thousands of dollars less than a native MVP.
• Build vs. buy for a commodity layer: Manifest generation, service-worker registration, and an install prompt are well-understood, low-differentiation work — roughly 1–3 engineering days hand-rolled plus ongoing browser-quirk maintenance (iOS standalone mode, install prompt heuristics). Buying it for a Composer require is the correct default; the package's own changelog shows it absorbing iOS install-prompt fixes you would otherwise debug yourself.
• Retention / acquisition experiments: @PwaHead + @RegisterServiceWorkerScript are two lines in a layout, which makes "add install prompt" a cheap A/B-testable lever. Instrument installs and repeat-visit rate, not just deployment success, before deciding whether to invest further.
• Offline/field-worker use cases: Ships an offline fallback page. Sufficient for "don't show the browser dinosaur when the connection drops" — a real support-ticket and perceived-reliability win for field, logistics, or low-connectivity user segments.
• Multi-tenant and white-label branding: The PWA::update() facade plus PWA::processLogo() allow per-account app name, theme color, and icon at runtime. Relevant if you sell branded instances and want each tenant's install to look like their app, not yours.
• Scope negotiation with stakeholders: Because the capability is bounded and cheap, you can commit to "installable + offline page" now and explicitly defer push notifications, background sync, and app-store presence — decisions that are visible and easy to defend.

When to Consider This Package

Adopt when:

• You run a Laravel 8–13 monolith with Blade or Livewire layouts you control, served over HTTPS end to end.
• Your offline requirement is "a graceful fallback page," not a configurable caching strategy.
• public/ is writable and persistent across deploys (note: containerized/serverless or read-only-filesystem deployments break the manifest-update and logo-upload features — verify this before committing).
• You can live with the fixed public/logo.png convention, or you accept dynamic icon management through the provided upload path.
• You want a reversible, low-commitment experiment and can pin an exact version.

Look elsewhere when:

• You need real control over caching, precaching, cache versioning, or update flows — reach for Workbox or vite-plugin-pwa instead; this is a thin convenience layer, not a service-worker framework.
• Push notifications, background sync, or share-target integration are on the near-term roadmap.
• Your front end is a Vue/React SPA built through Vite, where the JS-ecosystem PWA tooling already lives in your build pipeline and would duplicate this package's output.
• You require vendor due diligence: 202 stars, 0 dependents, a single maintainer, no visible test suite, and a license GitHub reports as NOASSERTION despite an MIT badge in the README. Confirm the actual license text before it enters your dependency tree.
• The PWA becomes business-critical (e.g., a paid offline mode). At that point, own the service worker.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, reversible bet that makes our existing web app installable to a home screen and usable offline in degraded form — no app-store review, no second codebase, no per-download fees. Cost is roughly a day or two of engineering, delivered in an existing sprint. Success is measured by install rate, repeat-visit frequency among installers, and a drop in offline error reports; if those numbers don't move, we remove two Blade directives and a Composer dependency. It answers the "do we need a native app?" question with data instead of a workshop.

To engineering: One composer require, one Artisan install command, two Blade directives in the main layout, and config in config/pwa.php. No build-pipeline changes, no front-end framework coupling (works with Blade, Livewire, Vue 3, React), and it tracks Laravel versions through 13.x with frequent patch releases. Known constraints to design around: the icon filename is fixed to logo.png, the manifest and logo writes need a writable public/, HTTPS is mandatory for service workers, and the service-worker scope is intentionally shallow. Pin the version, wrap the directives in a feature flag, and fork if the maintainer goes quiet — the surface area is small enough that a fork is a maintenance afternoon, not a project.