Since when was Flutter the "go-to solution for cross-platform development"?

Maybe for hobbyists but in the corporate space it's still React Native.

The problem with Flutter, and this extends even further with KMP is that the scope of your skills is limited to making mobile apps whereas with React Native you are learning and using skills that can apply to a complete stack.

KMP is even worse in this regard as they expect you to build two frontends (yes I'm aware of compose multi platform but it's a separate product entirely) so unless you have some crazy business logic that Dart or JavaScript can't handle you're sacrificing the largest benefit in cross platform app development for the smallest.

As for whether Google are replacing Flutter I think they made a massive PR goof with the launch and have introduced a lot of uncertainty. Possibly it's their long term plan but currently it's just a tiny niche product.

One datapoint is that Google rewrote their Google Docs app in KMM (which doesn't include UI, that's Compose Multiplatform), replacing their legacy in-house framework. They intend to write more of their apps in it.

They also recently offshored some Flutter roles which may be a sign of how central they view Flutter. In a few years it may be in the graveyard.

https://touchlab.co/KMP-at-google

https://www.reddit.com/r/FlutterDev/comments/1chwqtu/flutter...

My team publishes a cross-platform library/SDK with support for Flutter, React Native, Web and KMP.

Right now, we're seeing a lot of interest in Flutter for new cross-platform apps. I personally find it a really pleasant development experience.

We're also seeing a lot of interest in React Native. In our case possibly less than Flutter only because there is more competing libraries available for React Native.

We're also seeing interest in KMP, but much less than Flutter or React Native - I'd guess it's probably 5% or less of our users. It may have a good future, but it's not there yet in terms of current usage.

To resolve the long-standing issues of naming inconsistency and abbreviation confusion that have puzzled many Kotlin developers over the past two years, we are deprecating the “Kotlin Multiplatform Mobile” (KMM) product name. From now on, “Kotlin Multiplatform” (KMP) is the preferred term when referring to the Kotlin technology for sharing code across different platforms, regardless of the combination of targets being discussed.

From: https://blog.jetbrains.com/kotlin/2023/07/update-on-the-name...

Not sure... for some types of apps they might "compete" but for many not, I think: I view (after some toying with Flutter) the GPU UI renderers ala Flutter, QT/QML, gioUI, slint.dev etc as modern Flash-like options in a "can do anything graphically you could do with HTML+CSS+JS, which isn't the prime choice for some devs or some apps or those that don't want to have to end up with Ionic/Electron" manner — whereas KMM likely (my vague assumption) abstracts the common native GUI components shared among all platforms, plus allow platform-specific special ones too, I suppose? Or is KMM also going for custom GPU rendition?

Flutter & co. might just much more emphasize their graphical / fully-brandable nature rather than focus on their always-catching-up-and-slightly-off apings-of-native-UX.

If my KMM assumptions are somewhat correct, then it'll probably eat some of Flutter&co's lunch but not that much of it..

Flutter has the challenge that it requires a dedicated language (Dart) and ecosystem to execute "on top" of each native platform it aims to support. Flutter skills can only be used to build Flutter things.

Kotlin Multiplatform (KMP) on the other hand, as the name suggests, allows one's knowledge in Kotlin/Android/JVM (a vastly bigger and more established ecosystem) to be used for building cross-platform apps.

KMP's focus is on reusing "logic" while implementing each platform's UI using the platform specific framework (SwiftUI and Jetpack Compose for mobile). I see this as a big advantage as well, as it allows apps to keep up with each platform and feel "at home", instead of landing with an "averaged" experience.

So yes, KMP is a more sustainable path forward.

It depends on which platforms interest you, but the general lack of multiplatform Kotlin libraries makes me doubt this will happen any time soon. I tried and gave up on Compose Multiplatform after realizing this for my most recent project, last year. (I went web instead.)

We've tried doing both. It's unlikely we'll use KMP/KMM.

1) We weren't happy with the layers in between - there's the cross platform and the 3rd party libs. 2) The exported size was about 30 MB bigger than it could be, mostly related to the previous point.

The main advantage it has over Flutter is that you don't have to learn Dart and Google won't kill it. But Dart is a nice language and it plays better into reactive programming than Kotlin.

Who may have thought in 2004 that 20 years later you may have to use a specific language and a specific ui library to run gui on different platforms without 500mb runtime and it still stuttered.

Why are we like this? It’s literally 66% more APIs that you need to support since then, everything else is already done. Take GDK/Cairo or Qt abstraction layers, integrate it with platform-specific smooth scrolling api and paint whatever widgets you want efficiently. Even proxying it to html-css would do the trick, although for a price.

I wouldn't know, but the experience I've had with Flutter as a dependency is that when a company has been struggling for a year, eighteen months, and topples and ends up on my table I usually need to tell prospective buyers that the mobile application is going to need maintenance before they can get the 'stores' to accept it and they can relaunch the system.

It also seems relatively difficult to find developers compared to React Native, which otherwise seems to share those maintenance requirements.

I'm not a frontend engineer or really a fully experienced backend engineer. I have done systems stuff, lots of OPS, scaling and other things adjacent.

Flutter is interesting to me because I can use a tool like flutterflow to build an app and throw together the backend reasonably comfortably (with some possible future footguns included).

Not knowing Kotlin means this is less attractive to me, but I can see the benefit if I knew one language that could span frontend and backend very nicely.

Flutter is pretty good for UIs. As for the code sharing aspect I would pick Rust.

Maybe I'm getting cynical but in terms of longevity, I don't know how long JetBrains will be around and I'm not trusting Google to maintain a project for a long time. Can't believe I'm saying this but for perennial projects in that sphere, Java seems like the better option :/

Flutter was never welcomed by Android team, so this wouldn't surprise me.

The go-to solution for cross-platform mobile development are mobile Web apps, unless we are speaking about games, or very special snowflake apps that really need device APIs.

Forms over data can be easily done as mobile Web.

The only cross-platform tooling I've really been interested in is Rust + uniFFI but it doesn't seem to be that widely used yet, I've only built some toy libraries in it so can't actually say how well it works.

No, it isn’t. Flutter is doing great.

If you want cross platform with a nice set of mature libraries and components, have a look at Delphi. It now (optionally) uses Skia as its rendering engine, the same as Flutter.

I really see zero compelling evidence of this whatsoever. It seems like some random bullshit Twitter drama without any substance behind it.

I sure hope so. I love compose multiplatform - it’s by far my favorite dev experience.

For desktop targets you still have to bundle the whole JVM as I understand.

Use Ionic and go on with your life and mental health.

Well I don't want to throw poop at Flutter but I hope so. There's no need for yet another language for doing cross-platform mobile apps and having single overlord (Google) financing the language (Dart) as well as the toolkit (Flutter) doesn't seem sustainable in the long run (cough Stadia etc).

Kotlin has Java interoperability as well as wider community support which to me seems a lot more organic than Flutter's. And, personally, I dislike Flutter's obtuse OOP patterns. From what little I used Kotlin it seemed like more modern Java that didn't make your fingers sore with its boilerplate. Although Gradle is still the worst package manager I have ever used.