Mobilekit Laravel Package

Technical Evaluation

Baseline. No prior assessment existed; this establishes the baseline at v3.3.56. jeffersongoncalves/mobilekit is a Laravel application-scaffolding package that pairs a Filament v3 admin panel with a NativePHP Mobile shell and ships user/admin models, Filament resources, and login wiring.

Architecture fit. Good fit where we are standardizing on Filament for back-office and want one Laravel codebase to emit a mobile artifact. Poor fit where we already own a user/auth domain or a non-Filament admin. PR #118 ("Use user/admin packages for models, resources and login") means the package now assumes its own user/admin domain rather than deferring to ours — that is the single most consequential line in this release and it landed in a patch version.

Integration feasibility. Composer-installable, dependencies track mainstream lines, CI is standardized. The caveat is categorical: this is a scaffold, not a library. The value is generated code we then own and mutate. That makes adoption a fork-and-own decision, not a versioned-dependency decision. Budget for divergence; do not assume a clean composer update path across releases like #118.

Technical risk.

• Semantic versioning is not observable. A structural auth/model change shipped in 3.3.55 → 3.3.56 (patch). Treat every release as potentially breaking.
• Filament 3 pinning. The package tracks the Filament 3.3.x patch line. Filament 4 exists; upgrade debt accrues to us at some future date with no visible plan upstream.
• NativePHP Mobile 4.2.0 → 4.3.0 (minor). The mobile runtime is the least stable surface in the stack; native build reproducibility across dev machines and CI is the largest unknown.
• Bus factor 1. This release adds GitHub Sponsors and Buy Me a Coffee links — fine for engineering, but it is a sustainability signal, not a support commitment. No second maintainer or security policy is evident.
• CI governance. PR #119 enables auto-merge of Dependabot GitHub Actions minor/patch updates into main. Automated supply-chain movement into the default branch is a gap we inherit if we consume the repo directly.
• Transitive dependency patching. pnpm overrides and patches for shell-quote and source-map-js indicate we inherit dependency drift that upstream is papering over.

Key questions (answer before any commitment).

1. Is #118 opt-in or forced? Can we retain our existing User model and auth guard, or does the scaffold overwrite them? Blocking.
2. Which Filament major is supported, and is a v4 track planned on any timeline?
3. What is the PHPStan level and does CI fail on static-analysis errors? What is actual coverage on the mobile build path (not just the Filament path)?
4. Is there a per-release upgrade guide, or must we infer breakage from PR titles?
5. What native toolchain versions (Xcode, Android SDK, JDK) are supported, and is the build reproducible in CI?
6. Who is the secondary maintainer, and what is the security-response expectation?

Recommendation. Pilot only, time-boxed, on a non-critical internal admin. Do not adopt as a versioned dependency on a revenue-path application. If adopted, vendor/fork at a pinned commit and own the diffs.

Integration Approach

Stack fit. Laravel target stated as Laravel 13 (per the composer description fix — verify against composer.json requirements, not release-note prose). Filament 3.3.56, NativePHP Mobile 4.3.0, PHP 8.4 in CI. Frontend is pnpm + Vite with overrides in pnpm-workspace.yaml — we must standardize on pnpm; npm or yarn will not honor the patches. Confirm our runtime image matches PHP 8.4.

Migration path. Greenfield only. There is no migration path for an existing application: the package generates models, resources, and login. If we already have users/roles/permissions, we would be reconciling two auth domains. Sequence:

1. Spin a throwaway Laravel app, install exactly 3.3.56, generate the scaffold, and diff output against our conventions.
2. Decide fork-and-own vs. tracked dependency; record the decision and the owner.
3. If forking: pin the commit, strip sponsor/docs noise, retain only the Filament resources and native shell we need.

Compatibility.

• Pin the exact version (3.3.56), not ^3.3. Patch releases have shipped structural changes.
• Do not independently bump Filament; use the version mobilekit ships.
• Validate NativePHP 4.3.0 with a native build before any feature work — it is a minor bump on the riskiest surface.
• Check #118's "user/admin packages" for collisions with any existing auth package (Breeze, Jetstream, Filament's own panel auth).

Sequencing. (1) toolchain reproducibility spike → (2) scaffold diff review against conventions → (3) auth/model reconciliation decision → (4) one read-only admin screen behind our SSO → (5) native build on iOS and Android → (6) go/no-go. Start with the toolchain, not the mobile build: the native build is the longest pole and the least reversible, but the auth question is the cheapest one to answer and can kill the whole initiative.

Operational Impact

Maintenance. The dominant ongoing cost. We will own the generated application code, the pnpm overrides and patches, and the native build configuration. Budget roughly one engineer-day per upstream release for triage. This release alone contains 28 PRs, largely automated — a high-churn, low-signal stream that still requires a human to spot the one structural change buried in it.

Support. Community-only, single maintainer, no commercial support, no documented SLA. Internal implication: name an internal owner before adoption and maintain a patchable fork. The escalation path is "we fix it ourselves."

Scaling. The admin side scales like any Filament application — standard Laravel queue, cache, and database levers, nothing package-specific. The mobile side is where scaling breaks: app-store release cadence becomes a hard dependency for shipping changes, including admin-side fixes bundled into the binary. Determine early whether the Filament admin is served remotely and only the shell is native (low release coupling) or whether resources are compiled into the binary (high coupling, and a store-review bottleneck for every fix).

Failure modes and mitigations.

• Silent breakage on composer update (structural change in a patch release) → exact pin, committed lockfile, CI diff on generated code.
• Native build drift (SDK/Xcode/JDK mismatch) blocking releases → pinned containerized build image, native build exercised on every PR.
• Upstream abandonment (bus factor 1) → fork, or accept rewrite cost as a known liability.
• Filament 3 → 4 wall: Filament 3 eventually stops receiving security patches while mobilekit has not moved → track upstream status and set a dated reassessment.
• Actions supply chain: auto-merged workflow updates → pin third-party actions to SHAs in our fork.
• Auth-domain collision if #118 forces its own user model → verify before building anything.

Ramp-up. Low for the Laravel/Filament half — a competent Laravel developer is productive in days. High for the NativePHP half — native toolchain, code signing, store submission, and device/simulator debugging are a distinct skill set. Assume 2–3 weeks before one engineer is genuinely productive end-to-end, and plan for that person to be the sole owner initially. Treat that concentration as a risk to be actively managed, not an accepted baseline.