Last week at Google I/O, the Android team announced that Kotlin is now an officially supported language for Android development. This is good. Very good.

When Apple launched Swift in 2014, it raised a big question: when will this young language be ready for prime time? In contrast, Google’s announcement of support for Kotlin actually reduces uncertainty: Kotlin has proved itself a capable and relaible language for Android development in recent years. The question about Kotlin has long been: is this going to be the language Google puts its official weight behind? Thankfully, we now know that the answer is yes! You can take it to the bank – which we intend to do.

Yes that’s right, we’re throwing the doors open: Kotlin is now our first-choice development language for new Android projects. We’ve been building various smaller projects in Kotlin over the last year, and while it’s a great improvement over Java, it’s been hard to guarantee that this scrappy new language isn’t a flash in the pan. Thankfully that era is over, and Google’s commitment to the language gives us the confidence we need to go all in.

Kotlin and Swift, sitting in a tree

Not surprisingly for a new language, Kotlin has a ton of advantages over Java due to its modern language features, along with a cleaner, clearer syntax that’s still familiar to folks who know the Android system APIs.

What’s less obvious but exciting here at Steamclock is that Kotlin is a lot like Swift. While there are surely differences – for example Swift’s performant value-typed structs aren’t generally available in JVM-based languages like Kotlin – there is a ton of overlap with Swift’s language features and basic syntax choices. A developer who is comfortable with Kotlin or Swift should be able to get comfortable in the other quite quickly.

Looking at just one example, Kotlin has a feature that Swift has taught us to very much appreciate: nullability. In both languages, the type system will not by default let a variable be assigned a null value. If you want a variable to be nullable, you need to mark it as such, and then the complier will ensure that you handle what happens if that variable turns out to be null at runtime.

While nullability seems at first to be a complication, a burden of sorts, it is a mental shift that once made, produces substantially more reliable code. It’s incredible how many failures that occur in production code – both server-side and app-side – that boil down to an unexpected null value. Being able to categorically remove these bugs gives us a big leg up in reliability, and fewer fires to fight down the road.

Of course, nullability is just one of the modern features that Kotlin and Swift bring to the table. So, here’s to cleaner, clearer, safer code – on iOS and now on Android.