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.
The trend for Flutter is a straight line going up and React Native is going down in popularity.
The trend was obvious many years ago, and just recently Flutter is now surpassing RN in nearly every poll.
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.
I imagine I am having a harder time swallowing this logic than you are looking at raw numbers.
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
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.
MacOS support is so good that I've developed a MacOS app just for convenience so I don't need to open the iOS simulator.
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.
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...
No, Google did this throughout every team, not only the Flutter team.
Can you point me to the source? I'm curious
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.
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.
From: https://blog.jetbrains.com/kotlin/2023/07/update-on-the-name...
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..
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.
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.
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.
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.
It also seems relatively difficult to find developers compared to React Native, which otherwise seems to share those maintenance requirements.
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.
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.
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.
https://www.embarcadero.com/products/rad-studio/fm-applicati...
> The fastest way to build connected C++ apps for Windows, OS X, iOS, Android, gadgets, and wearables
It used to support 32-bit Android earlier, but not 64-bit, neither 64-bit macOS.
https://docwiki.embarcadero.com/RADStudio/Athens/en/What%27s...
Admittedly the reasoning provided is quite lame given that up to 11.3, the support is available.
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.
Ads is where the overwhelming majority of their money comes from. It’s all Dart (and Flutter specifically on non web platforms).
They also just got done rewriting all of Google’s Earths UI in Flutter.
It might be my ignorance but what multi platform stuff do they have in production with Kotlin?
They sold it, but didn’t use it. They had their own custom, in-house tool.
I’m a believer in eating your own dog food.
On-topic, I write native (iOS, in Swift), so have no opinion, as I don’t use either tool.
[0] https://en.m.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
> 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.
> 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.
Had it not been the case, Flutter team would never had reached for Dart.
What something from over a decade has to do with its value today I’m not sure.
That alone would be enough, Google has plenty of internally used languages.
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.