I really see zero compelling evidence of this whatsoever. It seems like some random bullshit Twitter drama without any substance behind it.
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.