Getting Started

mobilekitv5 is a starter kit / Filament v5 companion, not a general-purpose API library — despite the "mobile-ready API helpers" language in its description. Practically, that means you clone or require it into a Laravel app that already runs Filament 5.x and NativePHP, then start building inside the conventions it lays down. If you are looking for a drop-in token-auth package, this is not it; read the source before committing.

Minimal path:

composer require jeffersongoncalves/mobilekitv5

Then publish whatever the kit ships, because almost every day-to-day customisation starts from a published file, not a method call:

php artisan vendor:publish --provider="Jeffersongoncalves\MobileKitv5\MobileKitV5ServiceProvider"
php artisan filament:upgrade

Register the plugin per panel (confirm the exact class name in the README / src/ — plugin naming is not derivable from the changelog, which for 5.10.1 is Dependabot noise only):

public function panel(Panel $panel): Panel
{
    return $panel
        ->id('mobile')
        ->path('mobile')
        ->plugin(MobileKitPlugin::make());
}

Where to look first, in order:

README — the only reliable statement of API surface. The changelog says nothing about behaviour.
src/ service provider and plugin class — what's registered, what's publishable, what config keys exist.
config/ — the defaults you'll actually be overriding.
resources/ (Blade) and the NativePHP entry point — this is where "mobile" actually happens.

First use case: stand up a throwaway Filament panel at /mobile in a scratch app, register the plugin, and click through. Do this before wiring it into a real panel with real resources. You are validating three things at once: Filament 5.10.x compatibility, that assets compiled, and that the NativePHP shell boots. If the panel renders and the native wrapper loads, you have de-risked 90% of adoption.

Version pinning note: the package's version number tracks Filament's, not its own. 5.10.1 means "pairs with Filament 5.10.1". Do not read it as ten minor releases of maturity.

Implementation Patterns

Treat it as a per-panel plugin, not a global framework. The single biggest architectural win is scoping the kit to one panel so mobile behaviour doesn't leak into your admin:

// Admin panel: untouched Filament
->id('admin')->path('admin')

// Mobile panel: MobileKit conventions
->id('mobile')->path('mobile')->plugin(MobileKitPlugin::make())

This gives you a clean blast radius: if the kit's rapid release cadence becomes a problem, you delete one ->plugin() call.

Wrap it behind your own thin layer. Given the release velocity (5.8.4 → 5.10.1 in one hop, driven by upstream Filament patches), do not let MobileKitPlugin and its classes appear in fifty places. Put registration and any config reads in one place:

// app/Support/Mobile/MobileKit.php
final class MobileKit
{
    public static function register(Panel $panel): Panel
    {
        return $panel->plugin(MobileKitPlugin::make())
            ->brandName(config('mobile.brand'));
    }
}

Swapping to hand-rolled Filament pages later becomes a one-file change.

Upgrade cadence — batch, don't drip. The kit ships on every Filament patch. Either:

Track closely: composer update filament/filament jeffersongoncalves/mobilekitv5 --with-dependencies in one step, then run tests and a mobile-panel smoke test.
Lag deliberately: pin the kit to a known-good minor and update on your own Filament upgrade beat.

What you should not do is let Dependabot auto-merge this package. A transitive Composer bump or a pnpm override change can break your asset build with no changelog signal.

Config-first customisation. Publish the config, edit it, ship it. This is the extension point that survives every patch release. Same for Blade views — override via published files under your resources/views/vendor/... path rather than subclassing internal kit classes.

Asset pipeline, if you fork. The pnpm-workspace.yaml overrides (shell-quote, source-map-js) and Vite patch bump are contributor-side. If you consume compiled assets via Composer, ignore them. If you fork and rebuild, you must use pnpm — npm/yarn will silently skip workspace-level overrides and you'll ship unpatched transitive deps.

Frontend/backend split pattern. For a NativePHP app, the pragmatic split is: Filament panel serves as the authenticated app shell (resources, forms, tables rendered in the native webview), and any genuinely device-specific work (camera, notifications, storage) lives in the NativePHP layer, not in the kit. Don't try to force the kit to be your device-API abstraction.

Testing pattern. Filament panels are testable with Livewire's testing helpers; the mobile panel is no different. Cover the resources the kit provides before you customise, so an upgrade that changes behaviour fails loudly in CI:

it('renders the mobile dashboard', function () {
    $this->actingAs(User::factory()->create())
        ->get('/mobile')
        ->assertOk();
});

Gotchas and Tips

The description and the package don't match. Marketing copy promises "mobile-ready API helpers, token-based auth foundations." The release notes show a Filament starter kit with NativePHP. Validate what actually exists in src/ before you design around it — the configurable-defaults and JSON-response helpers may be thin or absent.
Changelogs are useless for API changes. 5.10.1 contains only Dependabot bumps, a pnpm workspace refactor, and two transitive JS patches. No features, no fixes, no breaking changes documented. When you need to know what changed, diff the src/ and config/ directories between tags:
```
git diff 5.8.4..5.10.1 -- src/ config/ resources/
```
That range covers releases whose notes you were never given. Assume there are changes not reflected in the 5.10.1 PR list.
"Plugin does nothing" is almost always cache. First-line debugging, in this order:
```
php artisan filament:clear-cached-components
php artisan optimize:clear
php artisan about   # confirm no stale cached config/views
```
Second-line: the plugin is registered on the wrong panel (you're looking at /admin, it's on /mobile).
composer update conflicts — don't guess. After a kit bump, if resolution fails, ask Composer directly:
```
composer why-not filament/filament 5.10.1
composer why-not jeffersongoncalves/mobilekitv5 5.10.1
```
Never reach for --ignore-platform-reqs to force a Filament mismatch; you'll get runtime errors that look like kit bugs but are version skew.
Fork hazard: pnpm in CI. If you maintain a fork, the overrides now live in pnpm-workspace.yaml. An older pnpm in CI won't apply them. Pin a current pnpm version in CI and treat a pnpm upgrade as a required step of the fork's maintenance, not an optional one.
Don't patch vendor. Edits inside vendor/jeffersongoncalves/mobilekitv5 evaporate on the next release, and those releases come often. The durable extension points are: published config, published Blade views, panel-level plugin configuration, and your own Filament resources/pages that happen to live on the mobile panel.
Filament major-version drift is the real support risk. 0 dependents and 9 stars means you are effectively the integration tester. Watch for Filament 6; expect the kit to follow, and expect a hard cutover rather than a compatibility shim. Have a plan for the panel-registration line being the only thing you need to remove.
Starter kits age. Because this mirrors upstream so tightly, the value is in the initial scaffold, not in long-term library semantics. Budget for the possibility that in eighteen months you replace it with plain Filament resources on a mobile panel — which is cheap only if you kept the wrapper layer above. Build accordingly.

Mobilekitv5 Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips