Disclosure: I’m not a frontend dev, and have no mobile app development experience.
Presently a LiveView Native app can be written in SwiftUI (Apple) or Jetpack Compose (Android). This means that an app has be to re-implemented for each platform.
Toolkits like Flutter or Compose Multiplatform enable you to target Android and iOS, and even Desktops and the Web with a single implementation.
It seems to me that a Flutter client or a Compose Multiplatform client would be especially valuable to the community. Is there any reason why this wasn’t pursued? A Compose Multiplatform seems simple to build since it is based on Jetpack Compose, which already has a working client.
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 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…
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.)
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.
