Cross Platfrom LiveView Native Apps with Flutter or Compose Multiplatfrom

I can’t speak for the LVN team for the exact reasoning, but one of their goals is to allow people to build with native UI components. At least flutter leaves a lot on the table compared to native components.

To compare flutter to native components from a more web angle: Instead of using a native <input /> dom component flutter would be rendering an input using <canvas /> to render raw pixels of an input and reimplementing anything needed to be able to render that + all the interactions with users – that works until it doesn’t.

I cannot speak to compose multiplatform though.

Achieving LiveView style patching for Flutter would be very interesting. No idea how feasible.

Digit’s talk from CodeBEAM on Nerves Flutter support is not out yet:

It would be quite interesting to see if LVN could be useful for Flutter. Using it at SmartRent we write Dart for the UI, not Elixir.

I found a flutter library maintained by Flutter Core for rendering remotely: rfw. No idea if it’s compatible with LiveView Native Core though.

Looking through rfw, I suspect that a Flutter Client will end up embedding Dart code which will somehow be compiled and run at runtime. Maybe a widget DSL can solve the ergonomic problem of writing Dart?

For regular Flutter apps, you should check out Clojure Dart. As a functional programmer, it seems a lot more pleasant that writing dart itself.

There seems to have a lot of great talks at CodeBEAM SF this year - I really feel as though I missed out. I spoke there last year. Maybe I should have delayed that presentation for this year…

I see. Have you encountered a similar problem yourself? I have generally heard that Flutter is quite stable, though I have never used it myself.

This is not an issue of “stability”. The thing to recognise is that flutter emulates native UI, it doesn’t use the native UI libraries – and emulation will always have places to lack behind their native counterparts. One well known thing where flutter lacks behind native iOS for example is text rendering quality.

Personally I’d only use flutter for implementing custom UI, but never using their compatibility layers for native UI.

I wasn’t aware of this. I had known that at some layer of the stack they were their own separate UI, but I never thought that they would emulate something as fundamental rendering text. I’d expect that abstracting API differences between the native UIs would be simpler that rolling your own.

About compose multiplatform, it’s more or less identical to jetpack compose, the native UI on Android, so I’m guessing it suffers from the same emulation problems. Interestingly, compose multiplatform is built on Kotlin Multiplatform so it makes at least sharing business logic fairly accessibly, even if you keep the UI native.

How would you achieve that? Won’t need to render text at some point in your UI? Do you wrap a native widget with a flutter one?

Are their compatibility layers truly so bad that you would rather maintain 2 native implementations of you app instead? I’d expect that it would be better than ReactNative which seems to be what the majority of mobile devs use today (Again not a frontend guy. For all I know this could be an apples to oranges comparision.)

There is this project: GitHub - alex-min/live_view_native_flutter_client: A flutter client for LiveView Native · GitHub

I think I’ve heard the LVN team saying they want to enable using the official native components of the respective platforms, so they plan to do SwiftUI, Android (Jetpack) and Windows.

This project is quite fascinating! Though I have some serious concerns if this client will be maintained since it seems to be a one man project.