Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog

Kodee’s Kotlin Roundup: Shipaton 2026 Winners, Kotlin 2.5.0-Beta2, and KotlinConf 2027

Kodee — Fri, 30 Oct 2026 12:02:33 +0000

Hi everyone! It’s been a busy few weeks since my last roundup: the Shipaton 2026 winners are in, and three Kotlin Multiplatform apps took the Ship Kotlin Everywhere Award. In other news, Kotlin 2.5.0 is taking shape with its second Beta, KotlinConf 2027 is officially heading to Kraków with the call for speakers open, and the new State of Kotlin in 2026 report shows where the language stands after 15 years. Here’s what stood out to me most:

Where you can learn more

YouTube highlights

Google Summer of Code 2026 With the Kotlin Foundation: Recap

Ksenia Shneyveys — Thu, 15 Oct 2026 15:03:05 +0000

Google Summer of Code 2026 has wrapped up! This was the Kotlin Foundation’s fourth year participating in GSoC, bringing new contributors into the Kotlin open-source ecosystem through hands-on projects and mentorship.

This year, two projects successfully reached completion, tackling two areas of the ecosystem: improving recursion support in the Kotlin/Wasm backend and building a global picture of where Kotlin is taught.

Congratulations to Ayako Hayasaka and Mark Seif Khalil, and a huge thank-you to our mentors for supporting them throughout the program!

Here’s more on what they accomplished.

Tail call support in the Kotlin/Wasm backend

Contributor: Ayako Hayasaka
Mentor: Charlie Zhang (JetBrains)

Ayako’s project added support for WebAssembly tail-call instructions to the Kotlin/Wasm backend. The compiler can now detect calls in tail position and emit return_call or return_call_ref, helping recursive Kotlin/Wasm programs avoid increasing the call stack.

In Ayako’s benchmarks, several recursive patterns became 1.7–4.3x faster at a recursion depth of 10,000. At a depth of one million, the same programs crashed without tail calls and completed successfully with them.

Testing the change on real-world projects also revealed an unexpected performance regression in V8. Ayako traced it to a missing optimization for return_call, submitted a fix, and had the patch merged into V8.

“What surprised me the most was that Ayako, after implementing the new WebAssembly instructions and using them in the Kotlin backend, actually found a bug in the Google V8 engine. Not only did she report the bug, she fixed it as well.”

Charlie Zhang

Ayako has continued working on follow-up optimizations and other approaches to supporting recursive code beyond the original GSoC project.

For Ayako, GSoC 2026 was also a chance to work much more closely on language and runtime internals than in her everyday work.

“In my day job, I rarely get to touch the internals of a language, so I simply had a lot of fun with this opportunity. While investigating the slowdown, I had to read not only the compiler but also V8, and I realized how much there is to learn beyond the code I usually work on.”

Ayako Hayasaka

Read Ayako’s full story → Final project report

Mapping the global Kotlin education landscape

Contributor: Mark Seif Khalil
Mentors: Ksenia Shneyveys (JetBrains) and Elizaveta Artser (JetBrains)

Mark’s project set out to create a structured overview of where and in what context Kotlin is being taught, considering that the information is spread across websites, course curricula, repositories, learning platforms, and other sources. The project brought that fragmented information together and created a structured and automated way to gather this data.

Over the course of GSoC 2026, Mark explored different sources and approaches to collecting this information, built a database, and developed a process for parsing and structuring data from multiple sources.

“The biggest thing I learned is when to stop pushing on something that is not working and change my approach. This is a lesson I will keep with me in every project.”

Mark Seif Khalil

The resulting project gives us a reusable foundation for monitoring Kotlin’s presence in education and identifying trends and gaps.

“What impressed us both the most about Mark was his ability to take an initially exploratory idea and bring his own vision for the research while continuously incorporating our feedback. Mark turned this scattered information into a resource we can actually use to understand Kotlin education worldwide.”

Ksenia Shneyveys, Elizaveta Artser

Read Mark’s full story → Kotlin Education Landscape
Watch Mark’s GSoC reflection

Interested in contributing to Kotlin through a future Google Summer of Code – or mentoring a project yourself?

Join the #gsoc channel in the Kotlin Slack to meet the community, ask questions, and follow future GSoC announcements.

What Makes a Great KotlinConf Proposal?

Jelena Ilic — Thu, 15 Oct 2026 09:11:39 +0000

The KotlinConf 2027 Call for Papers is now open! We invite developers from across the Kotlin community to bring their ideas, experiences, and expertise to the stage in Kraków.

Do you have a Kotlin lesson or discovery that could help other developers? Perhaps you solved a difficult technical problem, introduced Kotlin into an existing codebase, built something unexpected, or learned valuable lessons from an approach that did not go according to plan.

That experience could become a KotlinConf talk.

Submit your proposal

However, turning an idea into a convincing conference proposal can be challenging, especially if you’ve never submitted one before. How do you know whether your experience is worth sharing? What do reviewers notice first? How detailed should your abstract be? And how can you make a familiar topic stand out?

To help you prepare your submission, we asked Kotlin developers, developer advocates, experienced speakers, and KotlinConf program committee members what makes a strong proposal. Alongside practical advice for shaping your title, abstract, and takeaways, we have added a new section answering an especially important question: What do reviewers notice first when they open a proposal?

First-time speaker? Submit your idea anyway!

It’s easy to assume that a KotlinConf talk must begin with a groundbreaking discovery, a major production system, or years of speaking experience. In reality, a valuable talk can begin with a simple idea or a lesson learned while solving an everyday development problem.

You don’t need to know everything about Kotlin – you need something useful to share and a clear idea of who it could help.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

Submit your idea anyway! There have been some wildly successful talks at KotlinConf that started out as just a simple idea.

If you’re unsure whether your topic would interest anyone, discuss it with the people around you. Explain the idea to colleagues, friends, members of a user group, or people in the Kotlin community. Their questions and reactions can help you understand which parts are most valuable.

Marcin Mycek. Product Manager, Kotlin Build Tools

If you can find one interested person, there are probably more! If you can find at least two people around you who find the topic interesting and can listen for more than five minutes, it is already a decent candidate.

Previous conference experience is not required. A clear, authentic proposal based on something you understand and care about can be more compelling than a polished proposal with little substance behind it.

Start with the story you want to tell

Before writing the title or opening the submission form, identify the central story behind your talk.

“A talk about coroutines” or “a session about Kotlin Multiplatform” describes a subject, but it doesn’t explain what makes the session valuable.

Ask yourself:

What problem, question, or opportunity did you encounter?
Why was it important or difficult?
What did you try?
What surprised you?
What succeeded and what did not?
What did you learn that other developers could apply?

Your story doesn’t need to come from a large company or a system used by millions of people. A focused lesson from a small project can be just as useful if it offers an original insight or explains a difficult subject clearly.

Try summarizing the idea in one sentence, for example:

This talk will show [audience] how we [solved or explored something], what we learned, and how they can apply those lessons.

If you can’t complete that sentence clearly, the idea may need a little more development before you start writing the proposal.

What do reviewers notice first?

The title may be the first line reviewers read, but the overall level of care quickly becomes visible.

Reviewers consider not only whether the topic is interesting, but also whether the speaker can explain it clearly. A thoughtful title, focused description, concrete takeaways, and careful formatting show that you have spent time developing your idea.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

I can sum it up by saying that the care you take in writing the proposal is probably more obvious than people think. If I can see that you took the time to come up with a catchy or descriptive title that works well with the content, I am more comfortable giving you a thumbs-up to speak at KotlinConf. If your description is so short or so long, or so clearly AI-generated, that you cannot express your idea clearly and neatly, I will probably not vote positively for your talk.

This doesn’t mean you need to use complicated language or create a perfect marketing pitch. It means giving reviewers enough information to understand your idea and showing that the proposal represents your own experience and voice.

Marcin Moskała’s Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World provides a good example of a precise promise: “You’ll learn how to effectively use built-in tools, recognize problematic patterns, and implement proven optimization strategies.”

Write a clear and informative title

A strong title should give reviewers, and eventually attendees, an accurate idea of what the talk will cover.

Creativity can make a title memorable, but clarity should come first. Avoid titles that rely entirely on a joke, reference, or metaphor without explaining the subject.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

A carefully-selected title can make all the difference! Audience members often lack the time or attention span to read more than the title when deciding whether to attend a talk. Prefer clarity over a catchy or fun title that doesn’t give a good idea of what the talk is about in a nutshell.

Compare the following title examples:

Too broad:
Our Multiplatform Journey

More informative:
What We Learned Migrating Our Mobile App to Kotlin Multiplatform

Too vague:
Coroutines Gone Wild

More informative:
Debugging Coroutine Performance Problems in Production

Too general:
Building Better APIs

More informative:
Designing Type-Safe Kotlin APIs That Are Difficult to Misuse

A good title usually communicates at least two of the following:

The main topic
The problem or question
The context in which it was explored
The practical benefit for attendees
The expected experience level

You can still use humor or wordplay, but make sure the title does not hide what the session is actually about.

Build your abstract around a clear journey

Your abstract doesn’t need to contain your entire presentation. However, it should provide enough detail for reviewers to understand the problem, the direction of the talk, and its value.

Two or three focused paragraphs will usually communicate more than either a single vague sentence or a very long description covering every detail.

Sebastian Sellmair. Software Developer and KotlinConf speaker

X, BlueSky, YouTube

Talking at KotlinConf is a great experience and a huge achievement for any Kotlin developer. While choosing a great title, having highly polished animations, and curating high-quality memes might enhance your talk, the most important thing is having a story worth telling. Do you have something novel and technically interesting to present? Can you break down a topic in a way that is engaging and truly fun? Can you inspire fellow developers?

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

While we don’t need a full script for your talk as the abstract, we’re also unlikely to accept a talk where the abstract is just a single sentence. Two or three paragraphs are usually enough to provide meaningful detail.

A simple structure can help:

The context

Introduce the situation and the audience likely to recognize it.

The challenge

Explain the problem, limitation, or question that motivated the work.

Jodie Burchell. Developer Advocate and Data Scientist

LinkedIn, Mastodon, BlueSky

Hook your audience by telling them the problem you’re going to be solving. People love mystery books for a reason, and that’s because they build up a bit of suspense before they jump into the solution. A great proposal will do the same thing.

The approach

Describe what you explored, implemented, compared, or discovered.

The outcome

Clarify what attendees will learn and how they can use it.

A strong takeaway can be as concrete as the one from Tadeas Kriz’s Dependencies and Kotlin/Native: “Learn how native dependencies interact, how they are loaded, and the unexpected complexities of the native world.”

Chantal Loncle. Software Developer, Exposed, JetBrains

Avoid vague promises. Instead, use action verbs and specific outcomes to describe the exact capabilities and transformations the audience will gain. Will they leave your talk feeling that their time was well spent? If so, what practical knowledge, immediately applicable skills, or high-value tools will they take with them?

For example:

Maintaining separate Android and iOS implementations allowed our teams to move independently, but it also resulted in duplicated business logic and inconsistent behavior between the applications.

In this session, we’ll examine how we introduced Kotlin Multiplatform gradually, beginning with one shared feature rather than attempting a complete migration. We’ll discuss how we selected the first component, structured the shared code, tested it across platforms, and worked with the existing native applications.

You’ll leave with a practical framework for evaluating where to introduce shared code, which challenges to expect, and how to plan an incremental Kotlin Multiplatform adoption without rebuilding your entire application.

The example establishes the problem, explains what the session will cover, and gives the audience a reason to attend. It doesn’t reveal every detail, but it makes a concrete promise.

Think like an attendee

A strong proposal doesn’t focus only on what the speaker wants to present. It also explains what the audience will gain.

Ask yourself:

Who is this session for?
What knowledge should attendees already have?
What problem will the talk help them solve?
What will they understand or be able to do afterward?
Why should they choose this session over another talk happening at the same time?

Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker

When submitting a talk, think like an attendee. Would you want to sit through this? What’s in it for the audience? That’s why we ask about key takeaways. What do you want people to learn, try, do, or feel inspired by?

Avoid broad promises such as:

“You will learn best practices.”
“We will explore Kotlin Multiplatform.”
“This talk will cover coroutines.”

Instead, describe specific outcomes:

Attendees will learn how to identify and debug three common coroutine performance problems.
Attendees will understand how we structured shared code across Android and iOS.
Attendees will be able to evaluate whether the approach fits their own project.
Attendees will learn which parts of our migration worked, which did not, and what we would change today.

Specific takeaways make the proposal easier to evaluate. If the talk is selected, they also help attendees decide whether it is relevant to them.

Make a familiar topic feel fresh

Your subject doesn’t have to be completely new. Many valuable conference talks revisit established technologies from perspectives that have not been explored in the same way before.

If you are proposing a popular topic, identify what makes your version distinctive. This could be:

A real production case
An unusual scale or environment
A surprising result
A failed approach and what it taught you
A comparison between several possible solutions
A gradual migration rather than a greenfield implementation
An unconventional use of Kotlin
A personal experience that challenges a common assumption
A particularly clear way of explaining a difficult concept

For example, “Introduction to Kotlin Multiplatform” is broad and familiar. “What Broke When We Introduced Kotlin Multiplatform Into a Seven-Year-Old Mobile App” offers a specific context and creates curiosity.

Be honest about trade-offs. A talk doesn’t need to present a flawless success story. Explaining what failed, what changed, and what you would do differently can be especially useful to other developers.

Chantal Loncle. Software Developer, Exposed, JetBrains

Bringing a real, practical narrative to a familiar topic can strengthen a proposal. Be honest about what broke, what made your team unhappy, or what you would do differently if you could turn back the clock. A familiar issue can feel fresh when you look at it from the perspective of someone who will encounter the same problem for the first time tomorrow.

Rather than providing another general overview, build the talk around one specific pain point or discovery and introduce broader themes only where they support that story. A takeaway that attendees can immediately apply to their work can also help distinguish the proposal from a basic tutorial.

Keep the proposal relevant to KotlinConf

KotlinConf welcomes talks about backend development, Android, multiplatform development, web, desktop, AI, language design, tooling, libraries, developer experience, and other parts of the Kotlin ecosystem.

Whatever your area, the role Kotlin plays in the story should be clear.

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

Keep in mind that your talk should be related to Kotlin! For example, not every Android talk is necessarily a good fit for the KotlinConf audience. Or talks about Jetpack Compose often cover things that work the exact same way with Compose Multiplatform, and the latter is much more likely to be accepted at KotlinConf!

An Android topic, for example, is not automatically a KotlinConf topic. The proposal becomes more relevant when it explains how Kotlin influenced the solution, explores a Kotlin-specific technical decision, or provides lessons that Kotlin developers can apply.

Ask yourself:

Why is this a Kotlin story?
Which parts of the experience are especially relevant to Kotlin developers?
Would the proposal still be essentially the same if Kotlin were removed from it?

If the answer to the final question is yes, strengthen the connection to Kotlin before submitting.

Anshika Koul’s Kotlin Multiplatform’s Cross-Platform Brilliance at Norway’s 377-Year-Old National Postal Service offers a clear example of a Kotlin-centered takeaway: “We’ll learn how KMP provides a unified framework for code sharing and execution across various platforms to solve the challenge of different codebases targeting different runtimes.”

Sound confident, but stay true to yourself

Your proposal should show that you understand what you want to share and why it matters.

This doesn’t mean exaggerating your expertise or pretending that you have no doubts. It means presenting the idea as a clear statement rather than repeatedly questioning its value.

Marcin Mycek. Product Manager, Kotlin Build Tools

Keep statements as statements and questions as questions. It is normal to doubt yourself; everybody does, but a common mistake is to let it show in the text, for example, by changing statements into questions. Read your submission, or even better, ask someone else to read it, and ask yourself: Does this person sound convinced about what they want to tell?

For example:

Uncertain:
Could Kotlin Multiplatform possibly help teams reduce duplicated business logic? In this talk, we might find out.

More confident:
In this talk, I’ll show how our team used Kotlin Multiplatform to reduce duplicated business logic, including where sharing code helped and where it did not.

Confidence should not erase your personality. The proposal should still sound like you.

Marcin Mycek. Product Manager, Kotlin Build Tools

Stay true to yourself! It is important to make sure that your submission can be understood by others. A great practice is to give it to a few people you trust and ask what they understood from it and how it made them feel. However, keep your soul in it. A lot of great talks are quirky, do not follow every best practice, and people are there for it.

Advice and templates can help you organize your thoughts, but they shouldn’t make every proposal sound identical. Your perspective, language, humor, and enthusiasm are part of what makes the submission memorable.

Show reviewers how you communicate

Examples of previous talks help reviewers understand your presentation style and energy. If you have recordings from conferences, meetups, webinars, or livestreams, include the most relevant ones.

If you’re a first-time speaker and don’t have a formal recording, you can record yourself explaining part of the proposed talk. A simple laptop recording is enough. It doesn’t need professional lighting, editing, or production.

Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker

Examples of your talks help us make better choices. If you’re a first-time speaker and don’t have recordings, no worries! You can simply record yourself (even just part of your proposed talk) on your laptop and share the link. We would really appreciate it.

Depending on the topic, you can also include:

A technical article
An open-source project
Documentation you have written
A short technical demonstration
A podcast or meetup appearance
Other work connected to the proposed session

These materials support your proposal, but they don’t replace a clear title, abstract, and set of takeaways. Reviewers should still be able to understand the session from the submission itself.

Choose the format that fits the idea

Not every subject needs a full-length session.

A focused lesson, experiment, side project, or surprising discovery may work better as a lightning talk. A subject that involves significant technical context, several connected lessons, or a detailed demonstration may require a regular session.

Choose the format according to the amount of meaningful material you have. If you need to repeat yourself or add unnecessary content to fill a regular session, consider proposing a lightning talk instead.

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

Don’t forget that we also accept lightning talks! If you feel like your content would have to be padded to fill a regular session, it might be more enjoyable as a lightning talk.

You can also submit more than one proposal if you have several distinct ideas. Each submission should have its own story, audience, and takeaways rather than being a minor variation of another proposal.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

Submit more than one talk! It gives you more chances to join in on the KotlinConf fun.

Review the proposal before submitting

Once you have completed your draft, step away from it and return later from the perspective of someone encountering the idea for the first time.

Check whether your proposal answers the following questions:

Can someone understand the subject from the title?
Is the connection to Kotlin clear?
Does the abstract identify a real problem, question, or story?
Is it clear who the session is for?
Are the takeaways concrete?
Does the proposal explain what makes your perspective different?
Is the scope realistic for the selected format?
Does the writing sound confident and authentic?
Have you checked the spelling, grammar, links, and formatting?
Does the proposal sound like the person who will deliver the talk?

Ask someone else to review it, too. Rather than simply asking whether they like it, ask them to describe what they think the talk will cover and what they expect to learn. Their answer will show whether the proposal communicates what you intended.

Chantal Loncle. Software Developer, Exposed, JetBrains

Double-check that the intended audience level aligns with the description and expected takeaways. Review the proposal from the perspective of someone you hope will be in the audience. Does it make sense as it is, or is it missing context that may be obvious to you but not to the reviewer or the future audience they are keeping in mind?

AI tools may help you check grammar or organize your thoughts, but the final proposal should reflect your own experience, ideas, and voice. A polished abstract without specific or authentic insight won’t be as convincing as one that clearly represents the speaker behind it.

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn

Your submission should show that you’ve put some thought and energy into preparing it. Check your submission for formatting issues and typos, and please don’t submit abstracts that were generated by LLMs.

Your Kotlin story could take the stage

You don’t need to know everything about Kotlin or have years of conference experience to submit a proposal. You need a useful story, an understanding of who it can help, and a clear explanation of why it matters.

Not every strong proposal can be selected. Conference programs must balance subjects, formats, experience levels, and audience interests. If your submission is not accepted, continue refining the idea, sharing your knowledge, and looking for other opportunities to present it.

Your experience might be exactly what another Kotlin developer needs to hear.

The KotlinConf 2027 Call for Papers is open! Share your experience, ideas, and Kotlin expertise with the community in Kraków.

Submit your proposal

KotlinConf Recap: Lessons from Verifone’s Architect on Kotlin in Mission-Critical Payments

Alina Dolgikh — Wed, 14 Oct 2026 11:03:00 +0000

This article was written by an external contributor.

Aniket Bhattacharyea

Aniket is a Mathematics postgraduate who has a passion for computers and software. He likes to explore various areas related to coding and works as a web developer using Ruby on Rails and Next.JS.

Website

Yuri Geronimus’s four-year-old son once asked him what his job was. Yuri told him he writes books: books that describe what he wants to change in the physical world. His son didn’t fully get it.

Neither would most engineers: if you understand the words in your application code, you build good systems. If you don’t, you build bugs.

That’s the spine of Yuri Geronimus’s KotlinConf 2026 talk, “Kotlin as a Safety Net: Type-Driven Reliability in the Finance Industry”. Yuri is an architect at Verifone, where he works across payment terminals, gateways, and the systems that connect them to banks and regulators in the EMEA region. His method, in one line: write code in the exact words of the regulator or card network specs, and let the compiler enforce it. Enforce not by discipline, but by the compiler.

Watch the KotlinConf 2026 talk

Watch Yuri Geronimus’s KotlinConf 2026 talk to learn how Kotlin helps build reliable payment systems.

The world behind the terminal

Before the patterns, Yuri set the stakes. A “payment” isn’t one app. It’s a mobile sales app, a point-of-sale app, a payment terminal running on a locked-down OS, payment gateways, terminal management systems, merchant platforms, and, underneath it all, processors, banks, and regulators. Each country carries thousands of pages of specifications and roughly 1,000 scenarios that must be met before anything reaches production.

Some of those terminals have to keep working offline for up to 40 days, by regulation, because in the country they operate in, a payment terminal is critical infrastructure on the same level as a gas station or a pharmacy. Payment teams also have to satisfy contradictory rules from different regulators governing the same shared infrastructure: one country requires a behavior, another forbids it, and both must be enforced in the same codebase. That’s the environment the type system has to hold up in. Not a demo. Production, worldwide, for decades, not a year.

Six ways one word breaks a payment system

Yuri walked through real incident patterns from his 15 years in payments and banks, each one traced back to a single missing or misused word:

An incorrect field caused a reversal, and someone else’s money landed in the wrong account.
A mandatory field was made nullable “just in case”. When a firmware update stopped sending it, the code fell back to a default, and part of the terminal fleet stopped processing payments.
A card number ended up in a log line and a stack trace: a disclosure obligation, and a real compliance problem.
An authorization was approved while the fraud check timed out, and money was stolen.
A request timed out, but the authorization had succeeded upstream, and the customer paid twice.

Each of these traces back to the same root cause: somewhere, the code disagreed with the specification about what a word meant, and nothing forced that disagreement into the open before it reached production.

The method: write the spec, then let the compiler check your work

Yuri described this as a set of patterns, not a framework. Ten of them, all doing the same job: making illegal states impossible to construct, not just invalid ones you catch later.

1. Value classes for spec nouns

Fraud and risk models carry dozens of similarly shaped IDs: merchant ID, terminal ID, acquirer ID, and more, several of which are literally identical in format due to regulation. As plain strings, nothing stops a refactor or copy-paste from swapping two of them, and the transaction silently routes to the wrong acquirer, for example. Yuri’s fix is a value class per ID.

@JvmInline value class MerchantId(val value: String)
@JvmInline value class AcquirerId(val value: String)
@JvmInline value class AmountMinor(val value: String)

data class AuthRequest(val merchantId: MerchantId, val acquirerId: AcquirerId, val amount: AmountMinor)

fun demo(merchantId: MerchantId, acquirerId: AcquirerId, amount: AmountMinor) {
    AuthRequest(merchantId, acquirerId, amount)   // ✅ compiles
    // AuthRequest(acquirerId, merchantId, amount)   // ❌ type mismatch: swapped arguments do not compile
}

Swap the arguments now, and the code doesn’t compile. The mistake that used to reach production becomes a build error on the engineer’s own machine.

2. Validate factories

Every external field, whether it comes from a bank’s API or a terminal’s firmware, arrives as an untyped string that might not mean what the spec assumes. Yuri’s pattern parses it immediately into a sealed result at the boundary rather than trusting it downstream.

@JvmInline value class RawStan(val value: String)   // untrusted input
@JvmInline value class Stan(val value: String)      // validated, per spec

sealed interface ParsedStan {
    data class Valid(val stan: Stan) : ParsedStan
    sealed interface Invalid : ParsedStan {
        val rawStan: RawStan
        data class WrongLength(override val rawStan: RawStan) : Invalid
        data class NotNumeric(override val rawStan: RawStan) : Invalid
    }

    companion object {
        fun of(rawStan: RawStan): ParsedStan = when {
            rawStan.value.length != 6         -> Invalid.WrongLength(rawStan)
            !rawStan.value.all(Char::isDigit) -> Invalid.NotNumeric(rawStan)
            else                              -> Valid(Stan(rawStan.value))
        }
    }
}

fun authorize(rawStan: RawStan): AuthResponse =
    when (val parsed = ParsedStan.of(rawStan)) {
        is ParsedStan.Valid   -> gateway.authorize(parsed.stan)   // happy path
        is ParsedStan.Invalid -> reject(parsed)                   // structured rejection
    }   // no else, no try/catch, no Result to unwrap – exhaustiveness is enforced

fun demo(raw: RawStan) {
    when (val parsed = ParsedStan.of(raw)) {   // bad input is a value, not an exception
        is ParsedStan.Valid               -> gateway.authorize(parsed.stan)
        is ParsedStan.Invalid.WrongLength -> reject(parsed)
        is ParsedStan.Invalid.NotNumeric  -> reject(parsed)
        // forget any of the cases → ❌ 'when' expression must be exhaustive
    }
}

This approach Yuri thinks is a very good practice: it doesn’t throw exceptions; it helps prevent the not-best approach with Result, which hides the business domain, and prevents runCatching pitfalls in coroutines

3. Non-null types at the boundary

Many times, mandatory fields are marked nullable “just in case”, which requires juggling with silent fallbacks that often hide the real culprit. Yuri suggests leveraging Kotlin’s null-safety to fail loudly in one place:

data class KernelResult(val tvr: TerminalVerificationResults) // ← not Optional, not nullable

fun fromFirmware(raw: FirmwareResponse) = KernelResult(
    tvr = requireNotNull(raw.tvr) { "TVR null - firmware contract violated" }
)
// One loud failure at the boundary. Never a silent fallback downstream

fun demo(raw: FirmwareResponse) {
    // raw.tvr ?: TerminalVerificationResults()   // ❌ "just in case" fallback: silently hides the broken contract
    val result = fromFirmware(raw)   // one loud failure here, at the single parsing point where it is monitored
    val tvr: TerminalVerificationResults = result.tvr   // non-null: nothing downstream has to guard against it
}

This is the fix for the terminal-fleet outage: the field that was made nullable “just in case” never got a silent default again. It fails once, loudly, at the one predictable place it’s parsed, where it can be monitored, instead of failing quietly somewhere downstream where nobody is watching for it.

4. Mask sensitive data by default

Card numbers travel through logs and stack traces as plain strings, and that’s a disclosure obligation waiting to happen. Yuri wraps the value in a class with a private constructor and overrides toString(), so the safe behavior is the default.

// Illustration of the idea: in production this is hidden much deeper (PCI scope, key management, encryption)
@JvmInline
value class Pan private constructor(private val value: String) {
    override fun toString() = "PAN[****]"                         // ← always safe
    fun masked(): String = TODO("Pan.masked: masking according to spec")
    fun toNetwork() = value                                       // deliberate, grep-able

    companion object {
        fun of(raw: String): Pan? = TODO("Pan.of: the only way in – validate length, digits and Luhn, then construct")
    }
}

fun demo(card: Pan) {
    logger.info("Processing card $card")   // → "Processing card PAN[****]". Safe by default
    val onWire = card.toNetwork()          // the real value only through an explicit, grep-able call
}

An accidental log.info(“processing $pan”) now prints four masked digits. Getting the real value out, the one thing that’s genuinely needed to talk to the network, requires an explicit, auditable call. Nothing about that path is invisible anymore. Small note from Yuri: in real systems it hid much deeper.

5. Give every state its own class, not just its own name

A transaction that’s been refunded should never be able to call refund again, but a single mutable Transaction class with a status field relies on someone remembering to check that status everywhere. Yuri’s next-level version gives each state its own data class, so the method cannot change transaction state from the wrong data class; this ensures that a transition that shouldn’t happen (for example, refunding a reversed transaction) is blocked by the compiler.

import TransactionStatus.Captured
import TransactionStatus.FullyRefunded
import TransactionStatus.Reversed
import java.time.Instant

// One class per state: each state carries only the data that is valid in it
sealed interface TransactionStatus {
    data class Captured(val amount: AmountMinor)    : TransactionStatus
    data class FullyRefunded(val at: Instant)       : TransactionStatus
    data class Reversed(val reason: ReversalReason) : TransactionStatus
}

// Refund exists only on Captured: that is where the spec allows it
fun Captured.fullRefund(refundReason: RefundReason) = RefundAuthorization(amount, refundReason)

fun demo(captured: Captured, refunded: FullyRefunded, reversed: Reversed, reason: RefundReason) {
    captured.fullRefund(reason)   // ✅ compiles
    // refunded.fullRefund(reason)   // ❌ unresolved reference: a refunded transaction cannot be refunded again
    // reversed.fullRefund(reason)   // ❌ unresolved reference: a reversed transaction cannot be refunded
}

6. Immutability and named transitions

This continues the previous pattern. Make the class with your business data immutable and give every transition a name. The name is a verb from the spec. Any method that shouldn’t be callable simply doesn’t exist:

@ConsistentCopyVisibility  // Kotlin 2.0.20+: copy() is as private as the constructor
data class PurchasedAuthorization private constructor(
    val stan: Stan,
    val amount: AmountMinor,
) : Authorization {
    fun fullRefund(refundReason: RefundReason) = RefundAuthorization(stan, amount, refundReason)
    // no reverseAuthorization(): the spec does not allow it for a purchase
}

fun demo(purchaseAuthorization: PurchasedAuthorization, reason: RefundReason) {
    purchaseAuthorization.fullRefund(reason)         // ✅ compiles
    // purchaseAuthorization.reverseAuthorization()  // ❌ compile error: unresolved reference 'reverseAuthorization'
}

Yuri called this his favorite pattern because it affects how engineers read a spec. This changes how engineers think and speak about the business domain.

7. Delete the else branch

If a specification lists every case explicitly and never says “otherwise,” then an else in the code is inventing a case the spec doesn’t describe. His team had handled only full refunds. When partial refunds became a real scenario, the old else branch would have absorbed it silently: compiles fine, tests pass, and it’s wrong in production. Delete the else, and the same new case becomes a compile error that points to every place needing an update.

fun authorize(request: AuthorizationRequest): Authorization = when (request) {
    is PurchaseRequest   -> purchase(request)
    is FullRefundRequest -> fullRefund(request)
    // ← no else. Adding a new state BREAKS compilation here
}

fun demo(purchase: PurchaseRequest, refund: FullRefundRequest) {
    authorize(purchase)   // ✅ compiles
    authorize(refund)
    // spec adds: class PartialRefundRequest : AuthorizationRequest
    // → ❌ authorize() stops compiling: 'when' must be exhaustive
}

The business drifts constantly quarterly and monthly in payment in one country, and for the whole EMEA region – it becomes daily at Yuri’s scale. An exhaustive when turns every drift into a list of exactly what needs to change, rather than a bug report from a customer who was charged the wrong amount.

8. Choose the coroutine scope the spec implies

Yuri’s Black Friday example: authorization, risk management, and fraud checks used to run as three independent calls, each in its own try/catch. If fraud management ran slowly under load, the transaction could still be approved while the fraud check silently failed, and stolen cards could start getting approved. Kotlin gives two structured concurrency scopes that look similar and behave completely differently, and the spec, not convenience, should decide which one you use.

import kotlinx.coroutines.*
// coroutineScope = fail-fast.   ← partial success is an incident: one failure cancels the rest
// In production each call also gets its own timeout, and a timeout is an outcome, not a thrown exception
// (full version with tests: production/08_coroutine_scopes)
suspend fun authorize(req: Request) = coroutineScope {
    val auth  = async { acquirer.authorize(req) }
    val risk  = async { riskEngine.score(req) }
    val fraud = async { fraudService.check(req) }
    Outcome.from(auth.await(), risk.await(), fraud.await())
}
// supervisorScope = isolate.    ← partial success is the goal
// Note: runCatching also catches CancellationException. In production rethrow it
// (e.g. `catch (e: CancellationException) { throw e }`) so cancelling the parent still works.
suspend fun fanOut(event: Event) = supervisorScope {
    listOf(
        async { runCatching { sms(event) } },
        async { runCatching { analytics(event) } },
        async { runCatching { feed(event) } },
    ).awaitAll()   // never throws: each failure is a Result.failure in the list
}

Here, coroutineScope fails fast: if the fraud check fails, authorization and risk are canceled as well, and nothing is silently approved. A supervisorScope would let siblings keep running independently, which is the right call for something like fan-out notifications, where one failure shouldn’t cancel the rest. The question isn’t which scope is more idiomatic. It’s what the spec says should happen when one branch fails.

9. Model timeout as a domain outcome, not an exception

A gateway call that times out isn’t necessarily a failure. The acquirer may have already processed it; the client just didn’t hear back in time. Catching that as a generic exception and moving on erases the difference between “nothing happened” and “something happened, we’re just not sure what”. Yuri’s fix models a Timeout as a first-class outcome in the domain.

import AuthorizationOutcome.Approved
import AuthorizationOutcome.Declined
import AuthorizationOutcome.TimedOut

sealed interface AuthorizationOutcome {
    data class Approved(val authCode: AuthCode)    : AuthorizationOutcome
    data class Declined(val reason: DeclineReason) : AuthorizationOutcome
    data object TimedOut                           : AuthorizationOutcome // ← spec verb, named in domain
}

fun demo(req: Req) {
    when (val outcome = processAuth(req)) {
        is Approved -> settleTransaction(outcome.authCode)
        is Declined -> notifyCardHolder(outcome.reason)
        is TimedOut -> reconcile(req)  // not retry: it may have succeeded upstream
    }
}

TimedOut isn’t the absence of an answer. It’s a distinct state that routes to a reconciliation query rather than a retry, because a naive retry after a timeout that actually succeeded upstream is exactly how a customer ends up charged twice.

10. Make the tests something a regulator can read

Yuri’s least expected pattern targets certification tests, not application code. A typical certification suite runs a thousand tests at roughly 200 lines each, and, in his words, not even an architect can read that. The team rewrote the tests as Kotlin DSL. Written that way, a certification specialist who has never written Kotlin can read the test, follow the logic against the specification, and sign off on it directly. The test stops being an artifact only test engineers can verify and becomes a specification the business and certification specialists can review.

val purchaseOverFloorLimit = scenario("Purchase with tap card above floor limit must go online") {
    terminal { floorLimit = 50.EUR }
    posRequest  { purchase(amount = 75.EUR) }
    tap { card = TestCards.visaWithOnlinePIN }

    expect {
        terminalDecision  mustBe  GoOnline
        outcome           mustBe  Approved
    }
}

What actually moved

Yuri is specific about the outcomes: development ran 2.7 times faster, and certification passed with only one defect and on the first attempt, unusual enough that regulators asked what had changed. The resulting codebase was about 30% smaller. Code review shifted from hunting for missed state checks to comparing code against the specification sentence by sentence, because the compiler now catches the class of bug reviewers used to look for by hand. Onboarding a new engineer used to take two or three weeks before they understood enough of a 5,000-page specification and a legacy codebase to ship anything. Afterward, new hires opened a production pull request within days. Engineers could also move between device teams and backend teams, something a split codebase in two different languages had made difficult. The last effect Yuri called out was that engineers started speaking the business’s language well enough to talk directly with product managers, sales, and regulators, occasionally proposing changes to the regulations themselves.

Payments modernization without a rewrite

Yuri is direct about the mistake most teams make: treating migration as one project, a rewrite in Kotlin. His systems run 25-year-old Java and C++ code processing live transactions every second, with no acceptable downtime, so a rewrite was never on the table. Framed as a refactor-vs-rewrite decision, the answer for a live payments platform is almost always refactor. His alternative is four tracks that run in parallel, not in sequence.

Optimize the existing codebase first, in Java or C++, without touching the language; modernize code structure now – shared layout, clean architecture, screaming architecture – even before any Kotlin lands.
Shift to acceptance-test-driven development, not unit-test-driven. Nobody outside the engineering team cares what’s inside a function; everybody cares about the end-to-end behavior.
Build fitness functions to check compliance, security, scalability, and other “-lities” that run alongside the migration rather than being assessed at the end.
Migrate incrementally: new adapters first, then new domain models, then the legacy code that changes most often, working to reduce the number of “shared ports” to zero. Kotlin’s interop with Java is what makes this incremental path possible at all: a new adapter can sit alongside unmodified Java code without a dual-maintenance period.

Running all four at once, according to Yuri, is what makes a payments modernization effort safe and cost-effective in a regulated environment. Running them in sequence is what makes migrations stall.

Migration is an investment decision, not a language preference

Yuri pointed out who needs convincing in an enterprise: it isn’t the engineering team. He referenced a talk from Uber’s team the day before his, at the same event, making a similar point: even a company known for moving fast treats language migration as an investment decision once it’s operating at enterprise scale. A credible business case has to account for the costs of running old and new systems in parallel, the costs of decommissioning what’s being replaced, the learning curve for the team, and the risk of the transition itself. Getting the migration approved is not the same as its adoption. Without an operating model for how the migration actually runs day-to-day, Yuri was blunt: there’s no happy ending waiting at the end of it.

He pointed to a resource for that exact gap: a 22-page playbook on the Kotlin site, published two days before this talk, covering, in his words, “the part that everybody skips”.

What is Yuri Geronimus’s core method, in one sentence?

Write code in the literal words of the specification and let the compiler enforce them, rather than relying on discipline or documentation to catch gaps between the two.

Do you have to rewrite a legacy Java or C++ system to use these patterns?

No. Yuri explicitly argues against treating migration as a rewrite project. His four tracks run in parallel: optimizing the existing codebase, shifting to acceptance testing, more focus on fitness functions, and migrating incrementally, starting with adapters and the domain models, then going from the most-often-changed parts.

Why doesn’t discipline or code review catch these bugs instead?

At the scale Yuri operates, 20 teams worldwide, discipline doesn’t scale evenly. A compiler check applies identically everywhere, every time, regardless of who’s on call or how careful any one reviewer is that day.

Start Your Next KMP App With Kotlin Toolchain 0.13

Anton Makeev — Wed, 07 Oct 2026 10:21:46 +0000

The Kotlin Toolchain is a unified entry point into Kotlin. It lets you build JVM, Android, iOS, multiplatform, and server-side applications with a simple declarative configuration.

With the release of v0.13, we now recommend the Kotlin Toolchain for most new Kotlin Multiplatform (KMP) projects.

Earlier this year, we promoted the Kotlin Toolchain to Alpha. Since then, our Slack channels and issue tracker have been very active. So many of you in the community have joined us to create a great build experience for Kotlin. Thank you – your continuous feedback helped us get here!

Not using the Kotlin Toolchain yet? Experience automated environment setup and an intuitive CLI that works well with your AI agents.

Install Kotlin Toolchain

To access the latest Kotlin Toolchain features from your IDE, use IntelliJ IDEA 2026.2.3, Android Studio Rabbit 1 | 2026.2.1 (or newer). Make sure the latest version of the Kotlin Toolchain plugin is installed.

How the Kotlin Toolchain simplifies getting started

Getting started with Kotlin Multiplatform often means working with unfamiliar platforms. Android developers might be discovering iOS for the first time, while other teams are expanding to web or desktop. Every platform comes with its own tools to install and build configurations to understand.

The Kotlin Toolchain changes that. It is a single CLI entry point for configuring the environment, creating, building, testing, and publishing your KMP apps and libraries. It comes with a declarative project configuration and set of all necessary tools – everything you need in one place.

In recent releases, we’ve refined the CLI and IDE experiences, added support for web and cinterop, and made many other improvements based on your feedback. Our internal dogfooding and positive community feedback have given us the confidence to recommend it for new projects!

We’ll feature the Kotlin Toolchain in our KMP getting started guides, web and IDE project wizards. These updates will make it easier for both developers and AI agents to select the Kotlin Toolchain when it’s most appropriate for the task at hand.

Direct support for agentic workflows

From early on, we designed the Kotlin Toolchain to be reliable and easy to use for both developers and IDEs. It turns out that the automatic environment setup, declarative configurations, and clear, actionable error messages provide an ideal foundation for AI agents as well.

We’ve taken this further by introducing a Hot Reload MCP server and dedicated AI agent skills, included in the official AI agent skills for Kotlin. You can install them with:

npx skills add kotlin/kotlin-agent-skills

Eventually, these skills will be delivered directly through the Kotlin Toolchain. In our benchmarks, AI agents already generate and maintain Kotlin Toolchain projects more reliably while consuming fewer tokens.

What’s new in the 0.13 release

New project creation with `kotlin new`

Version 0.13 introduces the kotlin new command, offering an interactive setup flow similar to the Kotlin Multiplatform Wizard. Note that the kotlin init command remains available; it has been updated to match the behavior of kotlin new, but it generates project files directly inside your current directory.

When you run kotlin new, the first prompt asks you to select your application type:

For Kotlin Multiplatform applications, you can choose your target platforms in the second step:

Better onboarding UX for iOS applications

Setting up iOS applications on a clean machine is now significantly smoother:

Better Xcode installation diagnostics: Get clear, actionable messages regarding Xcode license acceptance and first-run status.
iOS simulator runtimes are downloaded automatically when needed. An iOS simulator is created automatically if none exists.

Download progress reporting in the CLI

The TUI now displays rich download progress bars when the Kotlin Toolchain downloads required tools, such as JDKs, Android SDK components, iOS runtimes, and compilers.

Android improvements

In previous versions, the Android SDK was automatically provisioned when running kotlin build or kotlin run but not when opening the project in an IDE. If you opened a project in your IDE before running a build, missing SDKs could cause setup errors.

We have aligned CLI and IDE behavior, and the Kotlin Toolchain now automatically provisions missing Android SDK components on project import.

Additionally, we’ve also tightened validation for namespace and application ID definitions so you don’t accidentally publish app or library builds with sample IDs like com.example.app.

Sync status in the IDE editor

You can now monitor the current IDE sync status inside your file editor:

SPM import

The Kotlin Toolchain now supports Swift Package Manager dependencies for Apple platforms.

Modules with Apple platform support (e.g. kmp/lib, ios/app) can import Objective-C APIs from Objective-C and Swift code using SwiftPM dependencies:

product: ios/app

dependencies:
  - swiftPackage:
      repository: "https://github.com/firebase/firebase-ios-sdk.git"
      version: "12.17.0"
      products: [ "FirebaseCore", "FirebaseFirestore", "FirebaseAnalytics" ]

Imported Objective-C APIs are namespaced using the swiftPMImport prefix and ending with the module name:

// app/src/app.kt
import swiftPMImport.app.FIRAnalytics
import swiftPMImport.app.FIRApp

Kotlin Toolchain also supports local SwiftPM packages using the localSwiftPackage key. See our documentation for more details.

Multiplatform library publication improvements

When publishing multiplatform libraries, your Compose Resources and SwiftPM dependencies metadata are published along with your build artifacts.

Compose Resources are also resolved from third-party multiplatform libraries.

Kotlin/Native compiler caches

Kotlin/Native rebuilds just got faster. With KTC-5422, the Kotlin Toolchain caches compiled native dependencies and reuses them across builds and even across projects. Project code gets per-file caches, letting the compiler rebuild only the affected code during linking. Once the caches are populated, small edits mean less work and faster edit–build–run cycles for native apps and tests.

The feature uses the existing settings.kotlin.compileIncrementally setting and supports non-optimized debug binaries on compatible targets. Compilation to .klib files continues to run in full.

What’s next for the Kotlin Toolchain and KMP

We have some exciting milestones on our roadmap, including:

Installing the Kotlin Toolchain via brew install kotlin.
Providing AI skills out of the box.
Supporting Swift Export as it stabilizes.
Streamlining and automating app store publishing workflows.

Much of our immediate focus will be on understanding new user feedback and closing existing gaps, including those for existing Gradle projects, before recommending migrations.

To achieve this, we want to hear from you! As we refine the functionality, some changes may require adjustments to your projects, and we’ll do our best to support you through those migrations and make them as smooth as possible.

Join the conversation in the #kotlin-toolchain Slack channel (get invite: kotl.in/slack) or share your suggestions and ideas in JetBrains YouTrack. Your input and use cases help shape the future of the Kotlin Toolchain!

Install Kotlin Toolchain 0.13.0

Ready to give the Kotlin Toolchain a go? Check out our Getting started guide to dive into code examples, tutorials, or our comprehensive user guide.

Install Kotlin Toolchain

Already using the Kotlin Toolchain? Simply run kotlin update in your terminal to upgrade.

Discontinuing Swift Language IDE Support in the Kotlin Multiplatform Plugin

Anton Makeev — Mon, 05 Oct 2026 10:46:19 +0000

Starting with IntelliJ IDEA 2026.3 and Android Studio Rabbit 2 | 2026.2.2, we’re discontinuing Swift language IDE features in the Kotlin Multiplatform (KMP) plugin. This includes editing, syntax highlighting, and navigation within Swift files and between Swift and Kotlin.

Running iOS applications and debugging Kotlin code on iOS will remain fully supported. Kotlin/Native functionality, such as Swift Export and importing Swift packages into Kotlin projects, is not affected.

The existing Swift functionality will remain available in earlier versions of IntelliJ IDEA, Android Studio, and the Kotlin Multiplatform plugin, though these older versions will not receive further updates.

Background

We originally developed Swift support for AppCode (our since-discontinued iOS IDE) and for working directly with Xcode projects. This technology was later adapted for Fleet’s polyglot capabilities and, most recently, for working with mixed Kotlin–Swift codebases using the Kotlin Multiplatform plugin.

While analyzing feature adoption, we found that active usage was limited and steadily declining. Our telemetry and user research showed that most iOS developers working on KMP projects prefer using Xcode for Swift development, while teams that primarily work in the Kotlin Multiplatform plugin increasingly use Kotlin and Compose Multiplatform.

Maintaining this Swift tooling, which inherited its core architecture from AppCode, requires substantial ongoing effort to stay compatible with continuous changes in Swift, Xcode, and the IntelliJ Platform. While we previously considered expanding Kotlin–Swift IDE support in the plugin, after weighing the necessary engineering investment against actual usage numbers we decided not to continue.

Looking ahead

We do not currently plan to replace these features. Moving forward, we will continue evaluating workflows and focus on providing excellent Kotlin tooling in IntelliJ IDEA and Android Studio and improving the KMP experience for iOS developers.

We would like to thank everyone who used Swift IDE features, especially those who have been with us since the AppCode days, and to all the contributors who put so much dedication into building and refining Swift support over the years.

Yours,

The Kotlin team

The Companions to Come

Alejandro Serrano Mena — Wed, 30 Sep 2026 10:33:03 +0000

We are working on extensions to our companions mechanism to unlock new code patterns and improve interoperability across different platforms. This post outlines these new features and provides preliminary guidance on migration.

Companion blocks and extensions

Many programming languages provide a notion of class or type members – functionality that does not belong to each particular value of a class, but to the class itself. Constants, utilities, and factory methods are often in this group.

val v1 = Vector(1.0, 2.0)             // a regular vector
val v2 = Vector.ZERO                  // the constant zero vector
val v3 = Vector.unit(angle = PI / 2)  // unit vector with an angle

Previously, companion objects were used to define these members. From Kotlin 2.5.0 on, you can also use an experimental companion block, which is very close syntactically, but with profound changes in compilation.

data class Vector(val x: Double, val y: Double) {
  companion {
    val ZERO = Vector(0.0, 0.0)
  }
}

In fact, these members may not be defined directly on the class itself. You can also use an experimental companion extension to declare new class members in a type, even if you don’t control them.

companion fun Vector.unit(angle: Double) = Vector(cos(angle), sin(angle))

The design of companion blocks and extensions overcomes the limitations imposed by companion objects. First of all, you can define companion extensions for any class or interface – whether you control it or not, whether it originally comes from Kotlin or from Java, or whether it has a companion object or not.

Second, the compilation strategy resembles that of static members in other platforms. For example, on the JVM, companion blocks are compiled as static members. This has additional implications for Kotlin Multiplatform: you can now define expected companion block members and actualize them using a Java class that contains static members.

If you want to know more about this upcoming language feature, the corresponding KEEP proposal contains all the information.

Using experimental companions

Companion blocks and extensions are experimental features available starting Kotlin 2.5.0-Beta1. That means that you need to pass an additional compiler flag to use the feature:

-Xcompanion-blocks to allow companion blocks.
-Xcompanion-blocks-and-extensions to allow both companion blocks and extensions.

Using the second feature causes the compiler to produce pre-release binaries, which means libraries using companion extensions may not be consumed as dependencies until the feature becomes stable. This restriction does not apply to exposing companion blocks, although consumers of such blocks still need to enable the companion blocks feature.

What about my companion objects?

This leads to a natural question: What is the role of companion objects in a language with companion blocks and extensions? There are two answers to this question:

On the one hand, most usages of companion objects would be better served by companion blocks, so new code may prefer the latter to the former.
On the other hand, there are a few use cases that are only served by companion objects. For example, if your companion needs to implement a particular interface, companion objects are the only possibility, since they compile to a full-fledged class.

There’s no need to migrate, though. Companion objects are an integral part of Kotlin, and support for them is fully guaranteed.

If you prefer to move to companion blocks, removing the object keyword should be enough in most cases – but note that the project and any code depending on it need to be recompiled. Other tooling in the ecosystem may not be ready for companion blocks, although we’re trying to ensure major players provide this support as soon as possible.

The State of Kotlin in 2026 Report

Daria Voronina — Tue, 29 Sep 2026 12:38:29 +0000

In 2026, Kotlin turned fifteen. Over those fifteen years, Kotlin has built a mature ecosystem, been adopted by companies around the world, and established a large and active developer community.

Fifteen years is long enough to understand which technology trends lasted and which didn’t. This report looks back at Kotlin’s first fifteen years to see what they reveal about how the language matured, while answering questions like: “Is Kotlin here to stay?”, “Can Kotlin scale across platforms?”, and “How does Kotlin fit into the AI era?”

View Report

State of Kotlin in 2026

Today, developers worldwide use Kotlin across a diverse range of applications, including mobile, backend, and multiplatform. The language is also finding its place in the rapidly evolving AI space, where Kotlin’s strengths, like static typing, null safety, and coroutines, take on new relevance. Kotlin is actively participating in the shift toward AI-assisted development: Among surveyed Kotlin developers, 93% use at least one AI coding tool, while 81% already use or are likely to try AI coding agents. An equal share – 81% – say that AI-generated Kotlin code is fully correct or requires only minor fixes.

The State of Kotlin in 2026 report combines data from JetBrains research with independent industry data and real-world adoption evidence. Some findings confirmed what we expected; others challenged some familiar assumptions. While the language remains deeply established in Android development, more than half of Kotlin developers now report working on backend projects, highlighting how far its usage has expanded beyond mobile.

Together, these findings point to a broader story: Kotlin’s evolution isn’t just about growth, but about how diverse its usage has become, spanning backend, multiplatform, AI-assisted development, and more. At the same time, the developer community itself has grown more experienced.

State of Kotlin in 2026: Explore the highlights

See what the data tells us about how Kotlin has evolved and where its ecosystem stands today.

Read the full report → Download the State of Kotlin in 2026 PDF

A More Reliable Compilation Scheme for Kotlin Multiplatform Modules

Aleksey Zamulla — Mon, 28 Sep 2026 09:38:26 +0000

The current compilation approach to Kotlin Multiplatform projects works, but sometimes can lead to unexpected or hard-to-predict behavior. For example:

The IDE analysis disagrees with the compiler on an overload, type inference, or whether the code should compile at all – with the IDE being stricter than the compiler.
Your commonTest code can unexpectedly call something from a platform source set, breaking your assumptions.

With Kotlin 2.5.0-Beta1, we introduced an optional “separate compilation” approach to KMP that solves both problems: make the compilation results consistent with IDE analysis, and point more consistently to problematic calls of library code from common source sets. As a bonus, this approach enables us to implement incremental compilation for common source sets.

The separate compilation feature is Experimental and disabled by default. To opt in, add the following compiler option to your gradle.properties file (note the known issues):

kotlin.kmp.separateCompilation=true

Let’s look closer at the problem and the solution.

How multiplatform declarations are resolved within a module

Within a module, multiplatform code performs predictably:

// jvmMain
fun foo() {}

// commonMain
fun test() {
    foo() // Unresolved reference in IDE and during compilation
}

The compiler and the IDE agree: The code in commonMain is also compiled to other platforms, for example, to Kotlin/JS, and there might not be a fun foo() declaration in jsMain. Expect/actual declarations exist precisely to solve this problem: explicitly tie platform-specific declarations to common ones.

You would expect that the reference is also flagged as unresolved when the foo() function is declared in a dependency (a module in the same project or a binary artifact like Kotlin standard library or kotlinx-coroutines). Unfortunately, with the current compilation scheme that’s where the IDE and the compiler disagree.

How multiplatform declarations are resolved between modules

To understand where the problems stem from, let’s look closer at the current compilation setup.

Kotlin Multiplatform compilation setup

In a KMP project, a module with common code usually consists of several source sets: in the example above it’s a shared source set (commonMain) and a platform source set for a declared target (jvmMain for Kotlin/JVM).

With that setup, the compiler can produce the following artifacts:

A platform artifact for each platform source set like jvmMain – *.jar on JVM, *.klib on other platforms.
A metadata KLIB for each common or intermediate source set (like commonMain or nativeMain). A metadata KLIB contains all declarations from the compiled source set without bodies.

So where do the problems start?

Common code is compiled against platform artifacts; IDE disagrees

During compilation of a platform source set, both the code inside it (jvmMain) and the code in all relevant shared source sets (commonMain and other intermediate source sets) is compiled against the platform artifacts of its dependencies. Here code from commonMain has a chance to implicitly resolve to a jvmMain declaration.

If you expect this to happen, you’re probably fine. It would be more transparent and predictable, however, if commonMain could only call declarations from the dependency’s commonMain (as listed in the dependency’s metadata KLIB).

This is exactly what the code analysis in IntelliJ IDEA already assumes. As jvmMain declarations are not included in the KLIB metadata, IntelliJ IDEA reports the unresolved reference error when commonMain refers to something not declared in common code explicitly:

// lib/jvmMain
class Foo

// app/commonMain
fun main() {
    Foo() // Unresolved reference in the IDE, no error during compilation
}

The same mechanism is also in play with commonTest source sets, because tests also “depend” on main code: commonTest compiled against jvmMain can successfully call a declaration from platform code, instead of being restricted to declarations in commonMain. IDE reports the same unresolved reference problem:

// app/jvmMain
class Foo

// app/commonTest
fun main() {
    Foo() // "Unresolved reference" in the IDE, no error during compilation
}

Let’s see how separate compilation solves these problems.

How separate compilation solves the problem

KMP separate compilation makes the compiler behave stricter (aligning with the IDE expectation) when compiling common source sets of KMP projects. This makes the overall experience more predictable, although you may need to adjust your old code for stricter compile-time checks.

Let’s look at specific code examples and what happens to them with the switch between compilation schemes.

Red code in IDE, no error during compilation

When you turn on separate compilation, this code stops compiling, because compiler now resolves common code calls strictly using metadata KLIB declarations:

// lib/jvmMain
class Foo

// app/commonMain
fun main() {
    Foo() // Unresolved reference in IDE, now also a compilation error
}

The fix is to show an explicit connection: declare an expect class in lib/commonMain and make the platform Foo class an actual class:

// lib/commonMain
expect class Foo()

// lib/jvmMain
actual class Foo

// app/commonMain
fun main() {
    Foo() // ok
}

Same for commonTest: with separate compilation, the test code won’t resolve to a platform call in jvmMain. If that’s what you want to test, declare the corresponding expect in commonMain:

// app/jvmMain
actual class Foo

// app/commonMain
expect class Foo

// app/commonTest
fun main() {
    Foo() // Ok, calls Foo from jvmMain
}

IDE and compiler don’t agree on selected overload

When several overloads are declared in lib/commonMain and lib/jvmMain, the IDE currently interprets the call from app/commonMain differently from the compiler:

// lib/commonMain
fun foo(x: Any) = "common"

// lib/jvmMain
fun foo(x: String) = "platform"

// app/commonMain
fun main() {
    // "Go to declaration" on foo() jumps to lib/commonMain,
    // but at runtime "platform" is printed
    println(foo(""))
}

The IDE resolves the foo("") call to the declaration fun foo(x: Any) in lib/commonMain, as it assumes that common code can only depend on common declarations. But during the actual compilation app/commonMain currently sees both declarations and chooses the more specific overload fun foo(x: String). At runtime, “platform” is printed.

With the new compilation scheme, the call is resolved to fun foo(x: Any) in lib/commonMain and at runtime, and “common” is printed.

Unexpected type inference

A trickier problem can occur when the error is triggered not at the app/commonMain call site, but in platform code. In the following example the IDE actually sees no problem, but the JVM compilation fails.

actual classes are allowed to have different supertypes than their expect counterparts, so you can reasonably arrive at the following code structure:

// eventsLib/commonMain
interface Event { val name: String }

expect class ClickEvent(target: String) : Event { override val name: String }
expect class ScrollEvent(offset: Int) : Event { override val name: String }

// eventsLib/jvmMain — serialized events get queued or stored in a session
actual class ClickEvent actual constructor(target: String) : Event, Serializable { /* ... */ }
actual class ScrollEvent actual constructor(offset: Int) : Event, Serializable { /* ... */ }

// app/commonMain
fun currentEvent() = if (clicked()) ClickEvent("buy") else ScrollEvent(120)

fun report() = currentEvent().name // e: Unresolved reference 'name' only on the JVM

The IDE only matches commonMain declarations, which allows it to (correctly) infer the return type of currentEvent() as Event and resolve the .name reference.

On JVM, however, the library declares an additional supertype for each actual class. When compiling app for the JVM, the compiler currently resolves common code against the eventsLib JAR which has the eventsLib/jvmMain version of the classes. With the two supertypes, the return type inference for the currentEvent() call arrives at Any, which doesn’t have a .name, and the JVM compilation fails.

With the separate compilation enabled, app/commonMain code is resolved only against eventsLib/commonMain declarations. So when compiling the JVM target of app, the compiler already has the resolved common code and has inferred the Event return type for the currentEvent() function. The JVM compilation runs separately, doesn’t have to infer anything, and finishes successfully.

How to enable separate compilation

The separate compilation feature is Experimental and disabled by default. To opt in, add the following compiler option to your gradle.properties file (note the known issues below):

kotlin.kmp.separateCompilation=true

Known issues

For separate compilation to work correctly in KMP projects, it is important that authors of multiplatform libraries publish the metadata KLIBs. This is the default behavior for publishing tasks of the KMP Gradle plugin, but the new compilation scheme makes metadata KLIBs essential.

There are some known issues with KMP separate compilation that are still being fixed:

Some problems with commonization of cinterops (like KT-88178 or KT-41509). These are unlikely to affect an average KMP project, but enable the separate compilation mode with caution if you use C interoperability.
KMP modules with common source sets and a single declared target are not affected by separate compilation for now.
Various smaller issues such as KT-88148.

Send feedback

We’d be grateful for any feedback you have on separate compilation: leave a comment in the dedicated YouTrack issue.

Kotlin 2.4.20 Released

Daniel Csorba — Mon, 07 Sep 2026 11:30:57 +0000

The Kotlin 2.4.20 release is out! Here are the main highlights:

Standard library: Support for coroutine stack trace recovery, new functions for checking equality and uniqueness of collection elements, and new overloads for kotlin.test assertion functions.
Kotlin/Native: New Swift export features, improved incremental compilation, and automatically generated Package.swift files for SwiftPM dependencies.
Kotlin/Wasm: Changes to top-level require() calls in @JsFun declarations, improved companion object initialization order, and support for Wasmtime in the Kotlin Gradle plugin.
Kotlin/JS: A new DSL for browser testing, support for exporting suspend lambdas as async functions, and improved exportability of data classes.
Gradle: Support for Gradle 9.7.0 and improved reporting in the Problems API.
Build tools API: Support for new targets: Kotlin/JS, Kotlin/Wasm, and Kotlin metadata.
Kotlin compiler: The `kotlinr` runner command and a separate native image.

For the complete list of changes, see What’s new in Kotlin 2.4.20 or the release notes on GitHub.

How to install Kotlin 2.4.20

The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio.

To update to the new Kotlin version, make sure your IDE is updated to the latest version and change the Kotlin version to 2.4.20 in your build scripts.

If you need the command-line compiler, download it from the GitHub release page.

If you run into any problems:

Find help on Slack (get an invite).
Report issues to our issue tracker, YouTrack.

Stay up to date with the latest Kotlin features! Subscribe to receive Kotlin updates by filling out the form at the bottom of this post. ⬇️

Special thanks to our EAP Champions

Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More

Joffrey Bion — Thu, 03 Sep 2026 10:40:05 +0000

Kotlin Toolchain 0.12.0 is out. This release brings some long-awaited features: multiplatform libraries publication, a preview of Wasm application support, Compose Hot Reload from the command line, and more.

Read on for the details, and check the release notes for the full list of changes and bug fixes.

Additionally, klibs.io now uses the Kotlin Toolchain in production. A real backend and not a sample, it’s built on JDK 21, Spring Boot 4 (with Spring AI), PostgreSQL, and OpenSearch. We’ve converted nine convention plugins to Kotlin Toolchain templates, and two Gradle plugins with no built-in equivalent: Jib and Git Properties, which we’ve implemented as local Kotlin Toolchain plugins. Check out the sources yourself.

To get support for Kotlin Toolchain’s latest features, use IntelliJ IDEA 2026.2.1 (or newer). Make sure the latest version of the Kotlin Toolchain plugin is installed.

Try the Kotlin Toolchain

Kotlin Multiplatform libraries publication

Library publishing arrived in preview in 0.11, but only for JVM libraries. Starting with 0.12, multiplatform libraries work too, with exactly the same configuration:

product:
  type: lib
  platforms: [jvm, android, iosArm64, iosSimulatorArm64, wasmJs]

settings:
  publishing:
    enabled: true
    group: org.example
    version: 1.0.0

The Kotlin Toolchain publishes everything your users need to depend on your library from any of its targets: the common API, one artifact per platform, the sources, and the module publication metadata that lets build tools pick the right pieces automatically.

Cinterop bindings are supported as well. They are published both commonized and per platform, so your users get the same C API you compiled against without setting up interop themselves. The result is consumable from Gradle projects like any other multiplatform library.

For more details, see the documentation.

Note: Resources of Compose Multiplatform libraries are not part of the publication yet. Follow KTC-5698 for progress.

Better compliance with Maven Central quotas

Because of the new quotas on Maven Central publications that Sonatype will soon enforce, we made a few notable changes to reduce the number of files published by default:

Checksums of signature files (.asc.sha1) are not necessary and are no longer published.
Only the .md5 and .sha1 checksums are published by default now. If you need to continue publishing the .sha256 and .sha512 checksums, use settings.publishing.checksums: [md5, sha1, sha256, sha512].

Wasm application support

wasm-js/app modules can now be built into a ready-to-use web application.

Among the supported features are:

Running Wasm apps with the kotlin run command.
Customizing index.html and other resources.
Fetching transitive npm dependencies from Kotlin Multiplatform libraries.

More information on working with Wasm web applications is available in the documentation.

Terminal UI improvements

We are actively working to make the output of the kotlin command less verbose and more user-friendly.

Diagnostics

For example, here are some of the recent diagnostics improvements:

Tests in the status widget

Running tests are now visible in the status widget under the respective tasks and their suites. There are also short test execution statistics visible during the run.

There are more things to iron out, but we’ll get there.

IDE improvements

Compose preview support

Android modules and kmp/lib modules that have Android as one of their targets now support the Compose preview feature, powered by the androidx.compose.ui.tooling.preview.Preview annotation and the Android plugin.

Better support for Compose resources

The IDE now correctly recognizes Compose resources, updates Res classes on the fly, provides navigation, completion, and refactorings that update both XMLs and your code.

Android tooling improvements

Adding to the Compose preview support mentioned above, we have also brought support for more of the Android features you are accustomed to, such as:

Android Lint
Live Edit
Layout Inspector
Resources (R class) navigation and completion

iOS improvements

Starting with IntelliJ IDEA 2026.2.1, the experience of working with iOS applications should be closer to what you’re used to in Gradle projects.

The run configuration now lets you pick a device, configure Xcode options, and choose a debug/release configuration mode.

We’ve also fixed a few issues with Kotlin/Swift interoperability, which should be more stable now.

Inlay hints with coordinates of catalog dependencies

Catalog dependencies in module files and templates now have an inlay hint next to them displaying coordinates that each entry points to.

Better Compose Hot Reload support

We now properly support Compose Hot Reload from the command line using the kotlin run --compose-hot-reload-mode command.

General improvements

The very first reload is now much faster and the build should consume fewer resources.
The Restart the application action from the DevTools menu is now supported.

Compose Hot Reload MCP

We now support an MCP server for agents to interact with applications running with Compose Hot Reload.

To get started, add the following snippet in your mcp.json:

{
    "mcpServers": {
        "Compose Hot Reload": {
            "command": "./kotlin",
            "args": [
                "compose-hot-reload-mcp-server"
            ]
        }
    }
}

With this, agents can interact with, reload, restart, and view window snapshots, and dump the tree of composables. Read more about these capabilities here.

Other improvements

New recommended local dependency format using the `//` prefix

Previously, the only way to define local module dependencies was to use relative paths starting with the . (dot) symbol. This approach had several problems. For example, moving a module from one directory level to another required changing all the dependency paths, such as from../../foo to ../foo. And having a multitude of ../ in deeply nested directory structures generally made paths hard to read.

The new recommended way to define local module dependencies is to use project-root-relative paths starting with the // prefix. You might be familiar with this syntax from tools like Bazel. The // prefix represents the project root directory and can be used not only in the dependencies block but in any place that expects a path as well, for example, apply.

The old relative-paths approach still works for now.

This is a step toward allowing multiple modules with the same directory name.

Raised minimum JDK and Kotlin versions

Until now, the minimum JDK version supported by the Kotlin Toolchain was not clearly documented anywhere, and the build would just fail in different places if you used a JDK that was too old. There is now a clear diagnostic and a clear minimum: only JDK 17 and higher are supported to compile your code. You can still use settings.jvm.release to set a lower target if your code should be runnable on lower JREs.

The minimum Kotlin compiler version was raised from 2.1.10 to 2.2.20. This allows simplifying our code, and is in line with the new security support policy for the Kotlin standard library.

Updated default versions

We’ve also updated some of the default versions for built-in toolchains and frameworks:

Kotlin 2.4.10
JDK 25
JUnit Platform 6.1.3
KSP 2.3.11
Ktor 3.5.2
Spring Boot 4.1.0
DataFrame 1.0.0-rc01
Kotlinx.rpc 0.10.3

Try Kotlin Toolchain 0.12.0

To get started with the Kotlin Toolchain, check out our Getting started guide. Take a look at some examples, follow the tutorial, or read the comprehensive user guide, depending on your learning style.

Try the Kotlin Toolchain

To update an existing project, use the kotlin update command.

Share your feedback

The Kotlin Toolchain is still in Alpha and under active development. You can provide feedback about your experience by joining the discussion in the #kotlin-toolchain Slack channel (get invite: https://kotl.in/slack) or by sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of the Kotlin Toolchain!

Compose Multiplatform 1.12.0 Released

Elvira Mustafina — Wed, 26 Aug 2026 13:28:41 +0000

Compose Multiplatform 1.12.0 is out! This version brings new tooling for AI assistants, improvements to web resource management, and finer control over desktop window states.

Here are the highlights of this release:

MCP server for AI agents in Compose Hot Reload
Automatic font fallback for web
v2 version of the window and dialog API for desktop

For a complete overview of the changes, check out What’s new in Compose Multiplatform 1.12.0 or the release notes on GitHub.

Get Started with Compose Multiplatform

MCP server for AI agents in Compose Hot Reload

Compose Hot Reload now ships with an experimental Model Context Protocol (MCP) server that connects AI coding agents to your running application.

Using the MCP server, an agent can trigger reloads, take screenshots, inspect the semantic tree, simulate clicks and text input, and read application logs. In practice, this means the agent can verify the results of its own edits. It can confirm that the reload succeeded, inspect the rendered UI, catch a runtime exception, and iterate – all without you describing what’s on screen.

For the full list of available tools and instructions on connecting your agent, see the Compose Hot Reload documentation.

Try Compose Hot Reload

Automatic font fallback for web

Compose Multiplatform for web now handles characters that your application’s fonts don’t cover. When it encounters an unresolved character during rendering, it downloads the matching Noto font subset on demand and recomposes the affected text. As a result, Japanese, Arabic, Devanagari, and emoji render correctly without you having to bundle fonts for them.

Window and dialog API v2

This release introduces an experimental v2 of the API for WindowState and DialogState in the androidx.compose.ui.window.v2 package. It gives you finer control over how windows and dialogs are positioned and sized. You can:

Select the screen a window appears on.
Provide custom positioning and sizing logic, including logic based on the content’s intrinsic size.
Set minimum and maximum window sizes.
Position dialogs relative to their parent window.

The enhanced API also makes the asynchronous nature of window state changes explicit: It distinguishes the state you request from the state the window currently has.

For example, to center a window and give it a fixed size, use WindowPositionProvider and WindowSizeProvider:

val windowState = rememberWindowState(
    initialBoundsProvider = WindowBoundsProvider(
        positionProvider = WindowPositionProvider.CenteredOnScreen,
        sizeProvider = WindowSizeProvider.Fixed(DpSize(400.dp, 200.dp))
    )
)

With the API v2, you can also use WindowSizeProvider.Unconstrained to size the window to its content initially, while still letting that content expand with fillMaxSize() when the user enlarges the window:

WindowBoundsProvider(
    positionProvider = WindowPositionProvider.CenteredOnScreen,
    sizeProvider = WindowSizeProvider.Unconstrained
)

See the Window and dialog API v2 documentation for the full details.

Update your dependencies, try out the new APIs, and let us know what you think about Compose Multiplatform 1.12.0.

For everything that didn’t make it into this post, check out the full release notes or What’s new.

Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog

Kodee’s Kotlin Roundup: Shipaton 2026 Winners, Kotlin 2.5.0-Beta2, and KotlinConf 2027

Kodee-approved spotlight

Ship Kotlin Everywhere winners at RevenueCat Shipaton 2026

Start your next KMP app with Kotlin Toolchain 0.13

The State of Kotlin in 2026 report

KotlinConf 2027 is coming to Kraków

The Kotlin Multiplatform Contest is open: Win a trip to KotlinConf

Kotlin 2.5.0-Beta2 and Kotlin 2.4.21

The Kotlin compiler will require JDK 17 or newer

KMP library spotlight

Where you can learn more

YouTube highlights

Google Summer of Code 2026 With the Kotlin Foundation: Recap

Tail call support in the Kotlin/Wasm backend

Mapping the global Kotlin education landscape

What Makes a Great KotlinConf Proposal?

First-time speaker? Submit your idea anyway!

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Marcin Mycek. Product Manager, Kotlin Build Tools

Start with the story you want to tell

What do reviewers notice first?

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Write a clear and informative title

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Build your abstract around a clear journey

Sebastian Sellmair. Software Developer and KotlinConf speaker

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

The context

The challenge

Jodie Burchell. Developer Advocate and Data Scientist

The approach

The outcome

Chantal Loncle. Software Developer, Exposed, JetBrains

Think like an attendee

Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker

Make a familiar topic feel fresh

Chantal Loncle. Software Developer, Exposed, JetBrains

Keep the proposal relevant to KotlinConf

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Sound confident, but stay true to yourself

Marcin Mycek. Product Manager, Kotlin Build Tools

Marcin Mycek. Product Manager, Kotlin Build Tools

Show reviewers how you communicate

Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker

Choose the format that fits the idea

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Review the proposal before submitting

Chantal Loncle. Software Developer, Exposed, JetBrains

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

Your Kotlin story could take the stage

KotlinConf Recap: Lessons from Verifone’s Architect on Kotlin in Mission-Critical Payments

Aniket Bhattacharyea

Watch the KotlinConf 2026 talk

A Legacy Modernization Strategy and Business Case Playbook for Enterprise Kotlin Adoption

The world behind the terminal

Six ways one word breaks a payment system

The method: write the spec, then let the compiler check your work

1. Value classes for spec nouns

2. Validate factories

3. Non-null types at the boundary

4. Mask sensitive data by default

5. Give every state its own class, not just its own name

6. Immutability and named transitions

7. Delete the else branch

8. Choose the coroutine scope the spec implies

9. Model timeout as a domain outcome, not an exception

10. Make the tests something a regulator can read

What actually moved

Payments modernization without a rewrite

Migration is an investment decision, not a language preference

What is Yuri Geronimus’s core method, in one sentence?

Do you have to rewrite a legacy Java or C++ system to use these patterns?

Why doesn’t discipline or code review catch these bugs instead?

Further reading

Start Your Next KMP App With Kotlin Toolchain 0.13

How the Kotlin Toolchain simplifies getting started

Direct support for agentic workflows

What’s new in the 0.13 release

New project creation with `kotlin new`

New recommended local dependency format using the `//` prefix