// the find
liveview-native/live_view_native
A framework for building native applications with Phoenix LiveView
LiveView Native lets a single Phoenix LiveView module render to SwiftUI, Jetpack Compose, or HTML clients by swapping the template engine per platform, so one Elixir server process drives web, iOS, and Android UIs. It's for Elixir/Phoenix teams who want native mobile screens without standing up a separate frontend stack or mobile backend.
Reuses the real LiveView process and socket diffing model for native clients instead of inventing a parallel state-sync mechanism — anyone who knows LiveView already knows the mental model here. Per-target render/2 clauses (matching on things like target: 'watchos') let you branch UI by device inside the same module, which is a clean way to handle form-factor differences without duplicating business logic. There's real integration test coverage exercising the template/render pipeline against actual client stand-ins (test/support/clients/gameboy, switch), not just isolated unit tests. It ships mix task generators (lvn.setup, lvn.gen.live) that patch an existing Phoenix app's router and config directly via a codegen/patch module, which lowers the cost of retrofitting onto a repo you already have.
Still 0.4.0-rc.1, and a working setup requires version-matching four separate hex packages (live_view_native, live_view_native_stylesheet, live_view_native_swiftui, live_view_native_live_form) plus sibling client repos — that's a lot of moving parts to keep in sync pre-1.0. The README says nothing about reconnection or offline behavior for native clients, which matters a lot more on a cellular connection than in a browser tab, and it's a glaring gap for anything mobile. The actual SwiftUI/Compose rendering logic lives entirely in separate repos (liveview-client-swiftui, liveview-client-jetpack), so this repo alone can't tell you how mature or complete the native rendering actually is. There's also no mention of how you get from a LiveView template to a shippable App Store or Play Store binary — that packaging step is presumably nontrivial and isn't documented here at all.