Flutter and Kotlin Multiplatform relationship - Ar...

# feed

[marcinmoskala]

Flutter and Kotlin Multiplatform relationship - Are they competitors? New article on Kt. Academy blog
https://blog.kotlin-academy.com/flutter-and-kotlin-multiplatform-relationship-890616005f57

[altavir]

It is my belief as well. We had several discussions about it and it looks like people are really happy with Flutter, but unhappy with Dart. I think it is possible to add addtional Dart-VM backend to kotlin, but it is easier to just add a Kotlin-Native front to Flutter.

[altavir]

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

[Sam]

Flutter’s garbage collection happens off of the main thread. As soon as it would touch a Kotlin Native object exposed to the dart runtime, the program would die. It’s not impossible to work around this limitation but it is more work than it should be.

[altavir]

Not flutters garbage collection, but Darts garbage collection. You should not mix the language with the library. Negotiating live-time between different runtimes is always a problem, but it is solved in many cases, so I do not think it is impossible to do.

[Sam]

Yes, Dart’s GC. I have successfully embedded K/N objects in JavaScript Core which does GC in background threads. It is definitely possible but not nearly as straightforward as putting in a swift or ObjC object.

[altavir]

I will trust you on that. Still, if we are talking about how to marry Flutter to Kotlin, then we are talking not about thin library layer on top of Dart, but about more deep integration, including rewriting top-level API in another language. If Google will decide it worth the effort, it can do it.

[kpgalligan]

Just skimmed the article, but will go back on a deeper read. This topic has been of much discussion in my circles.

[kpgalligan]

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).

[kpgalligan]

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

[kpgalligan]

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.

[kpgalligan]

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).

[kpgalligan]

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”.

[kioba]

Kotlin is not a silver bullet for multiplatform either. Without a good architecture it just code duplication on jvm and native and it will be more a political issue with the ios team.
That said I am happy to see two different approach I believe it is good for both community that they inspire each other ( flutter -> compose, nullability from Kotlin -> Dart etc)

[kpgalligan]

Had a long message but managed to fumble it somehow. Anyway, summary, “Without a good architecture” is true of all things, and the iOS political resistance would likely be Kotlin <= Flutter. Not sure if that’s what you’re saying, but I’ve had that argument more than once. Not to minimize the iOS resistance to Kotlin. It is non-trivial.

[kioba]

I just meant that kotlin on ios raises issues that I wish we had a discussion about.
Like what does a kotlin native brings on ios hiring ie: too much code sharing and swift developers wont apply.

How to deal with the team lead responsibilities when the Android team grows and the ios stays small.

[kpgalligan]

These are concerns or issues you’ve had specifically? I guess my response is, sure, there are political issues, and I can’t imagine any team not having these discussions. I fully expect iOS devs on a team will raise several issues when evaluating. However, none of these are particularly Kotlin specific, except maybe “Android team grows”, but that assumes the Android team does all Kotlin, which is a bad way to pitch it. “Selling” Kotlin to iOS people is kind of my focus right now. To those specific concerns I’d say the following:

[kpgalligan]

“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.

[kpgalligan]

“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.

[kpgalligan]

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