In recent times, the debate surrounding Kotlin Multiplatform (KMM) and Flutter has intensified, with some suggesting that KMM might supersede Flutter as the go-to solution for cross-platform mobile development. But is this truly the case?
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.
This old myth is as old as the RN vs Flutter debate itself and I'm willing to help bust it again.
The simple answer is that when people have a problem or question about Flutter they simply key in Flutter. With RN they can ask about React, JavaScript, typescript, RN itself or one of the many components you use to make an app as it's the sum of a lot more parts.
So if Flutter didn't get more searches here I would be surprised and concerned.
The longer answer I'll just tease but suffice to say it's more complex than above.
It can come down to lots of things including the competency/experience of developers and maturity. As an experienced developer I might need to search for or ask about what I'm doing maybe 2 times a week. For someone getting started that might be that many times an hour. If you just looked at the two of us as a blob it might seem that whatever the other is using is more popular despite it being 50/50.
So yeah, number of searches or stack overflow questions or Reddit posts or whatever it is does not equal popularity.
Reworded, your claim is that RN developers are getting smarter over time, need to search less, and that new developers don't have questions, they just figure it out .. and some mix of reasons like this are why the RN searches are going down.
I imagine I am having a harder time swallowing this logic than you are looking at raw numbers.
No. Read the simple form of my response, the first part.
What you said was an example of one factor as to why it's more complex than the simple form for people who really want to dig down deep but on its own it's not an answer
Hardly. Performance lags. Even after the new rendering engine. Try compiling and then running desk top samples (a mail client, a finance management tool) on macOs and check the amount of jank in animations.
Text fields are whole another story. They feel alien in UX on every platform.
I can live with that but performance is a deal breaker.
Eh, I was recently contracted onto a native macOS team (Swift), the company had an adjacent desktop team who opted to use Flutter, they had a lot of problems and ended up dropping the project. I don't know the details but there was a lot of weird edge cases they ran into on desktop. They had a mobile app partially in Flutter (different team again) which seemed to be OK, however.
The problem with Flutter is that it's a UI framework that relies on a single main thread. If you put something heavy there, you'll get lag. In contrast, other languages like SwiftUI let you easily spawn threads. Flutter dismisses this as outdated and instead promotes an isolated model with completely separate memory... for reasons.
> 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.
I mean, Kotlin on the backend is quite good in my experience, I would say you can definitely run a full stack off of it.
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.
For the name of the internal framework, I can't remember which podcast I heard it on, but they haven't mentioned it publicly much if at all. It's something they threw together in like 2012.
Still, in a couple of years when Compose Multiplatform is mature, and Google is looking to boost profit margin, they may rationalise their investment in multiple Cross Platform toolkits. I think most agree that, from a technical viewpoint, KMP + Compose Multiplatform offers the most flexibility.
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.
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..
KMM has two ways to do UI. You can do it natively and use Kotlin only for shared business logic (it inter-ops with Swift/Objective C). Or, you can take the new Android UI toolkit (Jetpack Compose) and it use it on desktop/iOS/web as well, for your whole app.
Dart also has native interop with Swift, Objective C, Rust, C, Java, Kotlin and JavaScript.
It also has more compile targets as far as I am aware too. On top of the standard web, iOS, macOS, windows and Linux across all the standard chipsets plus emerging ones like RISC-V plus it also has support for WASM.
I don’t know of anyone with that level of cross platform and cross language interop out there currently which is also something you would want to write significant business logic or UI in.
Still, for cross-platform mobile and desktop apps, the Dart website recommends Flutter with no qualifications, and Flutter only covers the approach of a single cross-platform UI, as opposed to native UI with a cross-platform backend. The fact that Kotlin officially supports the second option makes it more appealing to me.
There is also a webview based approach, like https://v2.tauri.app/ which comes with all the upsides of creating a lightweight HTML+CSS+JS UI but instead of shipping copies of chromium, it runs using the system's webview browser engine.
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.
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.
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 :/
Jetbrains is one of the best example of a bootstrapped company. They have a fantastic track record of 20+ years shipping and evolving some of the best IDEs out there
Same and with lots of Kotlin code in the wild on Android, I'm not too afraid to language will fade away. Bu in terms of active development like KMM; I don't like JetBrains being pretty much a single point of failure.
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.
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.
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.
They need to make C++Builder on par with Delphi. Nobody is going to start a new project in Pascal. This and their current licensing make me think that they are more interested in milking existing enterprise costumers rather than acquiring new users.
C++ Builder has been on par with Delphi for years.
If anything, I find quite tragic that Microsoft has never managed to make Visual C++ half as good as C++ Builder.
The only time that they came closer to it, with C++/CX, some internal devs managed to successfuly riot and replace it with C++/WinRT junk, only to now have fun in Rust/WinRT, and the remaining MS teams rather use C#, React Native, or Webviews, instead of dealing with XAML C++/WinRT mess.
I mean on par in cross-platform development. The latest C++Builder only supports Windows. Although, they have switched to Clang recently, so hopefully things will improve, on the tech side at least.
Please consider that many of us have been burned before. I've been in business for over 25 years now and I am still supporting several apps built with now forsaken technologies. That includes a web app built with Dart back when Google claimed that its Dart VM would be bundled into every browser.
Now, I like Flutter and I like Kotlin. Jetpack Compose is really nice. But if I am starting an app today and in a year or two, Google decides that developing two competing frameworks is too expensive, they'll discontinue one. If it is the one that I chose, I'll be sooooo bitter.
So yes, right now, they're pushing both and they claim not to have a preference but we need some reassurance that it'll stay that way.
> 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.
Interesting take - the way you cite this as an example makes it sound like they rewrote it from Flutter to Kotlin Multiplatform, but the actual article doesn't seem to support that claim. It actually says:
> Cross-Platform Evolution: Google Docs now uses KMP for shared business logic. Android, iOS, and Web are now more unified than ever.
Which suggests to me that the code base for Google Docs had very little shared code between the different flavours, probably native code for each platform, and they've since done a refactoring job so that the Android code (that obviously would have used Kotlin) for the business logic is now interfacing with the existing native code for UI for each platform, and they used the KMP libs to do that.
This seems like an entirely reasonable and sensible decision to make - they still have the pain points in multiple UI code bases, but the common stuff isn't now replicated in 3 different languages with 3 different sets of bugs. That's all good.
However, I don't see any reason why you'd see that as a loss/negative for Flutter. Obviously they already had an existing code base that used Kotlin for the Android native implementation, so there were many advantages to promoting that to the authorative version shared across the others. Rewriting the whole project in a completely different language (i.e. shifting to Flutter and using Dart) would have been a significantly bigger undertaking, and likely would have introduced many more bugs by starting again from a new implementation rather than just refactoring an existing code base that had already been extensively tested.
If you already have a project using Flutter, it'd be just as foolish to attempt to rewrite it in Kotlin Multiplatform as it would the other way around.
The real question is what the best choice is for starting a new application? Having used Flutter quite a bit now and then looking at Kotlin Multiplatform, I can see that Flutter is great for smaller teams that want fewer developers and the ability to share as much UI code as possible, wherease Kotlin Multiplatform seems more suited for bigger teams who can have dedicated resources for each platform, because they've made the choice that they want to leverage platform-specifc features for each of their targets.
For me personally, I dislike doing UI code, so I'm going to choose Flutter every time because I don't want to do that work multiple times. At the same time, I've found that doing UI work in Flutter on this project has felt more rewarding than every time I've had to do UI work before, because it's relatively easy to get some amazing results but you can also modify anything you don't like, as well as being able to read the source for the standard widgets if you want to base your widget on something similar.
Ads is the reason Dart is still around, back when Dart VM was discontinued, they had just recently migrated from GWT into Angular Dart, and they weren't going to rewrite it yet again.
Had it not been the case, Flutter team would never had reached for Dart.
You say that and yet they continue to use it and are choosing to do so even when it means rewriting huge and complicated bits of software from scratch.
What something from over a decade has to do with its value today I’m not sure.
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.
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.