[kennywinker]

Two points for using Swift on Android: 1) shared code between your ios, mac, and android apps. 2) you already know swift.

That said, there is always a cost to using a non-standard language to develop for a platform. Things like having to translate documentation as you read it, friction between system libraries and your languages standard library, etc.

I've not looked at Kotlin in detail, but I wonder how much that friction is reduced because it's java-based, or if you'll experience just as much friction using Swift on Android as you would using Kotlin on Android. Worth evaluating if you're starting a project 6 months to a year from now as the Swift tooling for Android starts to mature.

As it stands now, I would have a look at Kotlin, but almost definitely write any projects started today in Java. Swift is nowhere near ready, and the advantage of writing in the platform's "native" language usually outweighs any benefits there are to using a "better" language.

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

[izacus]

The alternative of course being C++14 with first party support for each OS out there and maturer ecosystem.