Kotlin Versions

The JetBrains origin and the M-series prehistory (2010–2015)

Kotlin started inside JetBrains in 2010, led by language designer Andrey Breslav. JetBrains had a specific itch: their own engineers had been writing IntelliJ IDEA and the rest of the JetBrains tool suite in Java for a decade. Java’s slow evolution under Sun and then Oracle — particularly the long delays around lambdas (eventually shipped in Java 8 in 2014) and the lack of practical null-safety — meant JetBrains was paying a daily productivity tax on a language that was no longer evolving fast enough for the work they were doing.

Scala existed and JetBrains evaluated it; the team concluded its compile times and complexity were unacceptable for IntelliJ-scale codebases. The decision was to build their own JVM language — pragmatic, Java-interop-first, IDE-tooling-first, with null-safety in the type system and a smaller surface area than Scala. Kotlin was announced in July 2011; the name comes from Kotlin Island, off St. Petersburg.

The development period from 2011 through early 2016 ran through fourteen Milestone (M) builds — M1 through M14, each a publicly downloadable preview, none with backwards-compatibility guarantees. The community that adopted these early milestones — Square, Pinterest, parts of the Android developer community, JetBrains’ own engineers — gave Kotlin its first real test corpus. Kotlin 1.0 in February 2016 was the formal end of the M-series and the start of the backwards-compatibility commitment.

Google I/O 2017 — first-class Android language

At Google I/O 2017 (May 17, 2017), Google announced first-class support for Kotlin on Android. Until that point, Kotlin had been usable on Android via the JetBrains Kotlin plugin since Studio 1.x, and a small but vocal cohort of Android developers (Square, Pinterest, Basecamp, Trello) had been shipping production Kotlin code. The I/O announcement made it official: Android Studio 3.0 (October 2017) shipped Kotlin first-class — bundled, no plugin install, with templates, code completion, lint, and refactoring across Kotlin and Java sources. (Cross-link: Android Studio 3.0.)

Two pressures drove the call. Oracle v. Google — the eleven-year API copyright case over Android’s reimplementation of 37 Java SE packages — was still active at I/O 2017, and would remain so until the Supreme Court’s fair-use ruling in April 2021. Reducing structural reliance on the Java APIs themselves was a strategic hedge, even if Google ultimately won the case. (See the Java Versions page for the Java-side narrative on the same case.)

The other pressure was developer demand. Kotlin’s reception inside the Android community had been rapidly positive through 2015–2017; Google could either lead the Kotlin transition or be dragged behind it. They led. In May 2019 at I/O, Google announced Kotlin-first — new platform APIs are designed Kotlin-first, new Jetpack libraries ship Kotlin-only, the Android Developers documentation defaults to Kotlin code samples. Java is still supported, but the planning is done in Kotlin.

The Kotlin Foundation

In February 2018, JetBrains and Google jointly established the Kotlin Foundation to safeguard Kotlin’s development as a public, multi-stakeholder project. JetBrains retained primary stewardship of language design and compiler implementation; Google joined as a founding sponsor. The Foundation owns the Kotlin trademark, oversees the language committee that approves breaking changes, and provides governance separate from any single corporate sponsor — a deliberate hedge against the uncertainty around Java’s post-Oracle stewardship that had unsettled the community a few years earlier.

Coroutines and structured concurrency

Coroutines — suspending functions and the structured-concurrency library built around them — were Kotlin’s most consequential addition since 1.0. Shipped as experimental in 1.1 (March 2017) and reaching stable in 1.3 (October 2018), they replaced the RxJava-shaped async stacks that Android and server-side Kotlin had been building on through the late 2010s. The pitch: write asynchronous code in a synchronous style, with cancellation and lifetime built into the type system rather than the convention.

The structured-concurrency design (Roman Elizarov’s lineage) became influential beyond Kotlin. Java itself absorbed similar ideas in Project Loom — virtual threads in Java 21 (September 2023) — though the API shapes diverge (Loom doesn’t require suspend markers; Kotlin does). Apple’s Swift 5.5 (September 2021) shipped a third take on the same problem — async/await, structured concurrency, and actors as a first-class language feature — and went further than either Kotlin or Java in baking thread-isolation into the type system, with Swift 6.0 (2024) making strict-concurrency data-race safety the compile-time default. Three languages, three different starting points, converging on similar ergonomics.

The K2 compiler — a multi-year frontend rewrite

The original Kotlin compiler — retroactively named K1 — was carrying a decade of architectural decisions that had become limiting. Type inference was performant but inflexible in subtle ways. Incremental compilation was approximate. IDE intelligence (Kotlin in IntelliJ / Studio) had to share the same frontend with batch compilation, which constrained both. The team began work on a replacement frontend — K2 — around 2017–2018.

K2 reached publicly testable alpha in Kotlin 1.7 (June 2022, JVM only, opt-in). Beta in Kotlin 1.9 (July 2023). And shipped as the default compiler in Kotlin 2.0 (May 2024) — the deliberate major-version bump signaling a structural change rather than a feature drop. The transition took about five years end-to-end and was the largest investment in Kotlin’s history.

What K2 changed: cleaner internal architecture (FIR — the new intermediate representation — replaces the old PSI-based frontend), faster incremental compilation, smarter type inference (cleaner casts across try/catch and through anonymous-class hierarchies), better IDE intelligence (the analyzer that powers Studio / IntelliJ now uses the same frontend as batch compilation), and a clearer foundation for future language features (context parameters, value classes, multiplatform improvements). K1 remains opt-in for projects that hit edge cases.

Kotlin Multiplatform — from experiment to stable (2017–2023)

Kotlin Multiplatform (KMP) was the answer to a structural pressure on the language: more than half of the Kotlin community was on Android, where Kotlin/JVM compiles to JVM bytecode that runs on the Android Runtime, but the iOS half of the mobile market was unserved. JetBrains had been working on Kotlin/Native (LLVM-based, ahead-of-time compiled to native binaries) since 2017 for exactly this reason. KMP composed Kotlin/JVM, Kotlin/Native, Kotlin/JS, and a Common shared module into a model where one shared codebase could target multiple platforms.

The progression was deliberate: experimental in Kotlin 1.2 (November 2017), refined through KMM (Kotlin Multiplatform Mobile) preview in 1.4 (August 2020), beta on the iOS target through 1.5–1.8, and finally stable in Kotlin 1.9.20 (November 2023). The stable milestone covered Common, JVM, Android, and iOS — the combination most cross-platform projects target. Wasm continues to mature; the JS browser story stabilized alongside iOS.

KMP’s adoption has been measured. It’s a meaningful tool for teams with substantial business logic that benefits from cross-platform sharing — networking, data persistence, business rules — while leaving each platform’s native UI (UIKit/SwiftUI on iOS, View/Compose on Android) to its own platform team. Major adopters include Netflix, McDonald’s, Cash App / Block, Philips, Touchlab. The Compose Multiplatform story (Compose UI on iOS, Wasm, desktop) is a separate parallel push that takes the sharing further into UI; Compose Multiplatform for iOS reached stable in 2024.

Kotlin on the server side

Kotlin’s adoption beyond Android has been quieter but real. Spring Framework 5 (September 2017) shipped first-class Kotlin support — null-safe APIs, Kotlin-flavored DSLs for routing and bean configuration, coroutines integration in Spring WebFlux. Ktor, JetBrains’ own asynchronous HTTP server / client framework, has been a steady alternative. Micronaut, Quarkus, and http4k all support Kotlin-first development. The major JVM frameworks have all opened to Kotlin without making it primary; coexistence is the steady state.

People who actually shaped Kotlin

JetBrains: Andrey Breslav (Kotlin language lead 2010–2020; designed most of the language); Roman Elizarov (current Kotlin lead since 2020; designed the coroutines library and the structured-concurrency model); Stanislav Erokhin (compiler lead); Mikhail Glukhikh (K2 frontend lead); Svetlana Isakova (Kotlin in Action co-author and developer-relations lead); Hadi Hariri (former JetBrains developer-advocacy lead).

Google / Android: Stephanie Cuthbertson (Android developer experience leadership during the Kotlin-first turn); Florina Muntenescu, Romain Guy, and the Jetpack team (Kotlin-first API design across Jetpack Compose and the rest of the Android KTX surfaces).

Community: Jake Wharton (Square; one of the earliest production Kotlin advocates; libraries that shaped the ecosystem — Retrofit, Okio); Egor Andreevich (Kotlin/Native lineage); Donn Felker, Antonio Leiva, and the Kotlin-on-Android book / blog circuit that brought Kotlin to mainstream Android developers in 2016–2018; Touchlab’s Kevin Galligan (longtime KMP advocate). Conferences: KotlinConf (annual since 2017) is the canonical venue.