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.
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.
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 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.
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 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"?
It depends on how popular the library gets before the plug gets pulled. If it's popular, it can survive because it's Open Source, and it actually has an advantage over actual proprietary platforms.
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.
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.
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'm puzzled why Kotlin isn't getting enough attention on HN, at least as much as Rust or Zig.
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.
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.
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].
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.
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.
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.
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.
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#.
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.
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.
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 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?
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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.
81 comments
[ 3.3 ms ] story [ 322 ms ] threadIf anyone here has used it for that, care to share your experience?
Ecosystem is no good. Almost all Kotlin libraries assume Android and don’t work on multi platform. Common things just don’t exist.
- 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 think Google has a winner on their hands here if they don’t give up on it.
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.
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"?
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.
Then again my use of these things is that of a hobbyist so I have a choice in these things.
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.
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?
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
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.
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 has downsides to be sure but it's not as simple as evaluating it as just another option for compiling to bytecode anymore.
Such as?
No, really, I'm interested!
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.
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.
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?
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.
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.
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.
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?
I’d like to see it thrive but I’m not optimistic.
> 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.
Same goes for any other multi platform GUI.
I feel dart is further along on this.
Seems a little silky having 2 projects aimed at the same thing?
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.
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.