Mobilekitv4 Laravel Package

Product Decisions This Supports

• Build vs. buy for mobile delivery: MobileKit is not a dependency you composer require — it's a fork-and-own starter kit. The real decision it informs is "do we scaffold our mobile app from a Laravel/Filament template, or start from a blank NativePHP project / go fully native?" Choose the template when ~2–4 weeks of boilerplate (auth, navigation shell, Filament admin surface, build config for iOS/Android) is worth more than the cost of pruning someone else's opinions.
• Roadmap sequencing — internal tooling before consumer mobile: The Filament + NativePHP combination is strongest for operator-facing apps: field ops, inventory counts, approvals, inspections, on-call dashboards. These justify a mobile roadmap item even when a consumer app wouldn't clear the bar. Use this to sequence "companion app for our back office" ahead of "customer-facing iOS app."
• Platform consolidation / stack reuse: If the org already runs Laravel + Filament, this lets one team own web admin and mobile from a single repo, single language, single auth model. That is a headcount and hiring decision as much as a technical one — it removes the "we need a Swift/Kotlin contractor" line item from the budget.
• Cheap validation of the NativePHP bet: Fork it, ship a throwaway internal app in 3–4 weeks, and use the result to answer the strategic question "is PHP-in-a-native-shell acceptable for our product surface?" before committing a roadmap quarter. The star count (14) and single-maintainer profile mean this is a probe, not a foundation.
• Feature scoping signal: What ships in the template (admin CRUD, auth, standard nav) tells you what the ecosystem considers solved. Anything you'd have to build yourself — offline sync, push, deep device APIs, background tasks — is where your actual product differentiation and your real estimate live.
• Vendor/exit-risk review: Because you own the fork, the lock-in is to NativePHP and Laravel 13/Filament 4, not to this package. That reframes the risk conversation from "is this repo maintained?" to "can we upgrade our fork when NativePHP changes?" — a much more tractable question.

When to Consider This Package

Adopt it as a starting scaffold when most of these hold:

• Your team is already fluent in PHP/Laravel and Filament; nobody wants to learn Swift and Kotlin.
• The target app is internal, low-to-moderate user count, CRUD- and workflow-heavy, and does not need a bespoke, high-frame-rate UI.
• You need iOS and Android from one codebase on a short timeline, and a web admin panel alongside it.
• You can accept pinning to Laravel 13.x / Filament 4.x / current NativePHP and doing manual merges on upgrades (there is no composer update path for a fork).
• You are explicitly treating it as a spike, a POC, or an internal-tools accelerator — with a named owner who will review every line before it reaches production.

Look elsewhere when:

• Consumer-grade UX is the point. Filament is a web admin framework; rendering it inside a native shell caps you on animation, gesture, and platform-idiomatic design. Go React Native, Flutter, or native.
• Deep device integration is core: camera pipelines, BLE, AR, background location, heavy offline-first sync, push at scale, HealthKit/Google Fit, payment terminals. Verify each against NativePHP's current plugin coverage before you shortlist this at all.
• You need support and a security response process. 14 stars implies a solo maintainer, no CVE channel, no SLA, and a real bus-factor. That's disqualifying for regulated, payment, or PII-heavy products without an internal owner who can carry the fork.
• You're on a mature Laravel version or a stable Filament release. Chasing 13.x/4.x means ecosystem packages you depend on may not be compatible yet; that compatibility tax lands on your team, not the maintainer's.
• Onboarding velocity matters more than scaffolding speed. A kit with strong opinions and thin docs costs new engineers more than a clean, well-documented blank project — especially once you've diverged from upstream and can't consult its issues or docs.

How to Pitch It (Stakeholders)

One line: MobileKit is a Laravel/Filament starter kit that lets our existing PHP team ship a native-shell iOS and Android app — plus its admin back end — from one codebase, in weeks instead of quarters.

For executives: It converts a mobile roadmap item from "hire a mobile team" into "reuse the team we have." The near-term value is a fast, low-cost POC that tells us whether PHP-based mobile is viable for our product before we commit budget. Treat the output as an internal-tools accelerator and a decision-making instrument, not a production platform. Cost of being wrong is a few engineer-weeks; cost of skipping the experiment is a quarter spent guessing.

For engineering: It's a fork, not a dependency — we own and maintain every line, we pin Laravel 13 / Filament 4 / NativePHP, and upgrades are manual merges. The genuine technical risk is NativePHP's device-API coverage and its maturity, not this repo; the repo is just convenient glue. Proposal: timebox a two-week spike against our top three must-have device capabilities, and only then decide whether to build on the fork or fall back to a conventional mobile stack. Assign an owner from day one, and don't merge anything we wouldn't be comfortable maintaining ourselves for two years.