How did we start?

Our adoption of Kotlin started through the recognition of “pain points” that we experienced on a regular basis. During code review, comments like this started to crop up often:

“this 10 line block could be done in 3 lines using Kotlin”

“it would be great here if we could avoid checking for null in 4 different places”

Having experimented with Kotlin outside Udacity, we knew the language might help us solve these problems and build better Android apps. Because of this, it wasn’t long before we had our first Kotlin PR

A small feature was implemented in Java, and a pull-request opened; but along with that PR another was created that provided the same feature; only written in Kotlin. The Kotlin PR wasn’t merged in that instance, but it demonstrated that we could easily integrate Kotlin into our existing app without compatibility issues or a slowdown in development time.

That was the jumping off point. We decided we would migrate a single, small feature in the app to Kotlin and see how it did in production.

We started by migrating our Settings screens in a separate develop branch. This branch received a lot of internal testing while we evaluated closely for 2 types of issues:

Usability issues: what impact did Kotlin have on crashes/bugs? Development process: did Kotlin cause CI issues, slow down our build, or slow down feature development?

When nothing arose, we shipped the new Kotlin feature to users and crossed our fingers. Thankfully, as we expected, no major issues were found. We were now happily using Kotlin in production.

After that, we slowed down a bit. We loved using Kotlin, but recognized the potential risks of going all-in on an unofficially supported language. We continued to add/convert some tests to Kotlin, but no new feature code was using it.

Then Google announced support for Kotlin as a first-class language for Android development.