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