Ux Native Laravel Package

Product Decisions This Supports

• Mobile presence without a second engineering team. symfony/ux-native lets an existing Symfony web app serve as the source of truth for an iOS/Android app via Hotwire Native (formerly Turbo Native). The product decision it unlocks is "ship a real App Store / Play Store listing using the web team we already have" versus "staff a React Native or Swift/Kotlin squad."
• Build vs. buy for the native shell glue. Everything this package does — detecting native user-agent traffic, rendering native-vs-web layouts, serving path configuration, and wiring native bridge components (camera, notifications, share, biometrics) into Twig/Stimulus — is work you would otherwise hand-roll and maintain. It is the difference between a two-week spike and a two-quarter platform investment.
• Roadmap sequencing. It makes "mobile app" a phase of the web roadmap rather than a parallel track. If the roadmap already includes Turbo/Stimulus/Live Components work, mobile becomes an incremental add-on instead of a fork in the architecture.
• Prioritizing server-driven vs. native-first surfaces. The package's path-configuration model is effectively a product lever: you decide per-screen whether a route opens in the native shell, in a modal, or falls back to the browser. That's a cheap way to ship a mobile MVP and promote screens to native treatment as usage data justifies it.
• Use-case fit. Strong for content-heavy, CRUD, account/dashboard, internal-ops, and marketplace apps where the UI is forms and lists. Weak for camera-heavy, offline-first, AR, heavy gesture/animation, or high-frame-rate consumer experiences.
• TCO and staffing decisions. Converts a native-headcount question into a PHP-headcount question, which is usually cheaper and faster to hire for — but concentrates risk in one web codebase and one release process for both surfaces.

Important framing caveat for a Laravel/PHP shop: this package is Symfony-only (it is a Symfony UX bundle and assumes Symfony's DI, routing, Twig, and Stimulus conventions). It is not a Laravel package and will not drop into a Laravel app. If the team is on Laravel, the equivalent decision is "adopt Hotwire Native with turbo-laravel plus a small amount of custom path-configuration and bridge code" — the architecture is the same, but you are taking on the glue yourself rather than buying it pre-built.

When to Consider This Package

Consider adoption when most of the following hold:

• The product is already a Symfony application, ideally on Symfony 6.4/7.x with Twig, and the team already uses Turbo or Stimulus (or is willing to adopt Symfony UX broadly).
• You need a mobile app for an existing web product and the screen inventory is dominated by forms, lists, detail pages, auth, and notifications — not custom native canvas work.
• Time-to-market matters more than native polish. A store-listed app in weeks beats a best-in-class native app in nine months.
• You have PHP engineers but no mobile engineers, or mobile capacity is the bottleneck.
• You can accept fast-moving, pre-1.0 dependencies and pin versions in composer.json.

Look elsewhere when any of the following hold:

• Maturity risk is disqualifying. 12 GitHub stars and a single recent release date indicate an early, thinly adopted project. Symfony UX packages have historically carried an @experimental covenant with breaking changes between minors. Assume no support SLA, thin documentation, few StackOverflow answers, and no guarantee of a maintainer in 18 months. If the app is revenue-critical and you cannot vendor/fork it, that is a stop sign.
• Laravel or non-Symfony stack. Wrong ecosystem; you would be rebuilding the package.
• You need genuinely native capability — offline-first sync, background processing, complex animation, Bluetooth, AR, heavy media. Hotwire Native's server-driven model fights you here.
• App Store review risk is unacceptable. Hybrid shells are generally accepted, but Apple has historically scrutinized "just a website wrapper." If your app is a thin repackaging of a marketing site, expect rejection regardless of framework.
• You need a vendor contract, indemnity, or security review sign-off. MIT + 12 stars will not clear most enterprise procurement gates without an internal owner.

Recommended posture: time-boxed spike, not a commitment. One engineer, two to three weeks, one representative end-to-end flow (login → list → detail → push notification). Gate the go/no-go on: does it build and submit cleanly to both stores, does the bridge cover our top three device capabilities, and can we pin and own a fork if the upstream stalls.

How to Pitch It (Stakeholders)

For executives — one paragraph: We can put a real app in the App Store and Play Store using the web team and the web codebase we already have, rather than hiring a separate mobile squad. symfony/ux-native is the open-source adapter that lets our Symfony app render natively inside a lightweight iOS/Android shell, including push notifications and device features, with per-screen control over what feels native. The trade-off is honest: it is a young, low-adoption MIT project (12 stars, one release), so we should treat it as a calculated bet with a fallback — a short spike first, version pinning, and a documented exit to a fully native build if it doesn't hold up. The upside is months of schedule and a meaningful headcount line avoided; the downside is bounded to the cost of the spike.

For engineering: This is the Symfony-side glue for Hotwire Native — native request detection, native layouts, path configuration, and bridge components wired into Twig/Stimulus. It saves us writing and maintaining the Turbo Native integration ourselves and keeps our release process unified across web and mobile. Risks we should name up front: pre-1.0 API churn, minimal community and docs, effectively a bus-factor of one, and no procurement-grade support. Mitigations: vendor the dependency or maintain a fork from day one, pin to an exact version, keep a thin internal abstraction over the bridge calls so swapping to a hand-rolled or fully native implementation stays a contained change, and instrument the native shell separately from web analytics so we can measure whether the hybrid approach is actually paying for itself. If the team is not on Symfony, this package is the wrong tool — we would implement the same architecture with turbo-laravel and our own bridge layer, and should budget accordingly.