Ux Native Laravel Package

Technical Evaluation

Architecture fit. The first thing to flag: symfony/ux-native is a Symfony UX package, not a Laravel package. Our stated estate is Laravel/PHP, so this is a framework mismatch, not an install-and-go dependency. Symfony UX packages are built around FrameworkBundle conventions — a bundle class, DI extension, Twig extensions, config/packages/*.yaml, and often AssetMapper/importmap for any shipped Stimulus controllers. Laravel has none of that scaffolding. Laravel does consume individual Symfony components, but UX packages assume the full-stack kernel, so "composer require" into a Laravel app will either fail on constraint resolution or land code we cannot wire up cleanly.

That said, the capability is a good architectural fit for our situation. Hotwire Native wraps an existing server-rendered app in iOS/Android shells and drives navigation with Turbo. For a PHP monolith that already renders HTML server-side, that is the cheapest credible path to native presence without a second codebase. The package's likely surface area — user-agent detection for the native webview, a /path-configuration.json endpoint describing which URLs stay in-app vs. open in the system browser, and helpers for Turbo bridge components (native buttons, form submission, native chrome) — is exactly the glue we would otherwise hand-roll.

Integration feasibility. Assessed as a dependency: low. Assessed as a pattern to port: high. The realistic code volume here is small — plausibly a few hundred lines across a request detector, a path-configuration builder, and a Twig/Blade helper for data-turbo-* and bridge-- attributes. A spike to read src/ and confirm that estimate is 1–2 days and should gate everything else. The MIT license removes legal friction for a port, and attribution is cheap.

Technical risk. Ranked:

• Adoption risk (high). 12 stars, score ~19.8, effectively single-maintainer. There is no community to absorb our questions or upstream our fixes. Treat it as reference source, not a dependency.
• Data integrity (medium). The stated last release of 2026-10-13 is a future date. That is either a bad feed or a projected date; verify on Packagist and in the repo's tags before anyone puts this in a plan. If the release history is thin or the repo is archived/experimental, the port decision is made for us.
• Protocol coupling (medium). We would inherit Hotwire Native's bridge protocol as a compatibility surface. That protocol is young and has changed across iOS/Android SDK releases. Whoever owns the port owns that tracking.
• Prerequisite risk (high, and under-weighted). The real cost is not this package — it is making the web app Turbo-correct: no full-page reload expectations, correct data-turbo attributes, fragment/history handling, auth and session behavior inside a webview. That work is framework-agnostic and dwarfs the glue code.
• Mobile delivery risk (high). Nothing here gives us iOS/Android builds, signing, TestFlight/Play console, or store review. That is a new discipline for a PHP team.

Key questions. Is this an official part of the Symfony UX monorepo or a standalone experiment, and what is its support tier? Does it cover both iOS and Android path configuration, or only iOS? Does it ship bridge-component helpers or only request detection? What are its PHP/Symfony/Turbo version constraints, and does it require AssetMapper? Is there a maintained equivalent in the Laravel ecosystem (Turbo Laravel and its Hotwire Native support) we should evaluate first? And critically: who on our side owns the mobile shells?

Integration Approach

Stack fit. Do not install this package. Use it as the reference implementation for a thin internal Laravel package (or, if we have any Symfony footprint, a standalone bundle). The four pieces to reproduce: middleware that detects the Hotwire Native user agent and sets a request attribute; a PathConfigurationController returning the JSON rules; a Blade directive/helper emitting native bridge attributes; and a versioned schema for that JSON.

Migration path. Additive, which is the main appeal. The existing web app keeps serving the same routes; the native shells are new clients. No data migration. The only "migration" is behavioral: Turbo-enabling the front end so in-app navigation does not fall back to full reloads. Scope that as its own workstream with its own acceptance criteria.

Compatibility. Pin the path-configuration schema to the Hotwire Native SDK versions we ship, and version the endpoint (/path-configuration/v1.json) from day one. Keep the Laravel port on the same PHP floor as the rest of the estate and avoid Symfony-only types (Request from HttpFoundation is fine; bundle config is not). Verify the bridge attribute names against the actual iOS and Android SDK docs rather than against this repo's tests.

Sequencing. (1) Two-day spike: read the source, confirm feature surface, verify upstream health and release history. (2) Evaluate Turbo Laravel as the likely better foundation. (3) Build user-agent detection + path configuration endpoint — this alone enables a shell. (4) Stand up one iOS shell against staging, internal-only. (5) Add bridge components feature by feature, starting with the highest-value native affordance (native submit button, then native nav). (6) Only then consider Android. Gate each step on the previous one working in a real device build.

Operational Impact

Maintenance. Low volume, real ownership cost. A few hundred lines of glue is easy to maintain; the obligation to track Hotwire Native's bridge protocol and SDK releases is the durable cost. Budget a recurring fraction of an engineer, not a one-off. If we adopt this repo directly instead of porting, the obligation becomes "we are now the maintainers of a 12-star package we did not write."

Support. No vendor SLA, no commercial backing, no meaningful community. Symfony UX channels exist but will not know this package. For a port, support is entirely internal — which is fine if we own it deliberately and document the protocol assumptions.

Scaling. Negligible runtime impact. Detection is a string comparison; the path configuration is static JSON suitable for HTTP caching or a CDN. Scaling pressure lives in the native client release cycle and app-store review latency, not in this code.

Failure modes. Watch for: user-agent misdetection serving a native layout into a browser or a web layout into a shell (blank screens, duplicated navigation); path-configuration drift between the server JSON and expectations baked into shipped app binaries, producing broken in-app navigation or unexpected external-browser handoffs; bridge component version mismatch failing silently rather than loudly; auth/session/cookie behavior inside the webview differing from the browser; and route changes in the web app that require a store release to fix. Instrument the native user agent path explicitly so misdetection is visible in logs rather than reported by users.

Ramp-up. For the PHP side, days — the glue is simple and the port is small. The genuinely new skills are mobile release engineering (signing, provisioning, TestFlight/Play console, review cycles) and Turbo front-end discipline. That is weeks, not days, and it is the honest cost of the mobile path. Recommend a spike plus a one-shell pilot before committing to the pattern, and do not let the package's low adoption alone be the deciding factor — the surface area is small enough to own — but do let the mobile delivery burden be.