Beginner questions here. How does a Kotlin compose...

# getting-started

[solvingj]

Beginner questions here. How does a Kotlin compose multiplatform get compiled into a runnable executable for each platform? Does it use Kotlin native under the hood, or is it more like Graalvm where it bakes in the JVM into the binaries? Can one use standard Java libraries in such projects?

[AdamW]

Hey! Your question is less about Compose Multiplatform, and more related to Kotlin Multiplatform in general. Here are some resources on how Kotlin Multiplatform works:
• https://kotlinlang.org/docs/multiplatform.html
• https://kotlinlang.org/docs/multiplatform-share-on-platforms.html
• https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-getting-started.html
The short of it is that you have platform-specific source sets (that may have platform-specific dependencies). These sources are then compiled directly into their respective platforms. So no, you couldn’t use Java libraries when targeting a platform other than the JVM 👍

[ascii]

It's also worth noting that you can't make portable executables. Only installable.

[solvingj]

Thank you both. All the high level marketing material and goals makes sense to me conceptually. However, it’s all too high level and spread around for developers who want to understand some very important toolchain and dependency implications, and compare it to the alternatives. It seems like you pretty much need to invest a day or two setting up a dev environment and creating some project to really see how it’s going to work.

[solvingj]

Maybe one more shot at clarifying the essence of what I want to know. I was hoping UI code written with Compose Multiplatform would be built something like this…
• Andriod -> JavaFX based GUI, Compiled to java bytecode and rendered via JVM
• iOS -> Native GUI, (Bound to UIKit), Compiled via Kotlin Native to a native IOS Bundle
• macOS -> Native GUI, (Bound to Cocoa, or UIKit/Catalyst) via Kotlin Native to a native universal binary
• Windows -> Native GUI (Bound to WinUI) , Compiled via Kotlin Native to native PE binary
• Linux -> Native GUI (maybe bound to GTK), Compiled via Kotlin Native to native ELF binary
But this doesn’t seem like how it works, and there would be challenges to this. Specifically, Kotlin Compose would have to have extremely robust capabilities for doing interop with all 4 of the native GUI frameworks for each platform, and that would be a super tall order.

[solvingj]

So, in the above world, would have expected to be able to use Java libraries for the android stuff and not other platform code. But, since I wouldn’t want that sort of “divergence”, I would probably hope to find “Kotlin native” libraries which support all targets. Is there even a dependency solution for “Kotlin Native Libraries” which work on all platforms?

[solvingj]

And, then assuming such an ecosystem doesn’t exist for Kotlin Native, I would expect to have to write TONS of foundation code myself. Parsers, Network clients, etc etc.

[solvingj]

I’m reading this now: https://kotlinlang.org/docs/native-libraries.html#cinterop-tool-specifics

[solvingj]

Oh right, I remember reading all this 3 years ago.

[solvingj]

Oh wow, scratch that, was 6 years ago!! https://kotlinlang.slack.com/archives/C3SGXARS6/p1513093558000825

[solvingj]

Ahhh, ok found the start of the future: https://libs.kmp.icerock.dev/

[AdamW]

I was just about to ask if you by ”Kotlin Native Libraries” you mean libraries with support for all MP targets 😆

[solvingj]

Yeah, for a minute i was skeptical of the whole premise because i was seeing instructions to publish a multiplatform library to maven central. I wondered: “how would consumers ever distinguish standard java packages from kotlin native ones. This is a terrible idea”. However, I kinda see the plan now which is Ok…. For now, but honestly, i really don’t like it as a long-term strategy.

[solvingj]

Anyway, I’m seeing loggers, a cli parser, DI, datetime, loggers and parsers and database clients and stuff… which is a start

[solvingj]

@AdamW can you comment on my compilation matrix above? What is the actual relationship between Compose multiplatform and Kotlin native compiler, and GUI frameworks? Can it be easily summarized?

[AdamW]

It’s definitely early days still for Kotlin MP, which was stabilized last september, so I agree in that the ecosystem leaves a lot to be desired for still.

[AdamW]

I think your understanding is correct.

Compose is basically ”just*” a regular Kotlin library with support for most (if not all) platforms. In essence rendering happens through a mechanism like your matrix describes, though I don’t remember the specific native UI implementations used on each platform. Your application uses Kotlin/Native (and any respective K/N dependencies) precisely for the platforms you’ve listed.

[solvingj]

Ok thank you so much for that. I should be able to find some references to some of the native gui headers in some project somewhere… which project would that be in?

[AdamW]

github.com/jetbrains/skiko here IIRC

[solvingj]

OK, thanks, that is useful, I know that 2-D graphics is a big use case in GUI programs. And I know SKiA is pretty much the center of that universe. But more than anything else, I’m interested in standard native looking windows with buttons, radios, check boxes, etc. etc. I don’t think SKIA is designed for that. I think it should be in one of the main kotlin repos.
I think this is a start for me tomorrow. https://github.com/JetBrains/kotlin/blob/master/kotlin-native/platformLibs/src/platform/mingw/windows.def

[solvingj]

But again I keep coming back to the feeling that this should not be a difficult question to answer in any way. It should be obvious. When I use “compose multiplatform” to create a main window, by what mechanism is it rendered. It can really only be JavaFX, or native interop… I don’t know what other mechanism exists to do standard windowing.