Product Decisions This Supports
- Mobile-first internal tooling: a Filament plugin that layers a PWA manifest, service worker, install prompt, and offline shell onto existing admin panels. If your roadmap includes "field teams / on-call engineers / ops staff need to use the admin from a phone," this closes that gap without a mobile app project.
- Build vs. buy on the PWA wrapper: the alternative is hand-rolling
manifest.json, a service worker, icon sets, cache-invalidation strategy, and iOS install quirks. That's typically 1–3 engineer-weeks plus ongoing platform churn (iOS Safari behavior changes often). A plugin converts that into a dependency.
- Roadmap de-risking for offline/degraded-network workflows: relevant where admin users work in warehouses, clinics, job sites, or on flaky mobile networks. Note the important limit: the PWA shell loads offline, but Filament forms writing to the DB still require connectivity unless you build queueing on top.
- Distribution decision for a single Filament panel: if you run one internal panel, the PWA value is mostly cosmetic-plus-installability. If you run several panels or ship a productized admin to customers, the leverage is higher.
- Not a customer-facing product decision: this does not make your customer-facing app a PWA. It only affects the Filament admin surface.
When to Consider This Package
Consider adoption when:
- You are on Filament v3/v4 and the admin is genuinely used on mobile or tablet by a meaningful share of users (check analytics first — this is the single most important input).
- You want home-screen installability, a splash/launch experience, and a branded app-like entry point without an App Store/Play Store submission.
- You need a cached app shell so the admin doesn't show a browser error page on a dropped connection.
- You have appetite for a small, single-maintainer dependency on a non-critical surface (the admin), not a revenue path.
Look elsewhere / build in-house when:
- The v4.0.0 signal is unresolved. This release is a major version bump with a changelog link and no enumerated breaking changes. Major bumps on a plugin that hooks into Filament's asset pipeline and service worker registration are exactly where silent breakage lives. Until you can read the actual commit diff, treat v3→v4 as an unverified migration.
- Vendor concentration is a blocker. Single-author package, low ecosystem redundancy, no visible commercial backing. Acceptable for admin chrome; not acceptable if PWA becomes a contractual requirement.
- You need real offline data capture. The plugin gives you a shell, not a sync engine. Offline writes, conflict resolution, and background sync are your problem — budget for that separately or the "offline" claim oversells itself to stakeholders.
- You need push notifications at scale. Service-worker push is a different problem (VAPID keys, subscription storage, delivery infra). Confirm the plugin actually covers it before promising it in a roadmap.
- You're on an older Filament major. Version alignment between plugin, Filament, and Laravel is the most common failure mode. Pin and test.
How to Pitch It (Stakeholders)
For executives (one paragraph): Our Filament admin is a web app that our internal users increasingly open on phones, where it behaves like a website — no icon, no offline tolerance, no app-like launch. This package adds Progressive Web App capability to the admin for a fraction of the cost of building or maintaining a mobile app: installable icon, splash screen, cached shell. It's a small dependency scoped entirely to internal tooling, with no customer-facing exposure and no App Store dependency. The current release (v4.0.0) is a major version — we'd pin it, validate it in staging, and treat the upgrade as a contained spike rather than a commitment.
For engineering: small Filament plugin, adds manifest + service worker + install UX to the panel's asset pipeline. The upside is deleting bespoke manifest/SW code and inheriting someone else's handling of iOS quirks. The costs are: (1) a single-maintainer dependency in the panel boot path; (2) a v4.0.0 major bump with no published breaking-change list, so the changelog comparison diff is mandatory reading before upgrade; (3) service-worker caching interacting with Filament's asset versioning — verify cache busting on deploy, or users get stale JS after releases, which is a genuinely nasty class of bug; (4) no offline write path, so don't let the word "offline" leak into requirements docs without qualification.
Recommendation: timeboxed evaluation spike in a staging panel — install, verify install prompt, verify service worker invalidation across a deploy, test on iOS Safari. Ship only if mobile admin usage is measurable. Pin the version either way.