And. by the way, there is not C++ interop for now if we do not count C API.

I wouldn’t expect Google to simply “replace” Dart in Flutter. The integration between language, tools, and dev experience was non-trivial to create, and internally it would be politically very difficult (I’d imagine).

Flutter’s interop story is terrible, and Kotlin’s is (relatively) fantastic. I say “relatively” because there’s still a lot of work to do WRT Swift, but still. It’s pretty great. Flutter would be far more interesting if you could keep your logic/architecture in the “native” app and use Flutter in parts as a purely UI implementation. Today that means some kind of multiplatform channels library (which I’d call Klutter). I think direct native interop might be feasible, but not so much jvm, which kind of kills what makes the Android side really useful for Kotlin

The channel to Kotlin library would be pretty straightforward I think. Figure late this year. Direct interop would be a while off. 1-2 years, unless somebody really, really wanted it.

However, in the “2-ish year” timeframe we’ll see Swift UI and Compose release, which will chip away at some of the dev experience advantage. Somebody will release some form Kotlin-based shared UI library. Several are in progress. We also tend to ignore the rapid advances in web tech (wasm, web components).

It’ll be an interesting few years, and I don’t see Flutter ❤️ Kotlin as a clear winning formula. Not a losing one, either. Predicting the future is hard. I do think Flutter and Kotlin are doing different things and not competing. I’m also fond of saying “shared ui has a history of pain, shared logic is the history of computers”.

“too much code sharing and swift developers wont apply”. It’s not that absolute, right? Some may not apply, but any tech stack choice will impact who applies. If you’re sharing everything but the UI, first, congrats. Second, your need for Swift architectural expertise is reduced. You’ll need more UI focused engineers, and learning how to code enough Swift to render a UI is way different than understanding protocol oriented programming, RX streams, etc.

“How to deal with the team lead responsibilities when the Android team grows and the ios stays small.” It’s not an “Android” team. It’s a mobile team. Part of management is setting culture. Also, it’s a good idea to encourage iOS devs learning Kotlin. We built the Xcode Kotlin plugin to help here. Forcing iOS devs to also install a different tool is a tougher sell, but being able to browse/debug in Xcode will get people started. As for learning Kotlin, most Android devs just went through the same process, and coming from Swift it’ll be reasonably straightforward.

Summary, change has issues, but I do think Kotlin is a simpler pitch. You can start with small parts of the arch, gradual introduction. It’s a lot less jarring than doing a big rewrite, and other frameworks are more difficult to partially include