9 ms·

Kotlin multiplatform is stable and production-ready

90 points by cvb941 3y ago

monlockandkey 3y ago
I think the most beneficial part is the sharing of logic. With UI, I don't think using skia is the way to go like flutter. But well done to the team and hopefully this continues to grow and see investment.
- whoopsie 3y ago
  Object lifetime semantics differ, forcing devs to think about non-native considerations on both Android and iOS. For a lot of CRUD apps the savings is minimal for networking / logic layers.
sdflhasjd 3y ago
Good to hear - though I've seen this being deployed a few times now and it seems to have been mature enough for a while. Has anyone really had a chance to use Compose Multiplatform on iOS? I've love to get an an opinion on what "Alpha" really means in this case Most of the projects I've been working on have been about playing it safe by sticking to React Native or MAUI/Xamarin - but they're both kind of getting a little bit behind with Swift UI and Compose now. The constant ritual of writing the same thing twice for 2 mobile platforms must have wasted more developer hours than anything I can really think of.
- stefs 3y ago
  > The constant ritual of writing the same thing twice for 2 mobile platforms must have wasted more developer hours than anything I can really think of. probably the only thing that wasted even more developer hours was trying to get the same thing to run on two different mobile platforms.
  - palata 3y ago
    Damn it! I wanted to say that, but you were faster :-)
- sickcodebruh 3y ago
  I didn’t realize Compose could now target iOS! That’s exciting. I haven’t written Kotlin or used Jetpack Compose since the before the latter’s 1.0 release but I was very impressed at the time. Kotlin in particular stood out as an expressive, powerful, fun language. Compose had some rough edges but I picked it up, new to Android and Kotlin, and was productive very quickly. I’ll certainly consider Compose Multiplatform next time I have the need.
jamil7 3y ago
Is anyone using this in production? I played around with it a year or two ago, and it was a little rough. I recently built something internal using Rust and UniFFI for a similar purpose. I much prefer Rust's tooling, but it would be nice to not introduce a third language. There is probably a more minimal environment I can use and not need Android Studio installed, but I'm not that familiar with Kotlin or Android development (Swift/iOS/mac day job).
- thecupisblue 3y ago
  Been using it for a while now in production, both for mobile apps, SDK's and some critical parts of codebase. While it works great, there are some caveats and additional tooling you need for iOS (i.e. if you want to get the pattern matching for sealed classes as enums, you need external tooling). There was some issues with coroutines, but IIRC also solved recently. For tooling, you can use IntelliJ or anything else you prefer, since you don't need all the "Android studio stuffing" until you go directly into Android development. It's just Kotlin + gradle build system. The best thing is Kotlin - a powerful language with great syntax sugar, allowing you to write readable and performant code. Even tho at core it's a JVM language, it is compiled directly into the native language of the platform instead of providing you with a "wrapped JVM". To interact with "native" code, you only write an interface in common code and then implement the actual interfaces in the platform code, allowing you to share the contract across platforms but delegate the details. To allow for running on other platforms, some tradeoffs are made (including the kotlin stdlib which blows up the size among some), but the saved time you get from having only one codebase shared as a library among multiple platforms is insane. The language itself is quite mature, super comfortable to write and missing only two things: Actors, Macros and Unions. Traits would be nice too, okay. Async/await is miles ahead of whatever state the Rust is in currently. Nowadays, my new project choice is: "do I go with Rust or do I go with Kotlin?", esp since now with WASM I can treat Rust as if it was multiplatform (Still, Kotlin is now adding WASM support and recently added WASI). But the maturity, flexibility and tooling usually make the dice fall on Kotlin.
- jurmous 3y ago
  I have used this in production for both Java and Web targets for a Startup. It did what it was promising although at earlier stage it took some research to make it work and had to adapt to changes. Now the multiplatform SDK is stable and way better documented. The Kotlin Slack community is also quite helpful for whenever you are stuck.
matsemann 3y ago
I have a bit trouble understanding what this is. Does it mean that I have to write my whole webapp or mobile-app in a Kotlin framework for it to give value? Or can I take some of my Kotlin libraries and convert so they're callable from js so I don't have to duplicate certain logic?
- sdflhasjd 3y ago
  The latter. You write your shared libraries in Kotlin, compile it for multiple runtime targets, then call your Kotlin code from whatever runtime you're using.
- tarkin2 3y ago
  Write your business logic in Kotlin with Kotlin libraries. Write your UI in Js/Android/iOS.
  - jurmous 3y ago
    It is also possible to write the UI in Kotlin cross platform with Compose Multiplatform.
- jurmous 3y ago
  You can work in whatever way makes sense for you to share code. Kotlin allows you to call native code (JS/C/ObjC/Java/WASM) from Kotlin, or you can call Kotlin functions from native code (JS/C/ObjC/Java/WASM). So you choose on what level you want to create shared code. So it is quite flexible so it is up to you on what level you want to share code. It can either be a low level library, a middle level library. And with maturing Jetpack Compose it is possible to build the whole app including UI multiplatform without leaving Kotlin.
tarkin2 3y ago
I’ve seen this used in a number of mobile shops when they need/want native frontends and to want share business logic, db use, networking etc. (My only gripe is that Kotlin more or less forces you to use IJ and gradle but most are happy with that). It’s been mature for a while now but has never seemed to get much airtime probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs.
- palata 3y ago
  > probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs. Most mobile companies I know do native Android/iOS development instead of using cross-platform frameworks.
  - tarkin2 3y ago
    I'm more wondering why this isn't more popular, at least with this crowd.
    - occz 3y ago
      One reason could be that people have been burned a few times too many by technologies promising the world with regards to cross-platform, and then failing to deliver on their promises. I think KMP could potentially be good enough to fly, but time will definitely tell on that.
      - palata 3y ago
        IMO cross-platform frameworks are "write once, debug everywhere". In my experience: 1. That's not particularly faster than writing native apps, but debugging is much more frustrating than writing native apps. So as a developer, cross-platform sucks, native dev is fun. 2. Desktop and Mobile are fundamentally different, so trying to write one app for both gives the worst of both worlds. Don't do that. 3. The "debug everywhere" part of cross-platform gets worse as the app gets more complicated. So the app is fundamentally getting more and more frustrating for the devs, which... well nobody wants. On the other hand, sharing code (or libraries) between platforms sometimes makes sense. And being able to do that in Kotlin instead of, say, C++ (or Rust, I know) is actually cool.
coldtea 3y ago
Amazing effort. And by that I refer to the feat of writing a huge article without bothering to explain what Kotlin Multiplaform is. "After several years of hard work by the JetBrains team, Kotlin Multiplatform reaches stable with the 1.9.20 release. This is a critical milestone for the platform and ecosystem. Kotlin Multiplatform was first announced at KotlinConf in 2017. Today, after years of work and amazing progress, Kotlin Multiplatform is stable! Along with progress on the tooling and library ecosystem, designating KMP to be stable will significantly increase adoption of the technology. Touchlab has been contributing to the KMP platform since the beginning, and some of our best work is still to come." And so on. From past reading, if I recall correctly it's a native version of Koltin (?) or a version targeted to mobile development for multiple mobile OSes, but can't be sure, nor about what kind of libs work with it (perhaps any?). This helps a little: https://www.jetbrains.com/kotlin-multiplatform/ https://www.jetbrains.com/kotlin-multiplatform/ Still, this page too could do a much better job, instead of selling "what it can do" to manager types: "Open-source technology by JetBrains for flexible multiplatform development" / "The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects." / "Reuse code across Android, iOS, web, desktop, and server-side while keeping native code if needed"), to plainly tell "what it is" to tech types. So, something like: "The shared business logic code for Android gets converted to Java bytecode that can be executed in JVM and Android has the virtual machine, so it can easily run it. But in the case of iOS, there is no virtual machine, so the code is converted to the native code that can be executed on iOS. Now in the Kotlin compiler, there is a frontend that converts the code into an intermediate representation known as IR, and the backend converts that intermediate representation to machine-executable code. So in the case of android, it converts it into java bytecode, and for iOS, it converts it into iOS native machine code." Had to go to a third party website to find this description.
- ahmedfromtunis 3y ago
  Thanks for the explanation. Unfortunately, this is far from being an isolated case. Very far. I used to play a game on Product Hunt where I'd open multiple links without reading the description on PH, and use the homepages to try to guess what each app does. Most of the time, it simply isn't possible. It was so frustrating that I stopped playing after awhile.
account-5 3y ago
How does/will this compare to dart/flutter?
- jurmous 3y ago
  Kotlin Multiplatform allows you to work fully native on Android as Kotlin is the main language there. And it also allows to compile to native iOS code and integrate with native iOS Objective-C code or bridge code. (Swift integration is on the roadmap) It also allows you to directly call C code or C libraries. Or it allows to compile to JS and call JS code. So it is more versatile than Flutter and easier to integrate with native code/components. Flutter is more creating its own world with the Dart sandbox and then has to pass messages to communicate with the native world. Kotlin is closer to native output. Jetpack Compose is the UI library and provides a similar mechanic as React/SwiftUI/Flutter in building declarative UIs. It is already the Android default as Google started to develop this UI library and Jetpacks brought in the multiplatform implementation.
  - account-5 3y ago
    I thought dart/flutter compiled to native code, on whatever platform it was on. And I thought dart could directly call libraries via it's ffi? I'm no expert so I'm likely wrong.
    - jurmous 3y ago
      If I am correct Flutter compiles to Dart code which compiles to Native code. Above I was more talking about platform integration. As Flutter their own document states everything within Dart is compiled to run like its own enclosed runtime environment. It talks with the native world with messages over channels. https://docs.flutter.dev/platform-integration/platform-channels https://docs.flutter.dev/platform-integration/platform-chann... Within Kotlin however it is possible to directly call the native method. So it looks like Flutter has more overhead for native communication than Kotlin. Here for example a part of a C interop tutorial in Kotlin. You can directly work with data coming from C libraries. https://kotlinlang.org/docs/mapping-primitive-data-types-from-c.html https://kotlinlang.org/docs/mapping-primitive-data-types-fro...
synergy20 3y ago
looks like a Java/kotlin version of flutter to me the doc mentioned desktop and web a little but 98% are about android and iOS I am more interested in cross platform desktop GUI,is this better than gtk or qt or wxwidgets? or swing?
- jurmous 3y ago
  Kotlin Multiplatform gives the mechanics to compile code to different platforms/targets. So it can compile code to Android, native iOS/linux/windows, web, beta web assembly, java runtimes and more. Compose Multiplatform is the Flutter equivalent. They work on a UI toolkit which compiles to desktop/mobile/web. It works with declarative patterns like Flutter/SwiftUI/React, so is a quite modern implementation to build UIs. So it is possible to build desktop apps. Jetbrains have build their toolbox app as first desktop app since a few years using Compose. It provides many UI elements to build Desktop apps and as Jetbrains itself is a big Desktop app developer, you can expect they put their expertise into it to make it as good as possible.
  - synergy20 3y ago
    make sense,not sure how google feels pushing both kotlin and dart at the same time at the cross platform apps front
    - pjmlp 3y ago
      Internal Google politics, if you go to the Android SDK site there is hardly any mention of Flutter. Jake Wharton has several interesting takes regarding how Flutter was seen from Android team, during his time at Google. https://codingwithtashi.medium.com/the-other-side-of-flutter-dart-8d156cecc05f https://codingwithtashi.medium.com/the-other-side-of-flutter... https://twitter.com/JakeWharton/status/1421139368467632136 https://twitter.com/JakeWharton/status/1421139368467632136
      - synergy20 3y ago
        I recall you can use Android Studio to develop flutter nowadays, no? that seems to me at least they're working together to some extent, after all, flutter does not have an IDE of its own.
stakhanov 3y ago
What would really be interesting to me would be something with a featureset similar to JavaFX, but with a more up-to-date tech stack. But it doesn't look like they're trying to take on that particular task. The compose multiplatform stuff all looks very mobile-first, with desktop a mere afterthought. The components seem like a toy subset of what JavaFX is capable of. It's absolutely crazy, especially if you're not on mac, that you have a choice between JavaFX with an emulated UI and an outdated tech stack, Windows Forms with an insanely outdated tech stack, and everying that Microsoft did after that which lead up to WinUI 3 which comes with a crazy level of instability and a ghosttown of a developer ecosystem.
palata 3y ago
I am really hoping that this kind of projects will get popular and give an incentive to write actual Desktop apps that are thought as Desktop apps instead of bundling a webapp into a browser and shipping them together.
- lesuorac 3y ago
  But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known characteristics?
  - stakhanov 3y ago
    Java Swing Desktop applications solved that problem 20 years ago. Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work. And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy. It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.
    - palata 3y ago
      I never used Swing. Is it much better than Compose for Desktop?
      - stakhanov 3y ago
        There are a lot more controls, and with JavaFX (the next generation of Java UI technology that JetBrains' own IDEs are also based on), you have even more controls (and more powerful ones). Also, those controls are actually the kinds of controls that will get you the most out of using a desktop, rather than this mobile-first stuff, where the limitations of mobile platforms are the defining constraints and they needlessly constrain also what you can do with those toolkits on desktop.
lordofgibbons 3y ago
I hope there's a good distribution story for this with regards to the JVM runtime for desktop applications written with this. I vaguely recall having the right JVM runtime installed on my Linux machine was a huge pain (openJDK vs oracle) and having the right minimum version number. But it has been a few years since I've had to use a Java desktop application. IntelliJ seem to have figured it out, though I think they just ship their own copy of the JVM runtime.
- deleted 3y ago
  [deleted]
diamondfist25 3y ago
Tauri to the rescue?
joshuakcockrell 3y ago
I've been using Kotlin Multiplatform Mobile (KMM) heavily for the past 2 years on my current YC startup. I'm in the process of removing the entire thing. KMM is an alternative to cross platform mobile libraries like Flutter, React Native, etc. The idea is that we could write all of our mobile app's business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. "We only need to write it once!" is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI & Jetpack. In reality, the codegened iOS code gets you 90% of the way there, the but extra 10% is extremely frustrating to work with. Enums (Sealed Classes in Kotlin) get mangled in translation and you lose exhaustive switch statements. Basic data types like Bool and Int get wrapped so you can only access them using additional .boolValue or Int64(..) constructors. Entire companies are being built around solving the pain point of this last 10%: https://touchlab.co https://touchlab.co In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you're using a Kotlin layer -> mangled through Objective-C -> accessed from Swift. It's a confusing decision, as the only iOS teams still actively using Objective-C are legacy apps (like the Twitter app), which seems like the opposite target market for new mobile tech like KMM. Kotlin and Swift are both modern languages, and my gut says the interop between the two would be much better without Objective-C in the middle. Further discussion from Droidcon if you're interested: https://www.droidcon.com/2022/08/01/sdk-design-and-publishing-for-kotlin-multiplatform-mobile-2/ https://www.droidcon.com/2022/08/01/sdk-design-and-publishin... > As you progress beyond "POC" to integrating and shipping real production code, the design of the "SDK surface" becomes more complicated and nuanced (or, possibly, problematic)... An Android consumer can see all the richness of the Kotlin language, but the iOS side gets filtered through Objctive-C into Swift. Much can get lost along the way. P.S. I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app's entire networking/caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way!
- jwells89 3y ago
  If you don’t mind my asking, did the networking bits hook up to native OS facilities or was that also custom (e.g. OkHttp in place of iOS URLSession)? One of the things that’s made solutions like this unappealing to me is how if you include networking in the shared code, you’re forgoing a bunch of platform optimizations on iOS that do things like coalesce requests to occur when the cell antenna is awake and transparently manage multi-connection situations. While it wouldn’t be too much of a problem in a simple one-note sort of app, for a more serious app that made a lot of network calls the impact is significant.

90 points by cvb941 3y ago

I think the most beneficial part is the sharing of logic. With UI, I don't think using skia is the way to go like flutter. But well done to the team and hopefully this continues to grow and see investment.

whoopsie 3y ago
Object lifetime semantics differ, forcing devs to think about non-native considerations on both Android and iOS. For a lot of CRUD apps the savings is minimal for networking / logic layers.

sdflhasjd 3y ago

Good to hear - though I've seen this being deployed a few times now and it seems to have been mature enough for a while. Has anyone really had a chance to use Compose Multiplatform on iOS? I've love to get an an opinion on what "Alpha" really means in this case Most of the projects I've been working on have been about playing it safe by sticking to React Native or MAUI/Xamarin - but they're both kind of getting a little bit behind with Swift UI and Compose now. The constant ritual of writing the same thing twice for 2 mobile platforms must have wasted more developer hours than anything I can really think of.

stefs 3y ago
> The constant ritual of writing the same thing twice for 2 mobile platforms must have wasted more developer hours than anything I can really think of. probably the only thing that wasted even more developer hours was trying to get the same thing to run on two different mobile platforms.
- palata 3y ago
  Damn it! I wanted to say that, but you were faster :-)
sickcodebruh 3y ago
I didn’t realize Compose could now target iOS! That’s exciting. I haven’t written Kotlin or used Jetpack Compose since the before the latter’s 1.0 release but I was very impressed at the time. Kotlin in particular stood out as an expressive, powerful, fun language. Compose had some rough edges but I picked it up, new to Android and Kotlin, and was productive very quickly. I’ll certainly consider Compose Multiplatform next time I have the need.

jamil7 3y ago

Is anyone using this in production? I played around with it a year or two ago, and it was a little rough. I recently built something internal using Rust and UniFFI for a similar purpose. I much prefer Rust's tooling, but it would be nice to not introduce a third language. There is probably a more minimal environment I can use and not need Android Studio installed, but I'm not that familiar with Kotlin or Android development (Swift/iOS/mac day job).

thecupisblue 3y ago
Been using it for a while now in production, both for mobile apps, SDK's and some critical parts of codebase. While it works great, there are some caveats and additional tooling you need for iOS (i.e. if you want to get the pattern matching for sealed classes as enums, you need external tooling). There was some issues with coroutines, but IIRC also solved recently. For tooling, you can use IntelliJ or anything else you prefer, since you don't need all the "Android studio stuffing" until you go directly into Android development. It's just Kotlin + gradle build system. The best thing is Kotlin - a powerful language with great syntax sugar, allowing you to write readable and performant code. Even tho at core it's a JVM language, it is compiled directly into the native language of the platform instead of providing you with a "wrapped JVM". To interact with "native" code, you only write an interface in common code and then implement the actual interfaces in the platform code, allowing you to share the contract across platforms but delegate the details. To allow for running on other platforms, some tradeoffs are made (including the kotlin stdlib which blows up the size among some), but the saved time you get from having only one codebase shared as a library among multiple platforms is insane. The language itself is quite mature, super comfortable to write and missing only two things: Actors, Macros and Unions. Traits would be nice too, okay. Async/await is miles ahead of whatever state the Rust is in currently. Nowadays, my new project choice is: "do I go with Rust or do I go with Kotlin?", esp since now with WASM I can treat Rust as if it was multiplatform (Still, Kotlin is now adding WASM support and recently added WASI). But the maturity, flexibility and tooling usually make the dice fall on Kotlin.
jurmous 3y ago
I have used this in production for both Java and Web targets for a Startup. It did what it was promising although at earlier stage it took some research to make it work and had to adapt to changes. Now the multiplatform SDK is stable and way better documented. The Kotlin Slack community is also quite helpful for whenever you are stuck.

matsemann 3y ago

I have a bit trouble understanding what this is. Does it mean that I have to write my whole webapp or mobile-app in a Kotlin framework for it to give value? Or can I take some of my Kotlin libraries and convert so they're callable from js so I don't have to duplicate certain logic?

sdflhasjd 3y ago
The latter. You write your shared libraries in Kotlin, compile it for multiple runtime targets, then call your Kotlin code from whatever runtime you're using.
tarkin2 3y ago
Write your business logic in Kotlin with Kotlin libraries. Write your UI in Js/Android/iOS.
- jurmous 3y ago
  It is also possible to write the UI in Kotlin cross platform with Compose Multiplatform.
jurmous 3y ago
You can work in whatever way makes sense for you to share code. Kotlin allows you to call native code (JS/C/ObjC/Java/WASM) from Kotlin, or you can call Kotlin functions from native code (JS/C/ObjC/Java/WASM). So you choose on what level you want to create shared code. So it is quite flexible so it is up to you on what level you want to share code. It can either be a low level library, a middle level library. And with maturing Jetpack Compose it is possible to build the whole app including UI multiplatform without leaving Kotlin.

tarkin2 3y ago

I’ve seen this used in a number of mobile shops when they need/want native frontends and to want share business logic, db use, networking etc. (My only gripe is that Kotlin more or less forces you to use IJ and gradle but most are happy with that). It’s been mature for a while now but has never seemed to get much airtime probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs.

palata 3y ago
> probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs. Most mobile companies I know do native Android/iOS development instead of using cross-platform frameworks.
- tarkin2 3y ago
  I'm more wondering why this isn't more popular, at least with this crowd.
  - occz 3y ago
    One reason could be that people have been burned a few times too many by technologies promising the world with regards to cross-platform, and then failing to deliver on their promises. I think KMP could potentially be good enough to fly, but time will definitely tell on that.
    - palata 3y ago
      IMO cross-platform frameworks are "write once, debug everywhere". In my experience: 1. That's not particularly faster than writing native apps, but debugging is much more frustrating than writing native apps. So as a developer, cross-platform sucks, native dev is fun. 2. Desktop and Mobile are fundamentally different, so trying to write one app for both gives the worst of both worlds. Don't do that. 3. The "debug everywhere" part of cross-platform gets worse as the app gets more complicated. So the app is fundamentally getting more and more frustrating for the devs, which... well nobody wants. On the other hand, sharing code (or libraries) between platforms sometimes makes sense. And being able to do that in Kotlin instead of, say, C++ (or Rust, I know) is actually cool.

coldtea 3y ago

Amazing effort. And by that I refer to the feat of writing a huge article without bothering to explain what Kotlin Multiplaform is. "After several years of hard work by the JetBrains team, Kotlin Multiplatform reaches stable with the 1.9.20 release. This is a critical milestone for the platform and ecosystem. Kotlin Multiplatform was first announced at KotlinConf in 2017. Today, after years of work and amazing progress, Kotlin Multiplatform is stable! Along with progress on the tooling and library ecosystem, designating KMP to be stable will significantly increase adoption of the technology. Touchlab has been contributing to the KMP platform since the beginning, and some of our best work is still to come." And so on. From past reading, if I recall correctly it's a native version of Koltin (?) or a version targeted to mobile development for multiple mobile OSes, but can't be sure, nor about what kind of libs work with it (perhaps any?). This helps a little: https://www.jetbrains.com/kotlin-multiplatform/ https://www.jetbrains.com/kotlin-multiplatform/ Still, this page too could do a much better job, instead of selling "what it can do" to manager types: "Open-source technology by JetBrains for flexible multiplatform development" / "The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects." / "Reuse code across Android, iOS, web, desktop, and server-side while keeping native code if needed"), to plainly tell "what it is" to tech types. So, something like: "The shared business logic code for Android gets converted to Java bytecode that can be executed in JVM and Android has the virtual machine, so it can easily run it. But in the case of iOS, there is no virtual machine, so the code is converted to the native code that can be executed on iOS. Now in the Kotlin compiler, there is a frontend that converts the code into an intermediate representation known as IR, and the backend converts that intermediate representation to machine-executable code. So in the case of android, it converts it into java bytecode, and for iOS, it converts it into iOS native machine code." Had to go to a third party website to find this description.

ahmedfromtunis 3y ago
Thanks for the explanation. Unfortunately, this is far from being an isolated case. Very far. I used to play a game on Product Hunt where I'd open multiple links without reading the description on PH, and use the homepages to try to guess what each app does. Most of the time, it simply isn't possible. It was so frustrating that I stopped playing after awhile.

account-5 3y ago

How does/will this compare to dart/flutter?

jurmous 3y ago
Kotlin Multiplatform allows you to work fully native on Android as Kotlin is the main language there. And it also allows to compile to native iOS code and integrate with native iOS Objective-C code or bridge code. (Swift integration is on the roadmap) It also allows you to directly call C code or C libraries. Or it allows to compile to JS and call JS code. So it is more versatile than Flutter and easier to integrate with native code/components. Flutter is more creating its own world with the Dart sandbox and then has to pass messages to communicate with the native world. Kotlin is closer to native output. Jetpack Compose is the UI library and provides a similar mechanic as React/SwiftUI/Flutter in building declarative UIs. It is already the Android default as Google started to develop this UI library and Jetpacks brought in the multiplatform implementation.
- account-5 3y ago
  I thought dart/flutter compiled to native code, on whatever platform it was on. And I thought dart could directly call libraries via it's ffi? I'm no expert so I'm likely wrong.
  - jurmous 3y ago
    If I am correct Flutter compiles to Dart code which compiles to Native code. Above I was more talking about platform integration. As Flutter their own document states everything within Dart is compiled to run like its own enclosed runtime environment. It talks with the native world with messages over channels. https://docs.flutter.dev/platform-integration/platform-channels https://docs.flutter.dev/platform-integration/platform-chann... Within Kotlin however it is possible to directly call the native method. So it looks like Flutter has more overhead for native communication than Kotlin. Here for example a part of a C interop tutorial in Kotlin. You can directly work with data coming from C libraries. https://kotlinlang.org/docs/mapping-primitive-data-types-from-c.html https://kotlinlang.org/docs/mapping-primitive-data-types-fro...

synergy20 3y ago

looks like a Java/kotlin version of flutter to me the doc mentioned desktop and web a little but 98% are about android and iOS I am more interested in cross platform desktop GUI,is this better than gtk or qt or wxwidgets? or swing?

jurmous 3y ago
Kotlin Multiplatform gives the mechanics to compile code to different platforms/targets. So it can compile code to Android, native iOS/linux/windows, web, beta web assembly, java runtimes and more. Compose Multiplatform is the Flutter equivalent. They work on a UI toolkit which compiles to desktop/mobile/web. It works with declarative patterns like Flutter/SwiftUI/React, so is a quite modern implementation to build UIs. So it is possible to build desktop apps. Jetbrains have build their toolbox app as first desktop app since a few years using Compose. It provides many UI elements to build Desktop apps and as Jetbrains itself is a big Desktop app developer, you can expect they put their expertise into it to make it as good as possible.
- synergy20 3y ago
  make sense,not sure how google feels pushing both kotlin and dart at the same time at the cross platform apps front
  - pjmlp 3y ago
    Internal Google politics, if you go to the Android SDK site there is hardly any mention of Flutter. Jake Wharton has several interesting takes regarding how Flutter was seen from Android team, during his time at Google. https://codingwithtashi.medium.com/the-other-side-of-flutter-dart-8d156cecc05f https://codingwithtashi.medium.com/the-other-side-of-flutter... https://twitter.com/JakeWharton/status/1421139368467632136 https://twitter.com/JakeWharton/status/1421139368467632136
    - synergy20 3y ago
      I recall you can use Android Studio to develop flutter nowadays, no? that seems to me at least they're working together to some extent, after all, flutter does not have an IDE of its own.

stakhanov 3y ago

What would really be interesting to me would be something with a featureset similar to JavaFX, but with a more up-to-date tech stack. But it doesn't look like they're trying to take on that particular task. The compose multiplatform stuff all looks very mobile-first, with desktop a mere afterthought. The components seem like a toy subset of what JavaFX is capable of. It's absolutely crazy, especially if you're not on mac, that you have a choice between JavaFX with an emulated UI and an outdated tech stack, Windows Forms with an insanely outdated tech stack, and everying that Microsoft did after that which lead up to WinUI 3 which comes with a crazy level of instability and a ghosttown of a developer ecosystem.

palata 3y ago

I am really hoping that this kind of projects will get popular and give an incentive to write actual Desktop apps that are thought as Desktop apps instead of bundling a webapp into a browser and shipping them together.

lesuorac 3y ago
But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known characteristics?
- stakhanov 3y ago
  Java Swing Desktop applications solved that problem 20 years ago. Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work. And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy. It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.
  - palata 3y ago
    I never used Swing. Is it much better than Compose for Desktop?
    - stakhanov 3y ago
      There are a lot more controls, and with JavaFX (the next generation of Java UI technology that JetBrains' own IDEs are also based on), you have even more controls (and more powerful ones). Also, those controls are actually the kinds of controls that will get you the most out of using a desktop, rather than this mobile-first stuff, where the limitations of mobile platforms are the defining constraints and they needlessly constrain also what you can do with those toolkits on desktop.

lordofgibbons 3y ago

I hope there's a good distribution story for this with regards to the JVM runtime for desktop applications written with this. I vaguely recall having the right JVM runtime installed on my Linux machine was a huge pain (openJDK vs oracle) and having the right minimum version number. But it has been a few years since I've had to use a Java desktop application. IntelliJ seem to have figured it out, though I think they just ship their own copy of the JVM runtime.

deleted 3y ago
[deleted]

diamondfist25 3y ago

Tauri to the rescue?

joshuakcockrell 3y ago

I've been using Kotlin Multiplatform Mobile (KMM) heavily for the past 2 years on my current YC startup. I'm in the process of removing the entire thing. KMM is an alternative to cross platform mobile libraries like Flutter, React Native, etc. The idea is that we could write all of our mobile app's business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. "We only need to write it once!" is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI & Jetpack. In reality, the codegened iOS code gets you 90% of the way there, the but extra 10% is extremely frustrating to work with. Enums (Sealed Classes in Kotlin) get mangled in translation and you lose exhaustive switch statements. Basic data types like Bool and Int get wrapped so you can only access them using additional .boolValue or Int64(..) constructors. Entire companies are being built around solving the pain point of this last 10%: https://touchlab.co https://touchlab.co In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you're using a Kotlin layer -> mangled through Objective-C -> accessed from Swift. It's a confusing decision, as the only iOS teams still actively using Objective-C are legacy apps (like the Twitter app), which seems like the opposite target market for new mobile tech like KMM. Kotlin and Swift are both modern languages, and my gut says the interop between the two would be much better without Objective-C in the middle. Further discussion from Droidcon if you're interested: https://www.droidcon.com/2022/08/01/sdk-design-and-publishing-for-kotlin-multiplatform-mobile-2/ https://www.droidcon.com/2022/08/01/sdk-design-and-publishin... > As you progress beyond "POC" to integrating and shipping real production code, the design of the "SDK surface" becomes more complicated and nuanced (or, possibly, problematic)... An Android consumer can see all the richness of the Kotlin language, but the iOS side gets filtered through Objctive-C into Swift. Much can get lost along the way. P.S. I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app's entire networking/caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way!

jwells89 3y ago
If you don’t mind my asking, did the networking bits hook up to native OS facilities or was that also custom (e.g. OkHttp in place of iOS URLSession)? One of the things that’s made solutions like this unappealing to me is how if you include networking in the shared code, you’re forgoing a bunch of platform optimizations on iOS that do things like coalesce requests to occur when the cell antenna is awake and transparently manage multi-connection situations. While it wouldn’t be too much of a problem in a simple one-note sort of app, for a more serious app that made a lot of network calls the impact is significant.