Kotlin Multiplatform for Android and iOS Apps(rockandnull.com)
rockandnull.com
Kotlin Multiplatform for Android and iOS Apps
https://www.rockandnull.com/kotlin-multiplatform-compose-multiplatform-cross-platform-development/
81 comments
[deleted]
I think modern Java has stolen a lot of Kotlin’s thunder. The differences between the languages shrink with each Java release, and server side Kotlin isn’t evangelized by its main cheerleader, google.
It’s a GC language, so rust/zig are not good comps. Go, Java, Scala, Server side JS/Node, or python. These are the comps.
Personally, I’ve written a number of non-trivial, server side applications in Kotlin. The extra cost of asking my colleagues to learn another language and some pain in the interop with Java has dampened adoption. It’s a shame, I find the coroutine library a joy to use, with none of the painful drawbacks of go, node, python, etc.
It’s a GC language, so rust/zig are not good comps. Go, Java, Scala, Server side JS/Node, or python. These are the comps.
Personally, I’ve written a number of non-trivial, server side applications in Kotlin. The extra cost of asking my colleagues to learn another language and some pain in the interop with Java has dampened adoption. It’s a shame, I find the coroutine library a joy to use, with none of the painful drawbacks of go, node, python, etc.
These are all fair points for Java on the JVM or Android, but Kotlin Multiplatform does things that are well beyond the purview of the JCP.
It has downsides to be sure but it's not as simple as evaluating it as just another option for compiling to bytecode anymore.
It has downsides to be sure but it's not as simple as evaluating it as just another option for compiling to bytecode anymore.
Don't forget C#/F#. Microsoft's been leaning hard into cross-platform with MAUI.
Hot take: Microsoft can't do good UI frameworks and it shows. XAML makes some things really hard, resulting in loads of ValueConverters for example. Part of my bad experience might just be the learning curve but honestly I'm not surprised so much software is built using Electron.
I am actually using Avalonia+ReactiveUI for my current project (MAUI doesn't support Linux or F# last I checked), which I understand is similar to WPF... what a hot mess it is to wire up models to views in just the right way, especially in F#.
iOS dev here. What you're missing is that a ton of native-code developers (me included) aren't interested in adopting an abstraction layer that has to be tweaked to approximate the look and feel of the native OS UI layer when we could just built it natively to begin with and save all that effort. We've seen PhoneGap/Cordova, we've seen React Native and we'll keep seeing money thrown away on pretending that there aren't real platform differences when there are.
As an Android developer that's been using Compose and multiplatform I believe the play is to get Android developers to be able to minimally adapt their apps to run on iOS. They don't pretend that you don't need to know anything about iOS but are trying to abstract as much (or as little) a way to compile to both.
The other multiplatform attempts failed because they were trying to use languages that neither side wanted or knew and pretended like you could drop in a dev from a completely different field and not need to know much about the platforms. If you did know the platform you were fighting against the framework in an unfamiliar language.
That said it is definitely not there yet, but I hope they get it to a reasonable place. I've enjoyed Android development and would love to be able to more simply port over a project without a complete rewrite.
The other multiplatform attempts failed because they were trying to use languages that neither side wanted or knew and pretended like you could drop in a dev from a completely different field and not need to know much about the platforms. If you did know the platform you were fighting against the framework in an unfamiliar language.
That said it is definitely not there yet, but I hope they get it to a reasonable place. I've enjoyed Android development and would love to be able to more simply port over a project without a complete rewrite.
The idea is you can write SwiftUI on iOS, whilst connecting to business logic written in Kotlin.
Sort of but not really. SwiftUI is reactive, with view changes triggered by changes in Swift variables and those changes triggered using Combine. The later iterations of Swift include async/await to greatly simplify async code (normally but not always focused on network endpoints). You can write everything you need without having to drag Kotlin into the mix, and including Kotlin will require bridge code that seems (to me, at least) an unwanted obligation just to let some executive say "We saved some money by sharing code!".
No no no. Just look at the janky stuff one needs to do to compile Kotlin for an iOS project. Plus, object lifetime semantics differ. Now you won’t be able to write Kotlin native code without thinking of iOS rules. So now you have the worst of unfamiliar worlds with a “most fast” product speed.
im not a phone app dev, but im curious, cant you already write backend code in another language and the ui in swift
Business logic is not only about backend. Apps usually have a lot of client-side logic that can be written once in KMM and used on both platforms. See [1] for a high level architecture diagram.
I'm an iOS dev and I've been using KMM on a couple of projects for more than a year now. It's really a powerfull technology which allows teams to move faster, but there are downsides, for example lack of native Swift interop, though there are opensource tools trying to solve this [2].
[1]: https://github.com/Kotlin/kmm-production-sample/tree/master#... [2]: https://github.com/touchlab/SKIE
I'm an iOS dev and I've been using KMM on a couple of projects for more than a year now. It's really a powerfull technology which allows teams to move faster, but there are downsides, for example lack of native Swift interop, though there are opensource tools trying to solve this [2].
[1]: https://github.com/Kotlin/kmm-production-sample/tree/master#... [2]: https://github.com/touchlab/SKIE
Stack traces look like garbage though. I've developed a library for KMM. The iOS devs didn't want to touch it, so write once, make android devs keep it up. Also it was the network layer, so that's the easiest shit to write natively.
This. It’s exactly the same for me (also iOS dev, and I do Swift on the server too).
I use Kotlin daily at my job (I have to) and I'm not impressed. It is a new language that ignores most of the innovations in Programming Language Theory from the last 20 years. It only improves on Java by making the syntax less verbose and adding coroutines but almost doesn't add any benefits in terms of semantics.
Hi, I’m curious, can you elaborate on the language features that you think Kotlin ignores?
> It is a new language that ignores most of the innovations in Programming Language Theory from the last 20 years.
Such as?
Such as?
It's ok everyone, they must misspelled Go as Kotlin
I'd really, genuinely be interested in reading more about this theory, and what your criticisms of kotlin are.
No, really, I'm interested!
No, really, I'm interested!
Its trying to be everything, but its good at nothing. Even with spring boot, it has a painful edges.
Learning a language isn't a huge burden. Frameworks and libraries can alleviate huge burdens. Kotlin avoids the benefits of frameworks and libraries while giving meager benefits in term of language constructs.
Learning a language isn't a huge burden. Frameworks and libraries can alleviate huge burdens. Kotlin avoids the benefits of frameworks and libraries while giving meager benefits in term of language constructs.
Can you elaborate on the painful edges and the benefits of frameworks avoided?
I wanna understand better as I do kotlin in daily basis, some with spring, some with ktor and some with android and I don't get your points.
I wanna understand better as I do kotlin in daily basis, some with spring, some with ktor and some with android and I don't get your points.
`kotlinc-native` is one of the slowest compilers out there. Try compiling a "Hello, World!" program. It's slower than `rustc`. By a lot.
From my admittedly limited experience KMM is a complete mess.
There doesn't seem to be a reasonable feature set across platforms.
Even the standard library has massive holes, forcing you to littler your code with expect/actuals everywhere.
This might be manageable for my own code, but completely destroys the ecosystem.
A very large number of important libraries only works the JVM. Jetpack Compose and Compose Multiplatform are also not the same. I typically can't use libs written for Jetpack Compose in Compose Multiplatform.
I would argue that the shared feature set is quite reasonable. You get coroutines, you get Ktor, date/time libraries, kotlinx.serialization. You even get metaprogramming via KSP.
I basically only write expect/actual implementations to talk to platform APIs, but even those, when abstracted correctly behave just like a normal API to users.
You still write the UI layer natively. IMO this is a positive not a negative unless you're working on a product that doesn't care about native UX. And if you REALLY want a shared UI layer, Compose Multiplatform seems to be right around the corner.
I basically only write expect/actual implementations to talk to platform APIs, but even those, when abstracted correctly behave just like a normal API to users.
You still write the UI layer natively. IMO this is a positive not a negative unless you're working on a product that doesn't care about native UX. And if you REALLY want a shared UI layer, Compose Multiplatform seems to be right around the corner.
The JVM’s biggest feature is all the millions of great quality packages it has.
I agree, but the subset of those that's relevant to mobile (Android, and with KMM, iOS) development often has KMM-compatible counterparts. The exceptions to that would be libraries that rely on runtime reflection heavily (serialization libraries for example), those are mostly replaced with libraries that work statically and/or code generation via KSP.
Spoiler alert: We (iOS developers) don't.
The downside of this approach, like most other multiplatform approaches, is that it disadvantages the web which is the platform most sensitive to code size and accessibility concerns.
Compose Multiplatform requires WASM (with GC!). This is going to require a Kotlin runtime plus Skia bundled in the WASM, probably with large parts of the standard library, and draw everything to the screen with canvas. Like Flutter apps, these apps will not load fast and will probably have accessibility issues.
Compose Multiplatform requires WASM (with GC!). This is going to require a Kotlin runtime plus Skia bundled in the WASM, probably with large parts of the standard library, and draw everything to the screen with canvas. Like Flutter apps, these apps will not load fast and will probably have accessibility issues.
I haven’t yet tried KMP, but I think Kotlin in general is slept on here on HN. My experience is on the server side with both Micronaut and Spring Boot and it’s such an ergonomic language to write in. It’s probably my favorite language thus far.
It’s a great language but it hasn’t really found a killer app yet outside of Android development and Java has improved a lot recently so the incentive to switch to Kotlin is reduced.
I’d like to see it thrive but I’m not optimistic.
I’d like to see it thrive but I’m not optimistic.
The over-proliferation of xplatform framework complexity has come full circle and now it’s easier and more productive to just ship SwiftUI & Jetpack Compose
I don't see what the difference is between using React Native vs Flutter vs Compose Multiplatform. You will still be basically putting all of your eggs in a corp's basket.
What if Jetbrains decides overnight "you know what? this whole Compose Multiplatform is taking up too many of our resources, we're going to retire it at the end of this quarter"?
What if Jetbrains decides overnight "you know what? this whole Compose Multiplatform is taking up too many of our resources, we're going to retire it at the end of this quarter"?
I really don't get the appeal of "multiplatform" rediscoveries. We already have the Multiplatform stack that is mature and truly Multiplatform: HTML+JS+CSS
If you need something close to the metal, you have C and others that are multiplatform. If you want to do something slightly platform specific you loose the multiplatform claim instantly anyway.
IMHO, if you are going to do something that is not an UI to an API or a database, just do it in the native toolset for the platform so you can do it properly. Otherwise, just do a web app.
Apple's iOS API&Frameworks is quite extensive, if you are not doing just an UI then you will likely need to learn that. And for the UI? If your app is going to match the iOS conventions, do it in SwiftUI or UIKit as Apple will handle most of the stuff for you. It's probably the same for Android, no?
If you need something close to the metal, you have C and others that are multiplatform. If you want to do something slightly platform specific you loose the multiplatform claim instantly anyway.
IMHO, if you are going to do something that is not an UI to an API or a database, just do it in the native toolset for the platform so you can do it properly. Otherwise, just do a web app.
Apple's iOS API&Frameworks is quite extensive, if you are not doing just an UI then you will likely need to learn that. And for the UI? If your app is going to match the iOS conventions, do it in SwiftUI or UIKit as Apple will handle most of the stuff for you. It's probably the same for Android, no?
It's only hard to understand if you regard html, js, and css as good enough. It's the reason why people prefer native development on mobile. Standards are a bit different there than on the web and the space is more competitive.
Kotlin multiplatform and compose multiplatform are about leveling the playing field a bit and giving developers more choices than this one size fits all straight jacket that is the "modern" web (I use the word modern loosely here).
And it allows people targeting mobile to target other platforms with their code bases. If it's valid to use the web on mobile, then why not use mobile frameworks on the web?
Kotlin multiplatform and compose multiplatform are about leveling the playing field a bit and giving developers more choices than this one size fits all straight jacket that is the "modern" web (I use the word modern loosely here).
And it allows people targeting mobile to target other platforms with their code bases. If it's valid to use the web on mobile, then why not use mobile frameworks on the web?
With KMP is that you can write all your logic in one language, then reuse that in all platforms, including iOS, Android and Web. That's quite valuable if it works well. I've been trying just that at work with mixed results... The lack of a multiplatform stdlib for pure Kotlin is very tough if you need to do a lot of crypto, various serialization formats etc. so you end up writing lots of multiplatform APIs that are implemented in the respective platform, losing most of the point of using KMP.
I wouldn't want to write the UI also in KMP, though you could do even that if you don't mind using beta software (see https://www.jetbrains.com/lp/compose-multiplatform/).
Using Flutter makes much more sense in that case as nowadays it's very mature, has a huge library and excellent developer UX.
I wouldn't want to write the UI also in KMP, though you could do even that if you don't mind using beta software (see https://www.jetbrains.com/lp/compose-multiplatform/).
Using Flutter makes much more sense in that case as nowadays it's very mature, has a huge library and excellent developer UX.
Yeah, the library ecosystem for KMM is lacking. Also the build system used to be a headache. I haven't tried KMM recently but it was so unintuitive a year back
It actually improved a lot. There are a lot of pretty decent multiplatform libraries out there. I've developed a few myself. It's pretty easy and straightforward. You are right that the tools were a bit rough a year ago. But they worked. I've been developing kotlin-js and multiplatform stuff since 2020. Definitely very cutting edge back then and not for the faint hearted. But our bet worked out and we now have a nice thriving business and a maintainable code base.
In fairness, KMM and KMP are still in beta and the compiler has been in the process of being overhauled. That's a process that is nearly completed but it is still ongoing. Having used the new k2 compiler with kotlin-js, it's a big upgrade in terms of performance. I expect a lot of stuff to start stabilizing post Kotlin 2.0, which should be out in later winter/spring next year. 1.9.10 is the current release. 1.9.20betas are already out. There might be a .30 but the release after that is basically 2.0. 3-6 months out basically if Jetbrains sticks to their normal release schedule.
IOS support in Compose Multiplatform is alpha quality. You shouldn't use it for anything important. But when it is done, you can expect to be able to develop applications with one code base that run nicely on Android, IOS, the web, or on desktops.
Compose web is actually targeting the new wasm compiler. Which of course is also alpha. That's an interesting one because it uses the WASM standardize GC facilities. That's currently out in browsers already but hidden behind feature flags. Which are very likely to come off soonish.
Give it a year or two. Too early to write it off now when it is basically all early access and alpha/beta quality. IMHO, there is some good tech coming together there.
In fairness, KMM and KMP are still in beta and the compiler has been in the process of being overhauled. That's a process that is nearly completed but it is still ongoing. Having used the new k2 compiler with kotlin-js, it's a big upgrade in terms of performance. I expect a lot of stuff to start stabilizing post Kotlin 2.0, which should be out in later winter/spring next year. 1.9.10 is the current release. 1.9.20betas are already out. There might be a .30 but the release after that is basically 2.0. 3-6 months out basically if Jetbrains sticks to their normal release schedule.
IOS support in Compose Multiplatform is alpha quality. You shouldn't use it for anything important. But when it is done, you can expect to be able to develop applications with one code base that run nicely on Android, IOS, the web, or on desktops.
Compose web is actually targeting the new wasm compiler. Which of course is also alpha. That's an interesting one because it uses the WASM standardize GC facilities. That's currently out in browsers already but hidden behind feature flags. Which are very likely to come off soonish.
Give it a year or two. Too early to write it off now when it is basically all early access and alpha/beta quality. IMHO, there is some good tech coming together there.
In KMM multiplatform means Kotlin code can directly interoperate with Swift on iOS or Java on Android. HTML cannot do these things.
Just being able to make client code for an HTTP API that can be installed into Javascript, Android, and iOS projects with identical logic is a pretty big win.
> We already have the Multiplatform stack that is mature and truly Multiplatform: HTML+JS+CSS
And that translates to Electron on the desktop environment and a webview on mobile devices I guess?
How is that better than Flutter for example? With Flutter, I am able to write once and compile to all platforms.
And that translates to Electron on the desktop environment and a webview on mobile devices I guess?
How is that better than Flutter for example? With Flutter, I am able to write once and compile to all platforms.
I've been curious about Kotlin Multiplatform for cross platform desktop apps (as an alternative to Electron).
If anyone here has used it for that, care to share your experience?
If anyone here has used it for that, care to share your experience?
- Flutter is reliable and simple to build with
- React Native is easy to find workers for but slow
- Kotlin is somewhat in the middle of both but has better performance
- Tauri is coming out of left field with webview2 apps but it's very early days for their mobile plans and completely unproven
Kotlin does a good job with all the compromises you have to make with cross platform but it's quite application dependent?
- React Native is easy to find workers for but slow
- Kotlin is somewhat in the middle of both but has better performance
- Tauri is coming out of left field with webview2 apps but it's very early days for their mobile plans and completely unproven
Kotlin does a good job with all the compromises you have to make with cross platform but it's quite application dependent?
I started building a Flutter app recently and so far I’ve been quite impressed. The ecosystem is surprisingly mature and dev velocity has been good even though I’m learning a new language and framework at the same time. On a purely technological level I’d take this over React Native any day and I have a lot of React experience.
I think Google has a winner on their hands here if they don’t give up on it.
I think Google has a winner on their hands here if they don’t give up on it.
Big worry for me has been a history of ignoring ios bugs for years, causing things like long startup times
You are probably thinking of the shader compilation step that has to happen - https://docs.flutter.dev/perf/shader - and the long term solution (from the page) is https://github.com/flutter/flutter/wiki/Impeller
It’s a legitimate concern but so far my experience on iOS has been quite good. They’ve put a lot of effort into polishing iOS performance recently.
Dart is honestly so easy to pick up, seen it cop some flack on here but its simplicity is a virtue, have onboarded people with zero experience and they are perfectly productive within a week. There's not many languages like that.
Tools, language and performance are great.
Ecosystem is no good. Almost all Kotlin libraries assume Android and don’t work on multi platform. Common things just don’t exist.
Ecosystem is no good. Almost all Kotlin libraries assume Android and don’t work on multi platform. Common things just don’t exist.
I've mostly stayed away from mobile development because Android projects look too complicated to get started on even NDK projects. The value of learning those APIs to me isn't even close to what you get by learning Web APIs. So if I invested my time to learning it I don't feel Is get as much out of it.
Maybe something like Kotlin/Compose Multiplatform can help. But, really if they made Android APIs (or React-native/Flutter/Compose) into a ISO/ECMA/ANSI whatever standard it would feel like I'm not just throwing away my time on some proprietary API that may change in a way that I have to update my app or loose my investment.
Maybe something like Kotlin/Compose Multiplatform can help. But, really if they made Android APIs (or React-native/Flutter/Compose) into a ISO/ECMA/ANSI whatever standard it would feel like I'm not just throwing away my time on some proprietary API that may change in a way that I have to update my app or loose my investment.
Try Flutter. It's amazing how easy it is to get started with a desktop app in any OS, and then just run it on mobile (or emulators which are easy to install via Android Studio or VS Code) when you want to without having to deal with almost any of the crap iOS and Android developers need to... Flutter generates all manifests and what not, and the docs show exactly what to do to sign artifacts and stuff that requires you to very briefly have to open XCode to set up those things.
I did some time ago. Back then it seemed like Flutter was like a parallel world where a different set of languages and APIs existed instead of the Web APIs. Which I thought was interesting. However unlike Web APIs Flutter didn't have the girth of resources tutorials and documentation available.
I don't know exactly if that's what stopped me or maybe I'm just just not meant for learning UI libraries of any sort as even something like Dear Imgui has been unattractive to me.
I don't know exactly if that's what stopped me or maybe I'm just just not meant for learning UI libraries of any sort as even something like Dear Imgui has been unattractive to me.
I used to favor the web for the same reasons but the churn in web technology is at least as bad in mobile. The knowledge I had three years ago is almost useless now. And on top of that you have to deal with a platform that is really a big pile of quick hacks that was never intended for building complex and performant applications.
Ironically mobile has been one of the most stable api platforms to develop against in my entire career, especially in iOS. New libraries and languages are mostly iterative and make sense to support a new feature.
I don't use frameworks or compile to js languages. I've only learned the plain html, css, js and DOM APIs. I have the same reservations about React and Typescript as I do these mobile APIs.
Then again my use of these things is that of a hobbyist so I have a choice in these things.
Then again my use of these things is that of a hobbyist so I have a choice in these things.
Many people seem to overlook the fact that Kotlin Multiplatform (KMP) is primarily developed for the purpose of sharing logic. KMP provides capabilities that are on par with what native C++ and C libraries have offered for several years, but with a higher level of sophistication.
For those who discuss 'compose multiplatform' and UI sharing using KMP, it's essential to understand that KMP's primary focus is logic sharing. Sharing user interfaces is merely an additional capability it offers via Compose Multiplatform. I strongly recommend that everyone conducts further research. Comparing KMP with Flutter and React Native is like comparing apples and oranges.
For those who discuss 'compose multiplatform' and UI sharing using KMP, it's essential to understand that KMP's primary focus is logic sharing. Sharing user interfaces is merely an additional capability it offers via Compose Multiplatform. I strongly recommend that everyone conducts further research. Comparing KMP with Flutter and React Native is like comparing apples and oranges.
ive been rocking with flutter since 2018 and im not going anywhere
> With KMM the promise is that you can have a native app in one of the major platforms (Android) and a good-enough app for the other major platform (iOS).
> You might be able to write UI and business logic in Kotlin for your Android app, and easily port it to iOS to kick-start your app journey. When the app becomes big enough (and you choose so) you can write a native iOS UI and still share the business logic between the 2 apps.
This seems like the less common order, anecdotally.
> You might be able to write UI and business logic in Kotlin for your Android app, and easily port it to iOS to kick-start your app journey. When the app becomes big enough (and you choose so) you can write a native iOS UI and still share the business logic between the 2 apps.
This seems like the less common order, anecdotally.
I think this has potential but if I were starting an app today I’d pick a more mature technology like React Native or Flutter.
For multi platform development I am more interested in tauri or capacitor in conjunction with svelte.
I’m familiar with phone gap which I believe does this, but is it kosher to have some sort of proxy app that gives you native api calls and otherwise just use a web page? I know you can do something similar with a web view but was curious.
Nah, this is more like React Native than PhoneGap, there’s no webview involved. The Kotlin code is somehow compiled into something that can run on iOS in a native or native-ish way.
You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md.
iOS devs don't want to use Kotlin multiplatform, I really doubt this will gain any traction.
As an iOS user, I also don’t want to use Kotlin Multiplatform, as it breaks my muscle memory and behaves just so slightly differently that it is enough to be annoying.
Same goes for any other multi platform GUI.
Same goes for any other multi platform GUI.
Yeah, but Android devs may use KMM. This is an Android dev focused product. It might grow to be something people choose first (like choosing flutter), but today it is a Android first ecosystem.
Kotlin is a Google project that wants to be cross platform, write once run everywhere. So is dart/flutter.
I feel dart is further along on this.
Seems a little silky having 2 projects aimed at the same thing?
I feel dart is further along on this.
Seems a little silky having 2 projects aimed at the same thing?
Kotlin is not a Google project. It is made by JetBrains. It says so right up front on their web page: https://kotlinlang.org/
Oops what a mistake, apologies. That's what I get for misreading Wikipedia. I stand corrected.
With significant advancements in AI technologies, including solutions like ChatGPT/Bard, I am considering this issue of multi-platform from a standpoint of AI. If an application has been developed for a major platform, adapting the same applications for other platforms could potentially be managed by Co-Pilot. For instance, I can already create applications with the assistance of ChatGPT.
I’m gonna wait for them to be able to solve a sudoku first, before daring to give them any non-toy code.
reddit.com/r/lostredditors/
Kotlin is indeed popular in it's specific domain (Android & Java). But the company is keen to position it as "write once run anywhere" space with a strong focus on multiplatform development.
1. The build system provides platform specific bindings for free (huge plus compared to the hassle of writing the core in C/C++ and then hand-writing platform specific bindings)
2. Keen focus on enabling single codebase for multiple platforms.
3. The company went so far, as to build a multi-platform UI Framework (Compose Multiplatform) that directly renders to Skia and runs on all mobile/desktop platforms. And even on browsers (with wasm)
I find it odd, that such interesting a language / compiler finds little attention beyond its domain.
Is there any reasons for this that I'm missing?