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.