Hey all, is the long-term plan of Jetbrains to hav...

# multiplatform

[Arjan van Wieringen]

Hey all, is the long-term plan of Jetbrains to have Kotlin Multiplatform be mainly on business logic? It says so explicitly on the KMP website.
The reason I am asking is that I've been working with Kotlin for 7 years now and I love this language a lot. However, lately a friend of mine, without any programming experience starting learning to program using Udemy in 2020 in C#. For his company he made an app that works on iOS and Android. Not looking at architectural issues and what not, I was blown away by the fact that he was able to do that so easily, with 1 codebase.
I've been heavily interested in Kotlin Multiplatform, and have attended the KotlinConf workshop in 2019, which was awesome, but it was rough around the edges. I've seen a lot of improvements all around, but I am struggling to see if there is currently a point where having 1 Kotlin codebase for Android + iOS app is feasible.

For now:
• Android = Compose obviously, so that's easy
• Web = Compose for Web (not Canvas, but DOM)
• Desktop = Compose for Desktop, which is awesome by the way
• IOS = ... ViewModels in Kotlin and SwiftUI in Swift?
Compose Multiplatform is pretty experimental, to say the least, so I would never use that in production. So that means SwiftUI?

For me this is a large barrier of entry for me and also as a technology choice for a team. You'd always require Swift knowledge and that is not always readily available, especially in this market. Looking at the likes of Flutter and Maui I see that they clearly target this 1-codebase approach. I understand they have other drawbacks. But currently they have solutions that work already for a while including tooling. The fact that an inexperienced developer can get an iOS + Android app working, for internal use only, in Maui made me question actually the state of Kotlin in this regard.

Compose and Coroutines and all the awesome language features make Kotlin my favorite choice, but I am struggling whether I would choose it as a technology choice for creating an Android + iOS app. What are your experiences in this regard and/or am I missing something completely?

The testimonials of CashApp/Netflix/Philips (which made me smile as old Philips employee) are great of course. But those are big experienced teams with loads of knowledge and they (CashApp / Netflix at least) aren't companies I'd suspect have a lot of difficulty hiring excellent Swift engineers.

[streetsofboston]

KMM/KMP shines when the choice has been made, for various reasons, to have pure native UI/UX/behavior on iOS, Android, etc.
It allows you to speed up development by sharing code on 2 (or more) separate codebases.

Not sure what framework your friend used (i think it's Xamarin/MAUI?), but it won't create a pure native UI/UX. Same for React Native or Flutter. That's a tradeoff you or your company has to make when building an app.

[Casey Brooks]

While Compose is taking Kotlin closer to a place where it could compete with Flutter/React Native/Maui, it intentionally didn't start that way. There's a big gap in the market for sharing some code between apps, but not all, and that's where Kotlin has been focused for the most part. Its competitor was closer to C++, which was really the only other feasible option for sharing business logic code for a long time.

But like I said, it's moving in the direction of sharing entire codebases, but the choice to not start with that has actually been a good one. It's forced the Kotlin team and developers using it to try and understand the more general problem of multiplatform development, rather than just using a multiplatform toolkit that can only do UI. It makes Kotlin significantly more flexible than the alternatives

[Casey Brooks]

Here's a couple well known examples of where companies had trouble sharing code cross platform, where Kotlin would have made a big difference had it been around at that time

https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android

https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a#:~:text=In%20addition%2C%20there%20were%20a,our%20efforts%20back%20into%20native

[Arjan van Wieringen]

@streetsofboston My friend uses Maui. I understand that it is not a truly native UI experience, just like Flutter. But how often does that really matter, or is the deciding factor in picking a technology? What is the true benefit of a native UI and will most basic apps benefit from it?

@Casey Brooks But Xamarin already allowed sharing of business logic right? I understand that it was a very good choice to start as they did, and I do not challenge that. However, it feels that for cross-platform single code base development, especially when including iOS, Kotlin is pretty far behind the rest.

[streetsofboston]

Non native, x-platform frameworks, often have have close but not true native UI/UX, which may cause cognitive dissonance for the end-users (some performance issues, animations and gestures slightly different, etc); issues with integration of native OS hardware, peripherals, services (eg Google Play Services) which can be overcome but that again/still requires a pure native skillset from the developers. Others are lock-in into the x-platform ecosystem and architectural patterns, not being able to keep up with innovations on the native platforms (eg needing to wait when Xamarin will support that new feature).

And for larger scale apps, not prototypes or PoCs, having a x-platform for Android and iOS doesn't save you 50% of effort and time developing it (it's more like 35%). You still have 2 platforms to test, deal with different sets of bugs on 2 separate platforms that you have to fix in 1 codebase, code that still would need if-statements here and there, etc.

[streetsofboston]

In short, choosing the right native or the right x-platform/framework needs to be done carefully, based on your (client) apps needs, (client) apps user base, skillset of your developers (at your client), future roadmap, etc etc etc

[Arjan van Wieringen]

@streetsofboston Thanks! That is a very clear explanation.

[streetsofboston]

But it's true that the language Kotlin is not used in any of the current popular cross-UI frameworks. That would have been nice (looking at you, Flutter 😊)

[Arjan van Wieringen]

I am very interested in Flutter, but Dart seems like a limited version of Kotlin

[streetsofboston]

Kotlin is as related to Dart as it is to Swift 😁
All kidding aside, they are not related even though they share some similarities

[Michael Paus]

@streetsofboston You should also consider JavaFX. It’s a cross-UI framework and of course you can use Kotlin for it. It works on all desktop, Android and even iOS devices (and on the web too).

[streetsofboston]

JavaFX has never been really a viable alternative for our clients. This thread sums up some of its issues
https://www.reddit.com/r/java/comments/re4czb/what_is_your_take_on_the_current_state_of_javafx/