Basically there are two paths toward a Flutter frontend.
"Flutter native" approach
Wrapping the SwiftUI and Jetpack Compose components from iOS and Android
I'll lay out the pros and cons of each approach here.
Flutter native
We can leverage Flutter MapLibre GL to get MapLibre on all platforms with Flutter bindings that are idiomatic and (ostensibly) easy to optimize for efficiency. There would only be one additional layer of binding between the C++ core and Flutter's state management (which determines redraw timing, much like other modern composable reactive frameworks). In fact, it would even let us support flutter web and (once MapLibre adds macOS support back) desktop through a single library. That'd be pretty cool ;)
The only downside here is that we have to maintain another platform and its UI components.
Wrapping SwiftUI and Compose
We already did a lot of the work for iOS and Android; maybe we can reuse it? It seems like Flutter supports SwiftUI views and Compose.
I do not know how much work this is, or how efficient it is. This is a question we'll need to answer before deciding on a path forward. Specifically:
Is it an inordinate amount of work to set up the SwiftUI / Compose bindings?
Can Flutter users do their own compositions? It would not be a win IMO unless we can provide a composable Flutter widget that wraps the native views (ex: a Flutter Banner widget which wraps the SwiftUI and Compose views on the respective platforms); composability is a huge selling point of Ferrostar's UI layer.
Is it significantly less efficient (CPU and RAM profile) / slower than Flutter MapLibre in a simple test (simulating driving a route ideally)?
Basically there are two paths toward a Flutter frontend.
I'll lay out the pros and cons of each approach here.
Flutter native
We can leverage Flutter MapLibre GL to get MapLibre on all platforms with Flutter bindings that are idiomatic and (ostensibly) easy to optimize for efficiency. There would only be one additional layer of binding between the C++ core and Flutter's state management (which determines redraw timing, much like other modern composable reactive frameworks). In fact, it would even let us support flutter web and (once MapLibre adds macOS support back) desktop through a single library. That'd be pretty cool ;)
The only downside here is that we have to maintain another platform and its UI components.
Wrapping SwiftUI and Compose
We already did a lot of the work for iOS and Android; maybe we can reuse it? It seems like Flutter supports SwiftUI views and Compose.
I do not know how much work this is, or how efficient it is. This is a question we'll need to answer before deciding on a path forward. Specifically: