IMHO, you want to do it from scratch if you want it to really work with Erlang, but that means a ton of work. ex11 exists, but I don't know that it was ever very complete, and it was built in the old era of X11 where clients didn't render fonts, etc, so there'd be a lot of work to complete it. The most active fork has moved towards using it for embedded systems.

Personally, I used ex11 because the wxWidgets interfaces are hard for me to grasp and then accept; it was easier for me to understand X11 as a distributed communication protocol that has a side effect of occasionally outputting graphics; but my application only outputs a bitmap once in a while, so really I could have made anything work. ex11 doesn't help you with mobile though, because Android and iOS don't run X11.

There's also gtkNode, but I don't know how well that works, because it didn't seem any less confusing than wxWidgets. gtk has some ability to run on mobile, I think.

Erlang comes with a binding to wxWidgets that is used to implement the graphical debugger and observer it comes with, but they are fairly utilitarian in their styling and I don’t know of any other Erlang/Elixir GUI apps. Which is to say: it probably could be done, but doesn’t seem to be popular even among Erlang programmers.

I'm in elixir land - but have a look at https://github.com/elixir-desktop - they even have an ios app in the app store..

basically wxwidgets comes with a webview, and that one is loaded up - and everything is packaged as an app - so you can use phoenix (liveview), or even react or anything to your liking..

believe certain improvements were made to OTP 25, so multiple things will land soon - even livebook https://github.com/livebook-dev/livebook are aiming at shipping a native app..

Not really, because UI components inherently need tight integration for event propagation, layouting, drawing... Sure, you could render individual components in their own processes and have one process accumulate a render tree , but I don't see much sense in that.

The lack of GC also is a problem, so you might have to do each redraw in a fresh process or something like that to avoid accumulating too much memory.

Processes would be good for all sideline functionality like API/db requests and expensive computations.