Mobile Bottom Nav Laravel Package

Product Decisions This Supports

• Whether to invest in mobile for the admin/back-office panel at all. The most expensive way to answer "do our operators actually need admin on a phone?" is a design sprint and a custom mobile shell. This package answers it for the price of a Composer install: register it, ship it to a pilot cohort, and read the usage data. It converts a strategy question into a two-day experiment.
• Roadmap sequencing: navigation first, everything else later. Mobile admin is not one feature, it is a stack (navigation, tables, forms, modals, actions). This package deliberately ships only the navigation layer and says so in its own README, pointing at a companion preset for the rest. That gives you a legitimate phase-one deliverable — "mobile navigation is live" — without silently committing to the full mobile-first rebuild.
• Build vs. buy for panel UX chrome. Anything that reproduces Filament's navigation on a second surface is a maintenance tax: every Filament upgrade, every new page, every permission rule has to be re-mirrored. This package reads Filament's navigation registry at render time instead of duplicating it, so new pages and visibility rules propagate for free. Buying (adopting) here is cheaper than building and cheaper than maintaining.
• Use cases worth validating. Field sales and service reps checking records between visits; warehouse and clinic staff working from a phone or tablet at the point of activity; on-call engineers acknowledging alerts; approval flows for managers who are not at a desk. If your admin usage is 95% desktop analysts doing bulk data work, this is not your roadmap item.
• Prioritization input for the mobile backlog. Once the bar is live, the next requests will sort themselves: tables that scroll sideways, out-of-reach action buttons, modals that should be slide-overs. The bar is a cheap instrument for generating evidence about which of those actually matters, rather than guessing.
• Risk posture decisions that are genuinely product calls, not engineering details. The plugin hides Filament's topbar hamburger below 1024px by default. That is a visible change to the panel shell affecting every mobile user, and it should be an explicit approved decision with a rollback plan, not something that arrives inside a dependency bump. Same for the version-floor recommendation: the package supports any Filament 4.x/5.x, but recommends 4.11.5+/5.6.5+ because earlier releases carry four published advisories, including an unauthenticated temporary file upload on auth pages. Choosing to stay on an older patch is a product risk acceptance, not a technical one.

When to Consider This Package

Adopt when most of the following hold:

• You run a Filament v4 or v5 panel and your admin surface is the thing that needs to be usable on a phone. This package has no value outside Filament.
• Mobile admin is a hypothesis or an early bet, not a funded program. The install-and-register cost is hours, there are no migrations, tables, queues, or persistent state, and rollback is removing one line from a panel provider. That risk profile is ideal for a pilot.
• Your navigation is already the source of truth in Filament. If page registration, grouping, sorting, and permission-based visibility all live in the panel provider, the auto-extraction does real work for you and the bar will stay correct as the panel grows.
• You want the mobile win without a design-system project. No custom theme, no Tailwind @source config, no asset build step. If your team has no front-end capacity and no appetite for owning a theme, this is the pragmatic path.
• You need the small things that signal real-world use: dark mode, safe-area insets for notched devices, badges for pending counts, and a "More" button that opens the existing sidebar rather than inventing a new menu.
• You can live with a young, narrowly-scoped dependency. Reasonable for an internal admin panel; see the caveats below before putting it anywhere customer-facing.

Look elsewhere — or plan to fork/vendor — when any of these are true:

• You are not on Filament. Nothing here transfers.
• You need the bar to match a brand design system. CSS is inline by design, which keeps rollout cheap but means the bar will not inherit your tokens or theme conventions. If pixel-level brand fidelity on mobile chrome is a requirement, budget for overriding the published Blade view or building it yourself.
• You need mobile navigation to be a product surface, not a convenience. Custom gestures, offline state, push-driven deep links, per-role bespoke layouts — that is an application architecture conversation, not a plugin.
• You need the rest of the panel to be mobile-first too. This package fixes navigation and nothing else, on purpose. Tables will still scroll sideways and modals will still be centred dialogs. If the mandate is "the whole panel feels native on a phone," scope the companion preset or a broader effort; adopting this alone and calling mobile "done" is the failure mode to avoid.
• Dependency governance is strict. Twenty stars, zero dependents, effectively a single maintainer, and a release cadence driven by one person's attention. It is MIT-licensed and trivially removable, which mitigates most of this — but if your policy blocks low-adoption packages outright, that policy will block this one, and the honest alternative is a small internal implementation of the same idea.
• You want someone else contractually on the hook. There is no vendor, no support tier, no SLA. Internal admin tooling tolerates that; anything with an external user base does not.

How to Pitch It (Stakeholders)

To executives — one paragraph: We can test whether our admin panel needs to work on phones without funding a mobile project. This is a small, MIT-licensed, open-source add-on that puts a thumb-reachable navigation bar at the bottom of our existing admin panel on phones and tablets, and hides itself on desktop. It reuses the navigation and permissions we already have, so it does not create a second place to maintain. It is roughly a day of engineering, carries no database or infrastructure change, and can be removed in minutes if we do not like it. It buys us evidence — do our field and on-call staff actually use admin on mobile, and what do they reach for first — before we commit to the larger work of making tables, forms, and modals mobile-friendly. The one decision I need from you is approval to change the mobile header: the plugin hides the existing menu button because the new bar opens the same menu.

To engineering — the honest brief: A thin presentation-layer plugin for Filament panels. One Composer dependency, one ->plugins([MobileBottomNav::make()]) registration, no migrations, no theme, no build step; CSS is inline. It extracts items from Filament's navigation registry at render time rather than duplicating them, so ordering follows the sidebar exactly (this was a real bug fixed in v1.3 — earlier versions sorted globally by raw sort value and ignored group order). Config is fluent and all optional: slot count, a "More" button that opens the sidebar, custom MobileBottomNavItem arrays with closure-based labels, badges, and visibility, and the render hook. The one behavioural change beyond the bar is hideSidebarToggle(true) by default, which hides the topbar hamburger below 1024px — only when the bar actually rendered and "More" is enabled, so the sidebar is never unreachable. Review and approve that explicitly.

Known caveats to state up front, not after launch: low adoption (20 stars, 0 dependents), effectively single maintainer, so treat it as vendorable and expect to own it if it goes stale. It supports Filament ^4.0 || ^5.0, but pin the panel to 4.11.5+ or 5.6.5+ — earlier patches carry four advisories including an unauthenticated temporary file upload on auth pages — and run composer audit rather than relying on the plugin's constraint. Inline CSS means no design-token inheritance; if brand fidelity on mobile chrome matters, budget for overriding the published view. And scope expectations: this fixes navigation only. Tables still scroll sideways and modals still open as centred dialogs, so it should be framed as phase one with a defined follow-on, not as "mobile is done."