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

iamcalledrob 3 days ago | parent | next [-]

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.

▲

pjmlp 3 days ago | parent [-]

Yeah, the JVM ecosystem is what makes Kotlin interesting, and the main reason why Google begrudgingly updates Java support, when Android starts to lag behind the current Maven Central trend, currently Java 17.

I agree regarding Gradle, thankfully the time I used to do Android native development is behind me, even if I keep up with Google IO sessions, and ADP Podcast.

How is Kotlin Native maturity nowadays?

	▲	iamcalledrob 3 days ago \| parent [-]
		I've found Kotlin/Native to be fine, but very basic. It's limited due to lack of ecosystem and minimal stdlib, though this is improving. There are things you might expect to be able to do trivially (e.g. formatting a timestamp into a date string) had no off-the-shelf approach last time I tried. You'd need to roll your own, or pull in an existing non-kotlin library, e.g. something from C. I think a lot of issues stem from existing APIs being designed around Java types that will never be available without the JVM.

▲

larusso 4 days ago | parent | prev [-]

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.

	▲	pjmlp 4 days ago \| parent [-]
		With a caveat, Metal is written in a mix of Objective-C and C++, with Swift bindings. Thus you can do anything Metal with Objective-C and zero Swift. Also, writing drivers, even in userspace is still mostly C++. Going on a tangent, even if Swift isn't everywhere still, I would like that Microsoft would be half as serious as Apple, regarding .NET use on Windows, however they aren't even serious with C++.