Carson Katri from DockYard posted today about swift-erlang-actor-system, which enables Swift programs to join Erlang clusters as distributed nodes.
In the Hacker News discussion, Brian Cardarella revealed this is part of a much larger project called “Crane” - a native UI browser that renders actual native components instead of HTML. So <Text>Hello</Text> becomes SwiftUI’s Text("Hello"), with each DOM node running as an Erlang process.
This Crane approach is very interesting - using distributed Erlang to bridge native UI with web-like development patterns, and representing DOM nodes as Erlang processes. If it pans out, the ability to run JavaScript via WASM in Elixir and target all Apple platforms (except Watch) could be game-changing for how we think about native development.
However, Brian mentioned this “originally started as the LiveView Native project but due to some difficulties collaborating with the upstream project we’ve decided to broaden our scope.”
I’m working on a commercial SaaS built entirely with Phoenix LiveView, and we’ve been considering using LiveView Native for our mobile apps. The big draw is keeping everything in Elixir without building a separate API layer.
I’m inferring the “upstream project” mentioned is Phoenix itself? Not looking for anyone to reveal private communications, but I’m trying to understand the implications for technology decisions I need to make in the near term.
I’m wondering if it would it make sense to start a new LiveView Native project given this development. Is Crane an evolution/replacement of LVN or something separate?
For those of us with production LiveView apps considering mobile options, what’s the recommended path forward? Would appreciate any insights from folks familiar with these projects or who’ve recently evaluated LiveView Native.
BTW to be clear: we hadn’t decided on LV Native but were planning to seriously evaluate it vs. alternatives (full native, other frameworks).
