[mwcampbell]

Kotlin Native is exciting. But there's another way to run JVM languages, including Kotlin, on iOS: the open-source Multi OS Engine (https://multi-os-engine.org/), which basically brings ART (the Android Runtime) to iOS. Note: It doesn't bring the Android UI toolkit, or any cross-platform toolkit, to iOS, so you have to write UI code for iOS. But I think that's as it should be.

Of course, there's a trade-off between Kotlin Native and Multi OS Engine. Kotlin Native is a lighter runtime. BUt with MOE, you can use arbitrary libraries that target the JVM (well, the JVM subset that works on Android). So MOE makes a lot more existing code available for iOS. For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

This space is going to be interesting to watch over the next little while.

[hota_mazi]

The Multi-OS engine has a much narrower scope than you describe: really just write apps on Android and run them on iOS.

It's not a way to run a JVM language and certainly not a way to generate Kotlin code for native targets.

Kotlin Native is very exciting because it's a potential threat across the board: not just to run iOS apps written in Kotlin, but also to generate native code from Kotlin in back end system, a domain that's currently heavily contested by both Go and Rust, and also to write Kotlin and generate Web Assembly.

It's going to be a very interesting next lustrum.

[kodablah]

> For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop.

Or someone writes a bridge between native Kotlin code and AOT'd JVM code. Or someone writes a kind of reverse compiler from JVM bytecode to Kotlin. Not sure how practical either is due to sheer JRE stdlib size.

[peoplewindow]

Look at SubstrateVM. It's capable of making fully stripped AOT compiled binaries with a bundled JVM that only use the parts of the JRE library that are needed. Sort of like what Go can do.

[kodablah]

Yup. There is also jaotc coming along. Regardless, to use a them from Kotlin Native would require bridging between the two.