Comparison
Firstlight UI vs NativePHP Mobile UI
They are not alternatives. NativePHP Mobile UI is the native foundation; Firstlight UI is a curated form and control layer installed alongside it. Mobile UI renders native controls from Blade. Firstlight adds the Laravel contracts NativePHP does not ship — screen-level validate(), a once-run submit(), and Gate-backed authorize().
If you are choosing between them, you are asking the wrong question — Firstlight depends on Mobile UI and cannot be used without it. The useful question is whether you want the form, validation, and authorization semantics decided once for you, or written per screen in your own app.
What each one is responsible for
| Concern | NativePHP Mobile UI | Firstlight UI |
|---|---|---|
| Role | The native foundation for NativePHP apps | A curated form and control layer on top of it |
| Relationship | Required. Firstlight depends on it | Installed alongside Mobile UI, never instead of it |
| Component coverage | Comprehensive native catalogue | Curated — 27 form, selection, display, and action controls |
| Control contracts | Each control exposes its own platform-shaped API | One contract across every control — stable public value, and the same label, error, disabled, and required semantics |
| Rendering | SwiftUI on iOS, Jetpack Compose on Android | The same renderers, via Mobile UI’s extension points |
| Element tree | Publishes the shared EDGE element tree | Publishes into that same element tree |
| Theme | Supplies the semantic theme | Inherits it — no parallel theme to maintain |
| Screen-level validate() | Not provided | ValidatesFields — validate() and validateOnly() |
| Validation message display | @nativeError renders as sibling text; a thrown ValidationException reaches the generic overlay | Binds the first MessageBag message to the field’s native error slot |
| Guarded submit | A press is an ordinary PHP method; re-entry is yours to handle | SubmitsForms — validates, runs the action once, optionally sends success Feedback |
| Gate-backed authorize() | No Gate helpers on screens; an uncaught authorization exception opens the overlay | AuthorizesActions — allows(), denies(), authorize() hide, disable, or send danger Feedback |
| Licence and price | See the NativePHP project | MIT, free, no paid tier |
| Maturity | The established foundation | Alpha — API may still change |
Every row above describes a difference in responsibility, not in quality. Firstlight exists because these three PHP concerns are the ones every NativePHP app ends up rebuilding, not because the foundation is lacking.
When to add Firstlight, and when to stay on Mobile UI alone
Add Firstlight when
- Your app has real forms, and you are writing the same validation and submit plumbing on every screen.
- You want Laravel validation messages to land on the native field rather than as sibling text or a generic overlay.
- You need Gate and Policy decisions to hide or disable native controls consistently.
- You want field semantics decided once across a codebase or a team.
Stay on Mobile UI alone when
- Your app is mostly display and navigation, with few or no forms.
- You need a native control outside Firstlight’s curated catalogue — reach for Mobile UI directly, and mix the two freely.
- You cannot take an alpha dependency, and would rather wait for the API to settle.
Common questions
- Does Firstlight UI replace NativePHP Mobile UI?
- No. Firstlight is installed alongside NativePHP Mobile UI and depends on it. Mobile UI supplies the native foundation — the EDGE element tree, the SwiftUI and Jetpack Compose renderers, the semantic theme, and the event lifecycle. Firstlight adds a curated form and control layer on top of it.
- What does Firstlight add that NativePHP does not have?
- Two layers of contract. At the control level, every Firstlight component exposes a stable public value and the same field semantics — label, value, error, disabled, and required behave identically across text fields, selects, pickers, sliders, and choice groups, so a form does not need per-control special cases. At the screen level, NativePHP EDGE has no validate(), no once-run submit helper, and no Gate-backed action guard; Firstlight adds ValidatesFields, SubmitsForms, and AuthorizesActions, so validation messages bind to the native field error slot, submits run once and publish native Feedback, and Gate decisions hide or disable native controls instead of reaching the generic error overlay.
- Can I use Firstlight and NativePHP Mobile UI components on the same screen?
- Yes. Firstlight is built on Mobile UI’s ordinary component extension points and publishes into the same element tree, so Firstlight and Mobile UI components compose together and share the same theme and event lifecycle.
- Is Firstlight UI free?
- Yes. Firstlight UI is open source and free to use, released under the MIT licence. There is no paid tier.
- Why is the Firstlight component catalogue smaller than Mobile UI’s?
- By design. Mobile UI aims for comprehensive native coverage. Firstlight is a curated catalogue of 27 form, selection, display, and action controls, and grows only where a reusable product-level contract saves every app from solving the same problem again.
- Is Firstlight UI production ready?
- Firstlight is alpha. The API may still change between releases. It is a reasonable choice for evaluation, prototypes, and teams comfortable tracking an early package, but pin your version and read the release notes before upgrading.