[on_and_off]

>friction between system libraries and your languages standard library

Well, that's the thing : Kotlin emits bytecode. It is entirely interoperable with Java. All the Java APIs of the platform are accessible in Kotlin.

Swift on the other end can only target the NDK, which limits it to a very specific niche on Android.

[kennywinker]

Just because they are accessible, doesn't mean using them is seamless. For example all of Objective-C's runtime and classes are available to Swift but there is some friction e.g. methods that emit untyped NSArrays rather than typesafe swift arrays, or cases where you have to avoid using Swift structs because they can't be passed into the Objective-C runtime. Apple's done a lot of hard work, and each release of Swift has made this better, but it's still not entirely without hiccups... without having used Kotlin, I can't say for sure, but I would guess there are some analogous issues.

[on_and_off]

So far, it seems pretty seamless. I guess that with a couple of years working on a production app in Kotlin, I would have to discover some hairy corner cases though.

What helps a lot is that the kotlin team has written many helper methods allowing a better flow between the android API and kotlin code : while you don't need it in order to get interop, it allows to more easily write idiomatic kotlin code while interacting with Android.

[drdaeman]

I haven't ever wrote an Android app (just toyed around and patched a few projects, but never had an idea and a necessity to do a full one from scratch), but what's the limitation here?

Can't a native library call just anything from the Android/Java world?

I mean, NDK library has JNIEnv* pointer and it can call FindClass/GetMethodID/Call*Method. And it can create objects/functions if it needs to be called back. Of course this isn't fun in the raw form, but don't see any reason it can't be well sugared.

[izacus]

You don't gain anything except a huge debugging pain and a large loss of performance. Debugging JNI and performance loss of translation makes not using JVM downright madness.