Kotlin 2.4.0 Release: Re-architecting Kotlin Multiplatform for Modular Systems

Host: Hey everyone, welcome back to Allur. I’m your host, Alex Chan. Now, if you’ve been following the show for a while, you know we spend a lot of time diving into the back-end with Go or looking at the latest in Laravel. But today, we are shifting our focus to the mobile and multiplatform world because something huge just happened. Host: Joining me today to help navigate these waters is Marcus Thorne. Marcus is a Lead Mobile Architect at Hexa-Tech and has been a KMP advocate since the very early alpha days. He’s seen the good, the bad, and the very messy when it comes to sharing code between Android and iOS. Marcus, it is so great to have you on Allur. Guest: Thanks so much for having me, Alex! It’s a really exciting—and honestly, slightly relieving—time to be in the Kotlin ecosystem. I think a lot of us have been waiting for this specific architectural shift for a couple of years now. Host: "Relieving" is a strong word! I love that. So, let’s jump right in. The headline for 2.4.0 is this shift from a "single-module" approach to a "shared-library model." For those who haven't been deep in the KMP weeds lately, what was the "old way" and why was it starting to break for teams? Guest: Yeah, so, in the early days—and even up until this release—the standard advice was: "Put your shared logic in a module called `shared` or `commonMain`." And that works... at first. But I’ll give you a real-world example from a project I worked on last year. Host: Oh, wow. So it basically became the exact thing we try to avoid in backend microservices, just shoved into a mobile app? Guest: Exactly! It was a monolith in disguise. And actually, the biggest struggle was that it made the build times atrocious. You’d change one line of logic in a domain model, and KMP would spend five minutes figuring out what that meant for both Android and iOS. Host: So, how does Kotlin 2.4.0 actually fix that? What does this "shared-library model" look like in practice? Guest: So, the core change in 2.4.0 is that the project structure now defaults to being modular. Instead of one big `commonMain`, the tooling now encourages you to define distinct shared libraries—like `shared-feature-auth` or `shared-feature-payment`. Host: Interesting! So, it’s almost like we’re building a suite of internal libraries that the Android and iOS apps just "consume," rather than one giant blob of code? Guest: Precisely. And that’s the "aha moment" for a lot of teams. It allows different teams to own different parts of the shared code. One team can own the "Core Domain" library, and another can own the "Analytics" library. They evolve independently. Host: I was looking at the release notes, and I saw a mention of Java 26 support. Now, for the mobile folks, we’re often stuck a few versions behind on Android, but how does this impact the wider KMP ecosystem? Guest: Actually, it’s huge for the server-side and desktop folks using Kotlin. By supporting Java 26, KMP ensures that if you're running shared code on the JVM, you're getting the latest performance optimizations and language features. It keeps KMP relevant for enterprise environments that are moving fast. Host: Oh! I saw that. Wasm is becoming such a big player. Why is incremental compilation such a game-changer there? Guest: Okay, so, previously, if you were using KMP to target the web via WebAssembly, every time you changed a single character in your Kotlin code, the compiler would often have to re-process the *entire* project to generate the Wasm binary. It was a massive feedback loop killer. Host: That’s a massive jump. It feels like JetBrains is really trying to erase the "friction" of multiplatform. Guest: That’s a great question, and actually, it’s where this modularity helps the most. When you have one giant monolithic framework being exported to iOS, it’s a black box. It’s hard for the iOS team to see what’s inside. Host: I love that phrasing—sharing the "brain" but keeping the "body" native. Guest: (Laughs) Well, migrations are never *totally* painless, right? But the Kotlin team has actually made the Gradle changes pretty logical. My advice? Don't try to refactor everything at once. Start by identifying your most "stable" code—usually your data models or your basic utility functions—and pull those out into their own shared module first. Host: It sounds like it’s finally giving us the tools to treat mobile architecture with the same rigor we use for backend systems. Guest: Exactly. We're moving out of the "experimental" phase of KMP and into the "industrial strength" phase. It’s really cool to see. Host: It really is. Marcus, thank you so much for breaking this down. This move toward a "shared-library" model feels like a massive step forward for the whole ecosystem. Guest: My pleasure, Alex! Always happy to talk Kotlin. Host: For everyone listening, if you want to see the code snippets Marcus was talking about, or check out the full release notes for Kotlin 2.4.0, we’ll have all the links in the show notes at Allur.tech.