Filament Pwa Laravel Package

Product Decisions This Supports

Installability as a distribution channel — without a native app. This package answers one specific product question: "can we get our admin panel onto a phone home screen without an app-store build, a review cycle, or MDM rollout?" For internal tools used by field, warehouse, clinic, or on-call staff, that is often the highest-value-per-effort mobile option available. It is a genuine substitute for a native shell in the narrow case where the need is "reachable and launchable," not "integrated with device hardware."

A build-vs-buy call worth making explicitly. The alternative is a hand-rolled service worker + manifest. That is not hard, but it is not free either — and it lands on the platform team's permanent backlog. Buying here means ~1 engineer-day of integration instead of owning a caching implementation forever. Buy wins if we do not already have one; if we do, this package is a parallel mechanism and should be declined.

Operational autonomy for branding. Manifest, icons, app name, and theme are editable from the Filament Settings Hub. That moves routine changes ("update the icon," "rename the app") off the engineering queue permanently. This is the most underrated benefit and the easiest one to sell internally.

A hard scope boundary to ratify up front. What we are buying is installability plus basic asset caching, on panel pages and — via @filamentPWA — on non-Filament surfaces like login and public pages. What we are explicitly not buying: push notifications, background sync, offline writes, per-tenant manifest scoping. If the roadmap item is actually "let field staff submit forms offline," this package does not satisfy it, and funding it as though it might is the expensive mistake.

A dependency calendar entry. Releases are breaking ports keyed to Filament majors (v4 → Filament v4, v5 → Filament v5 / Laravel 12–13 / PHP 8.2+). Adoption implies a paired upgrade every time Filament moves. That belongs in roadmap planning, not in a surprise.

When to Consider This Package

Adopt when: we are already standardized on FilamentPHP; we run (or are willing to run) the TomatoPHP settings hub rather than adding a second settings system for one feature; we can stand up an HTTPS-terminated staging origin so installability is testable at all; the surface is one or a few panels, not a multi-tenant estate; there is an identifiable cohort with real intermittent connectivity; the audience is internal/trusted, which keeps the blast radius small while auth-aware caching behavior is still unverified; and we want a reversible pilot rather than a platform commitment.

Look elsewhere when: we are not on Filament; the actual requirement is push, background sync, or offline data entry — nothing here delivers those; manifests must be tenant-branded or per-tenant scoped; shared-device or regulated environments make cache leakage after logout unacceptable and unverifiable; there is no named owner to absorb a paired Filament upgrade; a vendor SLA is a stated requirement; or we already maintain a service worker we would be duplicating.

Treat as disqualifying: 98 stars, zero dependents, single-maintainer family, no support channel. This is a pilot-scale bet. It is not a platform dependency, and it should not be described as one in any plan that outlives the pilot.

How to Pitch It (Stakeholders)

For executives (one paragraph): For roughly one engineer-day, we can make our admin panel installable on phones and desktops — no native app, no app-store review, no MDM rollout — and let operations update the app name, icons, and theme from the admin UI instead of filing engineering tickets. The change is additive and fully reversible: disable the plugin, drop one settings table, and we are back where we started. The trade-offs are honest and bounded: single-maintainer open-source dependency with no SLA, an upgrade obligation that follows every Filament major, and a security question we intend to answer before rollout rather than after. We are asking for a scoped pilot on one panel, not an enterprise commitment.

For engineering: Declarative plugin, one line in AdminPanelProvider, one @filamentPWA directive for non-panel blades, additive migration, and published config/views/lang — which means we own the override surface and a fork stays viable if upstream stalls. Two things are non-negotiable before this touches a panel holding PII: a security gate proving the service worker does not serve previously authenticated or stale content offline after logout or across users on a shared device, and a cache-busting step in the release checklist so installed clients actually receive new builds. Pin the version, assign an internal owner, and register the plugin behind a flag with per-panel scoping from day one.

The ask: a half-day spike to produce a working "Add to Home Screen" proof plus a runbook draft, one day of security verification that gates everything downstream, then a flag-gated pilot on a single panel with success metrics defined before launch — install rate, session length on degraded connections, and reduction in "couldn't load the app" tickets. Promote or remove on measured signal.