KMM (kotlin multiplatform mobile) just hit Beta status. Its a really unique value proposition compared to other cross platform options in that it doesnt run via a VM (either Javascript or e.g. Mono for Xamarin). It compiles to native LLVM on ios, and as such you can write your UI natively if you want.

I was holding off on KMM before, but I've started looking lately and its extremely promising. There is still a lot of ecosystem that needs to be built out (e.g. you need to find cross platform / pure kotlin implementations of URI or Color), but it is shaping up to be the leader in the space IMO.

Why would anyone use it if you can’t take advantage of the vast Java ecosystem? Why would I choose it over Graal for example, which has much bigger backing, stable and is language-agnostic.

You can take advantage of Java in the next layer up, but you lose out on sharing that portion of code/logic then.

There are actually 3 layers in play for each platform: The pure kotlin shared layer, the "native" kotlin shared layer, and the native-native layer. That second layer (the native kotlin shared layer) is platform-specific kotlin. So on JVM platforms thats the normal Kotlin you are used to, and as such it has access to Java. On iOS that second layer is Kotlin/Native, and you actually have access to native _bindings_ to the native layer (i.e. I can call into UIKit, but in Kotlin code). If you put your "native" code in the second layer instead of the native-native layer (which on iOS is Swift/objective-c), then you can move that into the innermost layer if/when it makes sense over time, and the frontend is none the wiser.

Here is a good visual and explanation (the rest of the presentation is a good overview as well, but I think this slide is the best part of the video): https://youtu.be/2yd6rVJdICU?t=1749

EDIT: I should also note that nothing prevents you from creating "glue" bindings in the pure kotlin layer using either expect/actual or an interface, and then reifying that using some JVM thing in the second layer, and writing the other platforms more from scratch to fulfill the contract.

  > I can call into UIKit, but in Kotlin code

just a note for those who've never used kotlin native: its generating obj-c code when compiling for ios, so you cant use any swift-based apis that arent exposed to objc from apple

uikit isnt going anywhere for a long time probably, but its an important caveat

Right, I forget to mention that. But if you are in the cross platform space thats just how they all work (that I've encountered at least). The difficulty of consuming Swift in Objc vs the other way around means that lots of iOS libraries are Objc based, but Apple is starting to signal that it might be over sooner than later as they begin to introduce new Swift/SwiftUI-only subsystems. Or maybe they have an ace up their sleeve with exposing those in the Objc space. Doubt it.

EDIT: and a nitpick. Its not generating any objc code. Its generating a binary which is exposed to swift using the same mechanisms that objc libraries use. I.e. it compiles to a native binary (an xcframework or framework, I forget which). It doesnt transpile.

  > Its generating a binary which is exposed to swift using the same mechanisms that objc libraries use. I.e. it compiles to a native binary (an xcframework or framework, I forget which). It doesnt transpile.

right, though the native library (xcframework) exposes its interface as objc objects (.h header files), since swift only knows how to read c and objective-c modules afaik...

Well there is kotlin-native which allows you to write kotlin libraries that compile to IOS and Android. Which you can than link to objective C or flutter based UIs. Or even react native. That allows you to share a lot of code between different platforms. A growing number of Kotlin libraries are multi platform meaning you can use them on IOS, the JVM, and in browsers.

Java doesn't have that and it's kind of an increasingly dead language for mobile development. Some older android projects still use it. But Meta is late to the game of migrating away from it. Many companies did that years ago and the vast majority of new Android applications is using either Kotlin or Flutter/Dart.

I have good hopes for Jetbrains extending the jetpack compose/compose desktop/compose web ecosystem to IOS at some point as well. That would create some interesting possibilities in terms of targeting just about any platform with kotlin from a single code base. It's a logical next move for them and they've been laying the groundwork with their multi platform compiler strategy for a while now.