Mobile Ui Laravel Package

Technical Evaluation

Architecture fit. nativephp/mobile-ui is a presentation-layer package for NativePHP for Mobile — it exposes native UI primitives (navigation bars, tab bars, sheets/modals, toasts, safe-area handling) to Laravel Blade/Livewire views through the NativePHP bridge. Architecturally this is a thin, high-leverage dependency: it touches only the view layer, so it does not entangle domain logic, queues, or persistence. That is a favorable fit if and only if the target application is already a Laravel + Blade/Livewire monolith and the mobile client is committed to the NativePHP runtime. If we are instead shipping a conventional API + separate native/React Native client, this package is irrelevant and should be rejected on fit grounds alone.

Integration feasibility. Mechanically trivial: composer require nativephp/mobile-ui, register the service provider, and consume components in Blade. MIT licensing removes commercial friction and redistribution concerns. The blocker is not effort, it is verifiability: the repository is listed as unknown, star count is 21, and the recorded last release (2026-10-29) is future-dated relative to any sane evaluation window. That combination means our dependency metadata is stale or unreliable. Before any commitment, we must confirm the package on Packagist, identify the actual maintainer/org, and check whether it is an official NativePHP artefact or a third-party add-on riding the namespace.

Technical risk — Medium-High.

• Adoption risk (highest): 21 stars implies a near-zero user base. We will be an early production adopter; every device-specific defect becomes our defect.
• Bus-factor risk: almost certainly one or two maintainers with no visible governance, no CVE process, no LTS branch.
• API stability: pre-1.0 packages in the NativePHP ecosystem have historically renamed components and changed bridge contracts between minor versions.
• Platform parity: any component abstraction over UIKit and Android Views will diverge on edge cases (safe areas, keyboard avoidance, back-button semantics, dark mode).
• Bridge performance: chatty native calls from Livewire re-renders can produce visible jank; no published benchmarks.
• Opportunity signal (8.87) is strong but asymmetric — it reflects upside if NativePHP mobile adoption inflects, not current maturity. Treat it as a cheap option, not a foundation.

Key questions to resolve before approval.

1. Is this an official NativePHP organisation package, and does it version-lock to a specific nativephp/mobile runtime version?
2. What is the actual component inventory, and what percentage of our designed screens does it cover versus hand-rolled bridge code?
3. Does it degrade gracefully — if a component is unavailable, do we get a web fallback or a hard crash?
4. What is the release cadence and changelog discipline over the last 6 months (not the anomalous 2026 date)?
5. Are there example apps, CI matrices against real devices, or any production references?
6. What is the escape hatch if the package is abandoned — how much of our view layer would need rewriting?

Integration Approach

Stack fit. Requires Laravel 10/11+, PHP 8.2+, and a pinned nativephp/mobile runtime. Verify the Composer constraint graph first: this package and nativephp/electron (desktop) frequently pull conflicting illuminate/* ranges. If we ship both desktop and mobile from one codebase, resolve the constraint set before writing any UI.

Migration path. Do not retrofit existing Blade screens one-by-one. Instead, introduce an internal wrapper layer — e.g. resources/views/mobile/ partials plus a small MobileUi facade — that maps our design-system components onto mobile-ui primitives. All application views depend on the wrapper, never on the vendor namespace directly. This costs roughly 2–4 engineer-days and converts an abandonment scenario from "rewrite the view layer" into "reimplement ~15 partials."

Compatibility. Treat the package as coupled to a runtime version, not to Laravel. Pin both nativephp/mobile and nativephp/mobile-ui to exact versions with a documented upgrade ritual, and forbid ^ ranges in this dependency group. Maintain a device matrix (minimum: one modern iOS, one modern Android, one small-screen Android) because parity bugs are the dominant failure class.

Sequencing.

1. Week 0 — Verification spike (2 days): locate repo, confirm maintainership, install into a throwaway Laravel app, render 3 representative screens on physical devices.
2. Week 1 — Coverage audit: map the design system against the component inventory; quantify the gap we must build ourselves.
3. Week 2 — Wrapper layer + feature flag: build the abstraction and gate adoption behind a config flag so we can revert to web-rendered views per screen.
4. Week 3–4 — Vertical slice: one complete user journey end-to-end, including offline and error states.
5. Go/no-go: proceed only if the spike shows zero hard-crash failure modes and the maintainer responds to a GitHub issue within ~5 business days.

Operational Impact

Maintenance. Budget an ongoing ~10–15% of mobile engineering capacity for vendor-defect triage and upgrades. Because the user base is tiny, most bugs will be found by us first; the practical model is "we maintain a fork we occasionally rebase," not "we consume a library." Set up a private fork from day one with a documented patch branch.

Support. No commercial support, no SLA, no security advisory channel visible. Internal escalation must route to a named engineer with bridge-level debugging skills (Xcode/Android Studio, not just PHP). This is the single largest hidden cost: PHP developers cannot debug native-layer failures, so we need at least one person comfortable on both sides of the bridge.

Scaling. Rendering cost is client-side, so server scaling is unaffected — a genuine advantage over server-driven UI approaches. The scaling concern is fleet heterogeneity: as device coverage grows, the untested-surface area grows faster than with a mature framework because the abstraction is thin. Instrument client-side crash/exception reporting before launch, not after.

Failure modes.

• Bridge timeout / silent no-op — native call never resolves; UI appears frozen. Requires per-component timeout handling and a visible fallback.
• Platform divergence — component renders correctly on iOS, clipped on Android. Mitigated only by device testing, not unit tests.
• Breaking minor release — pinned versions plus a fork make this survivable.
• Abandonment — wrapper layer plus fork reduces to a bounded, known cost.
• Version-skew with the runtime — enforce lockstep upgrades; a mismatch here produces the hardest-to-diagnose failures.

Ramp-up. Expect 1–2 weeks before a mid-level Laravel developer is productive, and longer (3–4 weeks) before they can diagnose bridge failures unaided. Onboarding cost is front-loaded and mostly about the native shell, not the PHP package.

Bottom line for the decision log: approve as a time-boxed, feature-flagged bet on NativePHP mobile — justified by low integration cost, an MIT license, and strong opportunity signal — but conditioned on the verification spike passing. Do not approve it as a foundation for a flagship mobile product until the package demonstrates a real maintainer and a stable 1.0.