8 ms·

Kotlin Multiplatform for Android and iOS Apps

60 points by synergy20 3y ago

eatonphil 3y ago
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?
- scosman 3y ago
  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.
- Grimburger 3y ago
  - 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?
  - cageface 3y ago
    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.
    - novok 3y ago
      Big worry for me has been a history of ignoring ios bugs for years, causing things like long startup times
      - cageface 3y ago
        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.
      - malkia 3y ago
        You are probably thinking of the shader compilation step that has to happen - https://docs.flutter.dev/perf/shader https://docs.flutter.dev/perf/shader - and the long term solution (from the page) is https://github.com/flutter/flutter/wiki/Impeller https://github.com/flutter/flutter/wiki/Impeller
    - Grimburger 3y ago
      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.
YmiYugy 3y ago
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.
- blashyrk 3y ago
  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.
  - kaba0 3y ago
    The JVM’s biggest feature is all the millions of great quality packages it has.
    - blashyrk 3y ago
      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.
  - dickersnoodle 3y ago
    Spoiler alert: We (iOS developers) don't.
sqoopd 3y ago
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.
- your_challenger 3y ago
  reddit.com/r/lostredditors/
- kaba0 3y ago
  I’m gonna wait for them to be able to solve a sudoku first, before daring to give them any non-toy code.
clawoo 3y ago
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"?
- bad_user 3y ago
  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.
  - akmarinov 3y ago
    Nah, once the big corporation backing it is out, it’s a slow agonizing death
cageface 3y ago
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.
byyoung3 3y ago
ive been rocking with flutter since 2018 and im not going anywhere
bobajeff 3y ago
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.
- cageface 3y ago
  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.
  - novok 3y ago
    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.
  - bobajeff 3y ago
    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.
- brabel 3y ago
  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.
m3kw9 3y ago
Ain’t no fing way gonna use an android first language on iOS platform
- carbl 3y ago
  Then maybe this is not for you. A bit unsure how this adds value to the discussion though.
- wiseowise 3y ago
  It’s not Android first language.
lewisjoe 3y ago
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. Is there any reasons for this that I'm missing?
- dickersnoodle 3y ago
  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.
  - frizlab 3y ago
    This. It’s exactly the same for me (also iOS dev, and I do Swift on the server too).
  - mike_hearn 3y ago
    The idea is you can write SwiftUI on iOS, whilst connecting to business logic written in Kotlin.
    - medo-bear 3y ago
      im not a phone app dev, but im curious, cant you already write backend code in another language and the ui in swift
5cott0 3y ago
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
mrtksn 3y ago
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?
- brabel 3y ago
  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/ 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.
  - your_challenger 3y ago
    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
    - jillesvangurp 3y ago
      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.
yafetn 3y ago
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.
- cageface 3y ago
  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.
e28eta 3y ago
> 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.
endisneigh 3y ago
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.
- Uehreka 3y ago
  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.
  - dickersnoodle 3y ago
    You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md https://github.com/apple/swift/blob/main/docs/Android.md.
tschellenbach 3y ago
iOS devs don't want to use Kotlin multiplatform, I really doubt this will gain any traction.
- your_challenger 3y ago
  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.
- Longhanks 3y ago
  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.
willi59549879 3y ago
For multi platform development I am more interested in tauri or capacitor in conjunction with svelte.
account-5 3y ago
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?
- spankalee 3y ago
  Kotlin is not a Google project. It is made by JetBrains. It says so right up front on their web page: https://kotlinlang.org/ https://kotlinlang.org/
  - account-5 3y ago
    Oops what a mistake, apologies. That's what I get for misreading Wikipedia. I stand corrected.
spankalee 3y ago
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.
sashenka 3y ago
[dead]
harley1611 3y ago
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.

60 points by synergy20 3y ago

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?

scosman 3y ago
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.
Grimburger 3y ago
- 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?
- cageface 3y ago
  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.
  - novok 3y ago
    Big worry for me has been a history of ignoring ios bugs for years, causing things like long startup times
    - cageface 3y ago
      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.
    - malkia 3y ago
      You are probably thinking of the shader compilation step that has to happen - https://docs.flutter.dev/perf/shader https://docs.flutter.dev/perf/shader - and the long term solution (from the page) is https://github.com/flutter/flutter/wiki/Impeller https://github.com/flutter/flutter/wiki/Impeller
  - Grimburger 3y ago
    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.

YmiYugy 3y ago

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.

blashyrk 3y ago
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.
- kaba0 3y ago
  The JVM’s biggest feature is all the millions of great quality packages it has.
  - blashyrk 3y ago
    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.
- dickersnoodle 3y ago
  Spoiler alert: We (iOS developers) don't.

sqoopd 3y ago

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.

your_challenger 3y ago
reddit.com/r/lostredditors/
kaba0 3y ago
I’m gonna wait for them to be able to solve a sudoku first, before daring to give them any non-toy code.

clawoo 3y ago

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"?

bad_user 3y ago
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.
- akmarinov 3y ago
  Nah, once the big corporation backing it is out, it’s a slow agonizing death

cageface 3y ago

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.

byyoung3 3y ago

ive been rocking with flutter since 2018 and im not going anywhere

bobajeff 3y ago

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.

cageface 3y ago
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.
- novok 3y ago
  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.
- bobajeff 3y ago
  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.
brabel 3y ago
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.

m3kw9 3y ago

Ain’t no fing way gonna use an android first language on iOS platform

carbl 3y ago
Then maybe this is not for you. A bit unsure how this adds value to the discussion though.
wiseowise 3y ago
It’s not Android first language.

lewisjoe 3y ago

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. Is there any reasons for this that I'm missing?

dickersnoodle 3y ago
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.
- frizlab 3y ago
  This. It’s exactly the same for me (also iOS dev, and I do Swift on the server too).
- mike_hearn 3y ago
  The idea is you can write SwiftUI on iOS, whilst connecting to business logic written in Kotlin.
  - medo-bear 3y ago
    im not a phone app dev, but im curious, cant you already write backend code in another language and the ui in swift

5cott0 3y ago

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

mrtksn 3y ago

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?

brabel 3y ago
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/ 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.
- your_challenger 3y ago
  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
  - jillesvangurp 3y ago
    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.

yafetn 3y ago

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.

cageface 3y ago
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.

e28eta 3y ago

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

endisneigh 3y ago

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.

Uehreka 3y ago
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.
- dickersnoodle 3y ago
  You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md https://github.com/apple/swift/blob/main/docs/Android.md.

tschellenbach 3y ago

iOS devs don't want to use Kotlin multiplatform, I really doubt this will gain any traction.

your_challenger 3y ago
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.
Longhanks 3y ago
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.

willi59549879 3y ago

For multi platform development I am more interested in tauri or capacitor in conjunction with svelte.

account-5 3y ago

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?

spankalee 3y ago
Kotlin is not a Google project. It is made by JetBrains. It says so right up front on their web page: https://kotlinlang.org/ https://kotlinlang.org/
- account-5 3y ago
  Oops what a mistake, apologies. That's what I get for misreading Wikipedia. I stand corrected.

spankalee 3y ago

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.

sashenka 3y ago

[dead]

harley1611 3y ago

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.