Kotlin CLI, Kotlin 2.4, KMP Changes & More - KotlinConf 2026 News Special

Added: 2026-05-27

[00:00:00]Hey guys, and welcome back to a new episode of Mobile Dev News. This time a special episode for KotlinConf. So, I just made one for Google IO for most of the Android changes and the the the Google ecosystem changes. But, KotlinConf in Munich here was at about the same time where I also attended. And that is why I want to make a separate video here just summarizing the most important changes that were announced on KotlinConf to the Kotlin ecosystem, be it for the Kotlin language, for Kotlin multiplatform, Compose multiplatform, or any tooling around that. So, let's dive into it. First of all, Kotlin 2.4 has been announced with some cool changes.

[00:00:37]It summarizes this here. So, on the one hand, we have certain language features that are now stable. Context parameters, we already had that. I already covered that in a video. Explicit backing fields, so this is very cool for all Android developers among you, in general, of course, for all Kotlin projects. But, in Android we very often have these, you know, view models, private mutable state flow, public immutable state flow. This now gets easier with explicit backing fields since you only need one field that way.

[00:01:03]Better defaults for annotation targets.

[00:01:05]This is in the end about this new all annotation. So, you could in the end apply certain annotation to all different parts of a field in Kotlin.

[00:01:13]So, to the constructor field, to the actual property, to the getter, to the setter, and so on. But, the cool things are about the new updates and experimental things that are now part of Kotlin 2.4. And what they've announced are multi-field value classes. So, in the end a value class in Kotlin is something that already existed. And it's a way for you to package a certain primitive value into a type-safe wrapper that serves as the value class. So, for example, you could have a value class called kilometer, and then you have a certain number of kilometers that you want to represent and in form of a float, of a double, or whatever. Because an amount of kilometers is in the end nothing else than a floating-point number, which you could represent as a float. But, by wrapping this into a kilometer value class, you make it explicit that when passing an instance of this kilometer class, you are really being explicit about passing a kilometer and not maybe a centimeter value some kind of arbitrary or negative value. And these kinds of rules you can enforce with a value class which has already existed. But now these value classes support multiple fields, so multiple primitives as part of the same constructor of the value class. So rather than having something like a kilometer class now, you could actually make a distance value class where you then have a certain value in form of a floating point number, but also maybe a type. So which specific unit of distance you're talking about? And this could be kilometer, centimeter, mile, inch, whatever, but only those two fields together actually make sense in order to represent a distance. And you still get all the advantages from value classes that way. So when a function then needs a certain distance and as an input, you can pass an instance of this value class, but under the hood, depending on how the class is structured, it will really just be treated like the plain primitives that may be inlined depending on the class body of the value class. So that is a very cool change. We then have name-based destructuring, which is in the end about destructuring data and value classes by name. So the destructuring is where you instantly destructure the fields from a data class inside variables. And up to this point, this has always worked by order. The first field of a Kotlin data class will become and will be mapped to the first variable of the destructuring part. This can be very brittle because if you accidentally change the order of the data class parameters, this will break the destructure parameter silently. And this is why they are now making name-based destructuring a thing so that the variables will simply get mapped by name and not by order anymore. Rich errors is this new Kotlin feature where you can be very explicit about which errors a function could return by using this pipe after the return type. Um so you could say, "Hey, a function actually returns a list of users. In case everything goes wrong, make a pipe and say, 'Okay, if if there is an issue, this is the type of error it will return. Collection literals, also pretty cool feature here. This in the end just a way for us to do do something like this. Val list is equal to 1 2 3. So, this is how we can construct a list in future in Kotlin without needing this list of function.

[00:04:08]Pretty cool little change. And locality and lifetimes, that's a bit more advanced, but in the end in Kotlin we often have these local scopes where a certain variable is valid in. So, for example, if you have the string builder function to build string one, then this, the Kotlin this keyword, references the string builder. And up to this point, it could actually escape the scope where the string builder would be valid in.

[00:04:31]And the locality and lifetimes actually is a feature that will be able to prevent this. Also a change that Kotlin 2.4 brings that is not highlighted here, but in regards to KMP, Kotlin Multiplatform, Swift export is now moving to alpha with this. Swift export is in the end a feature that will make it much much easier in Kotlin Multiplatform project to call Kotlin APIs, Kotlin functionality directly from Swift code because the Kotlin code that you have as part of your Kotlin Multiplatform project will be mapped directly to Swift code without any intermediate layer of Objective-C. So much about Kotlin 2.4, but there is a very cool new feature, a new tool from Kotlin, and that is the Kotlin tool chain. Now, that that's really what they've made quite some announcements about on Kotlin Conf. It's in the end a CLI Kotlin tool. So, it's very similar to the Android CLI that Google has announced one or two months ago, but for Kotlin and Kotlin Multiplatform project.

[00:05:25]So, it's in the end a CLI tool. You can see you can use it like this. Kotlin run. That covers all sorts of Kotlin project specific functionality for you to run from the command line. So, you can create new Kotlin projects from a template KMP project as well. You can run them. You can build them. You can run tests. You can document that and actually get some documentation. So, here I've already installed this. You can in the end type Kotlin help if you've installed that and then you will get a bunch of options that you could choose with this Kotlin CLI. Also, debugging works with that. So, it's in the end a central interface, the central API that gives you utility to work with Kotlin specific product, which is of course very helpful for Kotlin multiplatform project as well because these CLI tools are of course also very often the the main tool that agents stick to in order to control certain things about your project. So, an agent could now in the end initialize a new Kotlin project based on a template. An agent could now run your application directly via the CLI. It could clean the build folder and so on. And so, this is in the end what the Kotlin toolchain is all about. At its core, so internally it uses Amper. So, Amper is a JetBrains new build system that is YAML-based and is promised to be simpler than Gradle or Maven. And this toolchain now also gives Kotlin kind of a first-party tool that does not require you to learn all those Gradle DSLs or or Maven syntax while still remaining interoperable with the existing Kotlin ecosystem. They will very likely also release some sort of AI skills in order for an AI agent to learn how to use this tool, which commands to run in which case. But all in all, that's a pretty cool tool. And if you want me to cover that in a bit more detail, uh then of course let me know in the comments. Then what they've also announced is this Kotlin documentation model, uh which is in the end dealing with the problem that very often when you have a project or a library, a documentation for that library and functions of it are sprinkled across different sources. So, some part of the documentation maybe lives in your IDE, sometimes it lives in some kind of local files, sometimes it lives in the browser, some some kind of hosted website, like for example the JetBrains Ktor documentation. And this Kotlin documentation model in the end unifies the documentation into a machine-readable KDoc JAR file, which is then in the end a way to, for For tell AI agents the entire documentation about a certain function, give it way more context about how to use it. Then, the Kotlin language server is moving to alpha. What is the Kotlin language server all about? And well, in order to understand that, we first of all have to understand what a language service protocol is. But in the end, if you think of an IDE, an IDE can cover multiple different programming languages, Kotlin, Python, Java, and so on.

[00:08:04]And all these programming languages have their own kind of rules for the, let's call it, smart code support. So, being able to rename a variable in your IDE across different classes, auto-completion, going to a specific definition when you command click into a function, for example, all those are features that every single language in the end has and requires in some way.

[00:08:25]But how those features are implemented depends on the language. And the language server protocol itself, in the end, just standardized the communication in that sense. So, it's basically just asking the same question repeated for different languages. For example, given this field and at the cursor position, which completions for the code are valid? And this LSP protocol, in the end, just unifies that. So, it doesn't have to be re-implemented over multiple IDEs. And now, the thing here, the announcement is that this now exists for Kotlin. So, there is now first-party support for Kotlin language server.

[00:08:56]What does this mean? It means that you can also now better work with Kotlin in non-IntelliJ IDEs. For example, if you used Kotlin before in an editor like VS Code, then it didn't have this language server support, at least only a community extension, but not first-party support, which made it very hard for you to maybe use the refactor renaming tool, since there was no way for VS Code to know how that actually works in the context of Kotlin. And this is now moving to alpha, so you are much more flexible now with where you want to use Kotlin, in which IDE, in which editor, because they all stick to the language server protocol, at least the common ones. And now that Kotlin also has that one with first-party support from JetBrains, you are more flexible on where to use that. Then maybe something worth covering is the agent client protocol that is now be built or at least being focused on to embed in the future JetBrains IDEs. So it's in the end also just a protocol where you have a single entry point to talk to different kinds of agents. So Codex, Cloud, Gemini CLI, Juni, and so on. So you don't have to manage like five, six, seven different tools for your favorite agents, but it's in the end one central interface and you can decide which agents to control here.

[00:10:06]Then Kook 1.0 is now released. Kook is in the end JetBrains way for you to build AI agents on the back end side with Kotlin, with idiomatic Kotlin. So if you want to build your own customized AI agents and you want to use Kotlin for that, then Kook is the way for you to go. Maybe that could also be worth a tutorial, some kind of video where I showcase that, try it out myself. So if that is interesting to you to also have me cover something on the back end side, also let me know in the comments, please. And one more change here that's at least happened this month here regarding Compose Multiplatform, which is now at 1.11. So this wasn't something where they put a lot of focus on in the keynote on the Kotlin conference, Kotlin conference in general, but it's still Kotlin related news. And I think the coolest change here is actually just native text input on iOS. So if you are working with Compose Multiplatform, then you can actually have this native input here for iOS. We have this iOS-like text selection and this little glassy pop-up menu here for you to just add a more native feel to your Compose Multiplatform apps. Other than that, yeah, some Compose UI testing changes.

[00:11:14]It's in the end just aligning with what has changed on the Android side for UI testing already, that these APIs now default to standard test dispatcher rather than unconfined test dispatcher.

[00:11:24]In case you have Compose Multiplatform UI test, this may break some test cases because you need to maybe change them a little bit, Call something like advance until idle or advance uh time by. These APIs you now have to use more with a standard test dispatcher to instruct the coroutines from running that are being launched in your compose UI. For example, from a launch defect block.

[00:11:44]Smoother scrolling on web targets, yeah.

[00:11:46]I don't think that many people among you are using this for web at this point, but in case that's interesting to you, you now have smoother scrolling. Cool.

[00:11:53]As usual, down below in the video description you'll find all my Android and Kotlin multiplatform premium courses also for Kotlin backend side, by the way. So, if all this is interesting to you, check out the Kotlin full stack developer bundle because we really deep dive into all those technologies like compose multiplatform, Kotlin on the backend side, system design for mobile apps, building iOS apps with Kotlin. We really deep dive into that in this bundle. It's like I think 50-60 hour video material on how you build very high-performing compose multiplatform apps. Thanks for watching. I will see you back in the next video. Have an amazing rest of your week. [music] Bye-bye.