alt Hacker NewsKind of, because this always has to go via JNI in the end, given that 80% of the API surface is only exposed via Java.
These efforts are always to celebrate, however they always end up with leaky abstractions.
Just like on the other way around one needs to be aware of Objective-C for success, or .NET/COM on Windows.
Replies
larusso • yesterday at 8:05 AM
The fun part is that now you need to bind against swift and objective-c for success on Apple systems. They no longer provide obj-c frameworks for all the new things. So you have to double hop and deal with both or deal with it on a framework by framework level. Talking from a Unity background here where the interop with obj-c is kinda smooth due to the c# -> c marshaling. But swift needs a bit more work.
➕ show 1 reply
The reverse -- building for iOS in Kotlin -- is an interesting option that on the surface appears to be a best of both worlds.
You get (1) access to JVM APIs as normal on Android, and (2) Fairly full-featured interop with ObjC, Swift and C APIs elsewhere, and (3) A pleasant language with excellent IDE support in IntelliJ.
The `expect fun` / `actual fun` stubbing for different platforms also works in a fairly low-drama way. You can also share UI with Compose Multiplatform (less mature), or just write native views.
The downside (of course) is that non-JVM targets like iOS can't use the JVM ecosystem, and most of the Kotlin ecosystem assumes Kotlin/JVM. This is slowly changing though, and isn't a structural flaw.
Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.