Dev Logs / 6 min read

Kotlin 2.4.0 Is Out — Here's What Actually Changed for Android Developers

#

Kotlin 2.4.0 just dropped, and this release is more than just housekeeping. Several features that have been experimental for a while finally graduate to Stable, and a few new ones are worth paying attention to — especially if you're working with Kotlin Multiplatform or care about API design.

Let me walk through what matters.

Stable Features: No More Opt-In Required

The biggest theme in 2.4.0 is features graduating from Experimental to Stable. These are things you could technically use before but had to explicitly opt in with compiler flags. Now they just work.

Context Parameters

Context parameters have been in preview since Kotlin 2.2.0. They're now Stable — with two exceptions (context arguments and callable references, both still Experimental).

If you're not familiar, context parameters let you declare implicit dependencies on a function without threading them through every parameter:

context(logger: Logger)
fun processData(data: String) {
    logger.log("Processing: $data")
    // ... actual logic
}

This is cleaner than passing the logger everywhere, and avoids the "God object" pattern where you inject a massive dependency container just to get one thing out of it.

Explicit Backing Fields

Also now Stable. This one is useful when you need separate internal and public representations of a property:

class UserRepository {
    val users: List<User>
        field = mutableListOf()  // explicit backing field, mutable internally
        get() = field.toList()   // exposed as immutable
}

Previously you'd work around this with a private _users variable and a public users property — the classic underscore pattern. Explicit backing fields make this cleaner and more intentional.

New Language Features Worth Watching

Collection Literals (Experimental)

This one is interesting. You can now create collections using [] syntax:

// Before
val shapes = mutableListOf("triangle", "square", "circle")

// After (with -Xcollection-literals)
val shapes: MutableList<String> = ["triangle", "square", "circle"]
```

Still Experimental — you need to opt in:

kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xcollection-literals")
    }
}

It also supports nested literals and custom types via operator fun of. Useful for matrix-style initialization or DSLs. I wouldn't use this in production yet, but it's fun to play with.

Explicit Context Arguments (Experimental)

This builds on Context Parameters. The problem it solves: when you have two overloads that differ only by their context parameter, the call site becomes ambiguous. Now you can explicitly specify which context you mean:

class EmailSender
class SmsSender

context(emailSender: EmailSender)
fun sendNotification() = println("Sent email")

context(smsSender: SmsSender)
fun sendNotification() = println("Sent SMS")

context(email: EmailSender, sms: SmsSender)
fun notifyUser() {
sendNotification(emailSender = email) // explicit — no ambiguity
sendNotification(smsSender = sms)
}
```

Clean resolution of what would otherwise be a confusing compiler error.

Improved Compile-Time Constants (Experimental)

Kotlin is expanding what counts as a const val. You can now use:

• Unsigned type operations
• Standard library string functions like .lowercase(), .uppercase(), .trim()
• .name on enum constants

const val TAG = "MyFragment".lowercase()  // now valid at compile time

Opt in with -Xintrinsic-const-evaluation. This reduces the need for workarounds when you want truly compile-time string constants.

@IntroducedAt for Binary-Compatible API Evolution

This is specifically useful if you're maintaining a public library or SDK. The problem: adding a new optional parameter to a function breaks binary compatibility.

With @IntroducedAt, you mark when a parameter was introduced and the compiler generates the necessary hidden overloads automatically:

@OptIn(ExperimentalVersionOverloading::class)
fun Button(
    label: String = "",
    color: Color = DefaultColor,
    @IntroducedAt("1.1") borderColor: Color = DefaultBorderColor,
    @IntroducedAt("1.2") borderWidth: Int = 1,
    onClick: () -> Unit
)

No more manually maintaining deprecated hidden overloads. This is a big quality-of-life improvement for SDK authors.

Standard Library Updates

UUID API is Now Stable

The kotlin.uuid.Uuid API is now Stable. No more opt-in for the core UUID operations — generate, parse, compare, and convert. Only the V4 and V7 generation functions are still Experimental.

val id = Uuid.random()
val parsed = Uuid.parse("550e8400-e29b-41d4-a716-446655440000")
println(id > parsed)  // comparison works

Good news for anyone generating device or session identifiers in multiplatform code.

.isSorted() and Friends

New extension functions for checking sort order on iterables, arrays, and sequences:

val numbers = listOf(1, 2, 3, 4)
println(numbers.isSorted()) // true

data class User(val name: String, val age: Int)
val users = listOf(User("Alice", 24), User("Bob", 31), User("Charlie", 29))
println(users.isSortedBy(User::age)) // false
```

Simple, stops early on the first out-of-order pair, and readable. I've written this helper function manually more than once — glad it's in stdlib now.

New Map Fallback Functions for Nullable Values

Maps with nullable values have always been a bit awkward. If map["key"] returns null, you don't know if the key is missing or if it was explicitly stored as null. Now there are explicit functions for each case:

val cache = mutableMapOf<String, Response?>("user" to null)

// Replaces null value (treats null same as missing)
cache.getOrPutIfNull("user") { fetchUser() }

// Keeps null value (only fills if key is truly missing)
cache.getOrPutIfMissing("user") { fetchUser() }
```

This is exactly the kind of semantic clarity I want when building caches. Still Experimental — needs @OptIn(ExperimentalStdlibApi::class).

Kotlin/JVM: Java 26 Support

Kotlin 2.4.0 can now generate bytecode targeting Java 26. Straightforward upgrade if your project is moving to the latest JDK.

Also, annotations in metadata are now enabled by default. This means annotation processors and tools can read annotations at the metadata level without reflection. If you're building or using annotation processors, this is a meaningful improvement in how they can work with Kotlin-compiled code.

Kotlin/Native: CMS Garbage Collector is Now Default

The Concurrent Mark and Sweep (CMS) GC is now the default in Kotlin/Native. Previously the GC had to pause app threads during the marking phase. CMS runs marking concurrently with the app, which means shorter pause times and better responsiveness — especially visible in UI apps.

If something breaks, you can roll back:

# gradle.properties
kotlin.native.binary.gc=pmcs

Also worth noting: Swift export is now Alpha, LLVM updated from 19 to 21, and minimum Apple target versions have been raised (iOS/tvOS: 15.0, macOS: 12.0, watchOS: 8.0).

What This Means From Where I'm Standing

A few things I'm paying attention to with my current projects:

Context Parameters going Stable is good news for the CMP migration. It opens up cleaner DI patterns that work across Android and Desktop without relying on platform-specific injection frameworks. I've been experimenting with replacing some Koin boilerplate with context parameters in non-critical paths.

CMS GC as default — for Kotlin/Native targets in KMP, this should improve UI responsiveness without any code change. Worth keeping an eye on after upgrading.

@IntroducedAt — not immediately relevant for internal apps, but very useful if any internal SDKs ever get extracted as shared libraries.

.isSorted() family — small thing, but it's the type of stdlib addition that quietly removes a dozen lines of utility code scattered across projects.

How to Update

// build.gradle.kts
plugins {
    kotlin("android") version "2.4.0"
    // or kotlin("multiplatform") version "2.4.0"
}

Or just update IntelliJ IDEA / Android Studio to the latest version — it ships with Kotlin 2.4.0.

Bottom Line

Kotlin 2.4.0 is a solid release. It doesn't have one massive headline feature, but it moves the language forward in a consistent direction: better API evolution tools, cleaner implicit dependency handling, and a more complete standard library.

The graduation of Context Parameters and Explicit Backing Fields to Stable is the most practically impactful change for day-to-day Android/KMP development. Everything else is incremental but useful.

Worth upgrading to. No major breaking changes reported so far.

Source reference: What's new in Kotlin 2.4.0 — Kotlin Documentation