Sorry @Damirados and @mat-hek I accidentally flipped the replies and the site won’t let me edit it.
GenericJam
Damirados
Emerge is similar to scenic but with layout engine, animations and proper zero copy video pipeline.
0
bartblast
Creator of Hologram
I’d push back on this - the “native feel” obsession is largely a dev and designer thing. Users care about performance, reliability, and smooth interactions, not whether a button matches platform HIG. Nobody complains that web apps don’t use OS-native form inputs - users adapted years ago. Mobile is no different. Some of the most popular apps ship custom non-native UIs and nobody complains.
This misconception has a real cost: too many devs dismiss the WebView path outright. WebView’s bad reputation mostly comes from early hybrid frameworks that shipped unoptimized web apps in a shell - that was an implementation problem, not a WebView limitation. There’s a ton of optimization headroom there and nothing fundamental preventing it from being nearly indistinguishable from native - WebView engines improve with every OS release, Web APIs keep closing the gap, and platform conventions are converging. We’re planning to take this approach with Hologram after Local-First lands - same repo, same UI components across web and mobile.
5
f0rest8
Just to chime in, maybe I’m off topic, but when I see DX for Elixir on Native Mobile… what I really want is to be able to write and make my web app in elixir (phoenix live view for me personally) and then be able to simply run a mix task (or similar simplicity) and have the native app setup/updated to represent the same experience I just created in web.
That would be my dream. Work in the language and framework I prefer and know that my one app is more or less the same experience replicated across any device and immediately submittable to the various app stores. We’re dreaming right? 
2
bartblast
Creator of Hologram
That’s exactly the plan for Hologram - web, mobile, and desktop from the same repo with the same UI components. Not dreaming, just not there yet
3
derek-zhou
I think there is a niche for both. In fact, if you consider the 2 aspects of native: native look and native rendering speed, there are 2X2=4 combinations, all 4 are valid:
- Neither, I think that’s where Hologram is aiming. Maximizing portability.
- Both, I think that’s the way @GenericJam is aiming. Awesome look and feel, but cross platform portability will suffer
- Native rendering speed but not so much native look and feel. I think this is where @Damirados is going.
- Native look and feel but still going through webview. I think this is where @Grouvie is going.
I am glad that all quadrants are being explored within this community.
3
Damirados
IMO if you make UI toolkit well enough, matching native look and feel is just a theme and some configuration options for stuff like scrolling behavior and gesture physics.
I am going for high performance on low powered devices on one end (think smooth 30/60fps on a hardware equivalent of 10 year old smartphone, cheap one, not flagship) and a high complexity desktop apps on the other end (video editors, music DAWs, CAD software…). Mobile apps should basically come for free as a side effect, once interface to the OS is developed (which is ton of work and not free at all)
Number 1 thing I am going for is the development experience.
1
GenericJam
I don’t really know who has the obsession but there are whole libraries in React Native to mimic native buttons, etc. I think it is without argument that when you have an app that looks like system apps it feels like it belongs there. I spent a couple of years in React Native so I know a lot of the pain points in the ecosystem.
A webview is not designed to be a first class experience on any of the platforms but their native apps are.
I’m not sure what the plan to get Hologram onto mobile is but there aren’t really any great options in my opinion. You could do PWA which has its own problems. You could do Cordova which has other problems. You could do NativeScript. I may be missing one or two. All of them have issues as far as I’m concerned.
Before going down this particular rabbithole I built a PWA in LiveView and I built a PoC NativeScript app with LiveView and they do ‘work’.
It’s not just that I want Elixir, I also want the BEAM in the app. I think this is where LiveView Native got it wrong. The processing needs to happen on the device and people want BEAM style interaction. At least I do and I definitely missed it when going back to programming on mobile without it. The BEAM is such a powerful runtime for precisely the problem set of mobile which is the mucky middle.
The other thing that LiveView Native got wrong is assuming that LiveView would work as well on mobile as it does on desktop. Apps have to be super snappy. Even more so than desktop apps. I’m very appreciative of the work that was done there with pioneering design but I could tell pretty early that this was not going to get wide adoption because mobile is a very different space than desktop. Another issue with LiveView Native is too many moving pieces. In my framework the app is directly wired to the BEAM. Zero latency and very little in terms of dependencies that have to be maintained.
By targeting the native view tree we get all of the native performance for the cost of building the mapping. So all of the performance advances including whatever they just released in the latest update we get thrown in. There’s also a ton of things you can’t do with a webview whereas anything the phone can do is available if you just build a native app.
Every blessing on the hologram project. I’m cheering for you but mobile is a difficult space and the reason I took this direction is by feeling the pain points.
@f0rest8 I don’t think there is any example where this is the case. Today you can already create a PWA with LiveView if you really want to but it’s a canned webpage posing as an app. Even React Native shares a handful of things with React but the crossover is surprisingly small as they are not actually mapping the same problem space. All the RN elements are different, RN has navigation, etc. They share a virtual DOM and probably a common design language but there are many differences.
NativeScript comes close but that’s another example of trying to shoehorn one thing into another.
Overall I want native performance, native look, write in Elixir using conventions that feel like LiveView with the BEAM on board to do all the stuff the BEAM can do. I think this is the best of everything for the specific problem space of what most people want for mobile apps.
7
GenericJam
Another design consideration: because of my work in React Native I realized the pain of having to go through too many layers. I want it to be as simple as is reasonably possible.
React Native | React | Javascript | Platform glue | Mobile OS | Phone
Moving anything in any of these layers could mean your app stops working or will stop working at the next update.
iOS and Android don’t want you there as some alternative cross platform thing. They want to give every advantage to native developers. Apple is particularly bad. Arguably, Android just wants everyone on the web but Apple actively tries to force people into the blessed way.
If you write a React Native app of anything of reasonable complication you will end up with a fair bit of platform specific code either in native modules or in platform glue and even in your code logic. Trying to get it working on two platforms is comparable to just writing two separate apps which is what many teams settle on. So now that is possible to do with one language. Of course there must be some overlap so you might as well include them in the same codebase (yay!) but there will still be a need to have platform specific code as there are lots of eccentricities between them.
My plan is to write an abstraction layer that for the most part tracks to a native implementation on each side but if you really want to dial it in you can use the actual native terms and say which platform you want it to end up on.
So, simplicity is a goal but also specificity. Anything that you can do natively you should be able to do here. I realize the groups I’m trying to make happy here may not agree on what constitutes a good decision but I’m hoping that it will work well enough to enable Elixir developers to get onto native mobile and mobile developers to get into Elixir.
4
derek-zhou
Through NIF? The problem here is that there are first party high level language APIs that are much nicer to use, but I am stuck with the C API by choosing Elixir.
0