DEV Community

Cover image for Kotlin on Android: Not a big surprise, actually

Posted on

Kotlin on Android: Not a big surprise, actually

Google finally announced first-class Kotlin support for Android! 🎉🍾🎊
Some of us knew that this would happen one day and we can now safely say "Told ya!".1

However, not all people were so sure about this.

It was last year around April, when a co-worker posted an article in our company's Slack that "Google is said to be considering Swift as a ‘first class’ language for Android".
I was curious, so I immediately read the article. Not only was I curious, but I was also skeptical. It turned out, I was right to be.

While Swift is definitely a great language, something felt off. I thought "why not Kotlin?".
Those of us who were already playing with Kotlin, or even used it in production, knew of the benefits and it's ease of use.

Despite the article's title, the article quickly got to the point where it stated that using swift was actually too complicated:

"Android would need a runtime for Swift"

"Google would also have to make its entire standard library Swift-ready"

"Swift would also not be useful in bridging higher level APIs in Java"

So my suspicion is that the author picked "Swift" for the headline because it would generate more clicks than "Google considers other languages than Java".

Some of my co-workers (iOS developers, obviously 😉), where sold anyway:

"I saw a talk at the local cocoa heads. The guy showed us how to run Swift on Android."
"Oh, that's interesting. How did he do it?"
"I don't really know, I think something with native bindings"
"He used the NDK? That's not really convenient, isn't it? It's also kinda slow."
"Maybe but you can now use Swift on Android! So we only write our model once and use it everywhere! Also, when Foundation is ready, you won't even need Retrofit and these things anymore!!!!111!"
"Dude, du you even know what Retrofit is? Also, Kotlin has more or less the same features as Swift, but works out of the box..."
"Doesn't matter, Swift is better!"

Ok, maybe I'm exaggerating here and the conversation was actually more civilized, but that's what it has become in my memory 😜.
The point is, even back then, Kotlin was already the better choice for Android.
Kotlin has always been developed with Android in mind. In my opinion, it was made for Android development:

  • It compiles to Java 6 compatible bytecode
  • It's 100% inter-operable with existing Android- and Java- APIs
  • The Android framework relies heavily on null - and Kotlin makes dealing with it more safe.
  • Delegates like lazy or the lateinit-keyword make it more comfortable to work with e.g. the Android Resources class.
  • Lambdas can be inlined to gain performance.
  • Extension functions help us add functionality to Android framework classes without reflection or subclassing.
  • Extension functions are resolved statically, which may also benefit performance.
  • The Kotlin runtime is (compared to how powerful it is) really small - only about 7000 methods and 1MB.
  • Dagger, Butterknife, Android Databinding and other libraries commonly used by Android developers run smoothly with little extra configuration.
  • A lot of libraries are already taking Kotlin into Account (or were made for Kotlin), e.g. Rx Binding or Anko
  • You don't need to choose between Java and Kotlin - you can use both in the same project!

The article continues with arguments of why Kotlin is probably not going to be Google's language of choice.

Well actually, the only argument against Kotlin the article mentions is "that Google’s current mindset is that Kotlin is a bit too slow when compiling.". Which sounded ridiculous to me: at that time our Android team had build times of 2 minutes at max, while iOS struggled to get their build times below 15 minutes.

The other "argument" seems like plain ignorance to me:

Though Kotlin is an alternative, it’s a very nascent language without the eager community Swift has.

I have no idea how anybody who ever took a glimpse at Kotlin could call it "nascent"2 (if the author actually used it, it's even more weird to write something like this), especially if you consider that it was already in 1.0 for more than a month during the time the article was published.
The point with the community might be true though, but I doubt that Swift's community would be as eager if Apple wouldn't embrace Swift themselves.

Swift is a really nice language, but it's not the right choice for Android development.

At Google i/o 2017, Google took the right step by making Kotlin an officially supported language of the Android platform.
Every CTO who feared the adoption of Kotlin for Android can now rest assured: your developers knew what they were doing.

The surprise isn't that Kotlin is now officially supported, the actual surprise was that it took so long for Google to embrace it.

1 I originally drafted this article as "Swift on Android is not gonna happen", but then Google i/o crossed my plans 😅. This post is not supposed to be a rant or show how great I am because I anticipated this. It should simply highlight why Kotlin is the better option.

2 I understand "nascent" as in "too small to be taken serious" here, because it's used as an argument against Kotlin.

The cover image was created with the JetBrains Artwork creator

Top comments (3)

r_mirabelli profile image
Russell Mirabelli

At least as interesting as the choice for Kotlin on Android is the emergence of Kotlin Native. It's only just under development, but having Kotlin target LLVM directly may mean that we're able to create business logic and domain models in Kotlin and share that code across platforms (in a way that's much less troublesome than using C++ as a cross platform language).

This is something I'll be tracking for my own teams over the next year.

lovis profile image
Lovis • Edited

Yeah, I am also really looking forward to Kotlin native!

However, we need to be careful not to tell our Swift friends "Kotlin is better!!!111" 😉

dean profile image

I'm super excited for Kotlin Native! I've been using Kotlin for a while now. Wondering how much it's going to differ from JVM.