KotlinConf 2026 — Day 1 Impressions

KotlinConf 2026 opened today at the ICM, Internationales Congress Center Messe München. Day one ran the full range, from low-level coroutine internals to the shape of where the language is going. From Compose rendering optimisations you can apply next week to a look inside how Google rebuilt the search backend on Kotlin coroutines.

Here are the highlights of the talks I managed to catch.

Run, Kotlin, Run

Marc Reichelt

A lightning talk... that did exactly what it says on the tin. Move fast, cover ground, and leave you slightly energised.

Marc ran through the full spectrum of places Kotlin can execute today. JVM, native, JavaScript, WebAssembly.

The WASM story in particular is a worthy mention from this session. Kotlin/Wasm has matured considerably and the pitch of "one language, every runtime" is getting harder to dismiss as fluffy aspiration. I recall WASM based talks during KotlinConf 2025, and this particular talk made it feel less like a roadmap item and more like the present tense.

Opinionated Ktor Services

Simon Vergauwen

In my naive opinion, Ktor's unopinionated nature is both its appeal and its trap. The framework gives you the pieces but does not tell you how to assemble them. Simon's talk was a useful corrective, a practitioner's view of where the decisions actually land when you build real services with it.

A lot covered here, and early morning caffeine was started to wear off, so I was grateful that the talk was engaging ☕

Dependency injection approaches, code organisation, third-party SDK integration, testing strategy, and automatic API documentation generation. None of it is rocket science, but having someone work through the trade-offs out loud is its own bucket of usefulness.

Ktor projects tend to develop opinions anyway. Better to develop them deliberately.

Breaking Frozen Frames: Phased Rendering for Compose

Sinan Kozak

This was one of the more immediately applicable talks of the day. The problem is familiar to anyone who has built feature-rich Compose screens. The entire composition renders in a single pass, which means users stare at a blank screen until everything is ready. On complex screens, that can mean 1,000 to 2,000ms of nothingness before anything meaningful appears.

Sinan's solution, Phased Compose, splits the composition into deterministic steps, each rendering its own phase progressively. Skeleton loaders appear immediately, then sections fill in as they complete.

The result is not just faster in the raw numbers (25% reduction in frozen frames, 2.5% reduction in time-to-interactive from home screen) but feels faster. A skeleton loader communicates that something is happening, which changes the user's experience and perception of the wait even when the absolute time is similar.

Worth noting is that PausableComposition and lazy layouts do not solve first-frame jank for non-scrolling UI. Phased Compose fills that gap in a general, predictable way without timers or workarounds.

I'm the opposite of a subject-matter expert for mobile development, but user experience (good or bad) is a constant parallel in any rendering medium.

Bringing Native iOS Feel With Compose Multiplatform

Mohamed Ben Rejeb

A quick demonstration of Calf, Compose Adaptive Look & Feel, an open-source library that maps Compose components to their native platform equivalents. Material on Android, Cupertino on iOS, from a single codebase.

The demo was a Reminders-style app built on Kotlin Multiplatform Compose that genuinely looked at home on iOS, which is harder to pull off than it sounds. If you are an Android developer curious about KMP but worried about the UI gap, this is worth a look.

How Google Search Runs on Kotlin Coroutines

Sam Berlin & Alessio Della Motta, Google Search Infrastructure

This was the talk of the day for me, and it earned that.

Google Search routes every query through server-side Kotlin. That sentence deserves a moment. The move was driven by the demands of AI-native generative results, where the answer is not fully known upfront and streaming becomes a first-class concern rather than an afterthought. The old model of "compute everything, then return" does not survive contact with generative AI at search scale.

The team built on top of the JVM rather than replacing it, introducing an internal interface description language called QFlow that connects asynchronous data definitions. Developers implement business logic in Kotlin and QFlow handles the graph of dependencies and the streaming of results. The choice of Kotlin was deliberate. Suspend functions and coroutines with pluggable dispatching, the Flow API for streams, and code that people actually find enjoyable to write. That last one matters more than it gets credit for.

Interesting war stories from the presenters. Debuggability with coroutines is genuinely hard, that I know from direct experience. Stack traces are unhelpful, cancellation handling has sharp edges, and orphaned coroutines are easy to create and hard to find.

The team built enhanced tooling around QFlow stacks to surface these. The honest acknowledgement that coroutines at scale require real investment to debug well was refreshing to hear from people operating at this size.

My conceptual understanding here was that the team effectively built a meta-language on top of Kotlin, which is hyper-optimised for coroutines specifically and had some syntactical sugar that is closer to C++ language features.

The warm and cold flow distinction in QFlow was also worth noting. Cold flows re-execute their sources, which has meaningful implications at google.com/search scale, and the team has had to think carefully about where each pattern belongs.

Always refreshing to see an industry giant demonstrate novel problem-solving to long-standing problems.

Why AI Agents Never Scale

JetBrains (Koog team)

A birthday and a warning in the same talk. Koog, JetBrains' Kotlin-native AI agent framework, turned one year old, and the team used the occasion to announce integrations with Spring Boot, Spring AI, and AWS AgentCore, as well as on-device Google model support for Android.

The "why agents never scale" framing was the more interesting thread. The argument is that naive prompting produces agents that are impressive in demos and fragile in production. The proposed corrective is LLM domain modelling, giving agents structured awareness of what tools they have, when to use them, and where their authority ends. The example walked through a customer support flow. In the diagnostic phase, the agent had access to conversation and read tools only. In the resolution phase it gained write access. The guardrails are structural rather than prompt-level, which is the right instinct.

The broader point is one of the industry is still working out. Scaling agents is not primarily a model capability problem, it is an architecture problem. Koog is betting that Kotlin's type system and the discipline of explicit tool definitions is part of the answer.

The Lord of Collection Functions

Ben Kadel

Ben framed a walkthrough of Kotlin collection functions as a Lord of the Rings epic, complete with Center-earth under threat from the imperative evil of the Dark Lord For-ron, and a fellowship of developers tasked with restoring functional purity to the realm.

Indeed.

As absurd as it may sound (deliberately so, I assume), underneath the theatre was a genuinely useful survey of what Kotlin's collection API can do. Map, filter, fold, groupBy, partition, the full cast of characters, each introduced at the moment the fellowship needed them to defeat whatever algorithmic oppression stood in their path. Walking to Mordor via a series of well-chosen collection transforms is, it turns out, a surprisingly effective teaching device.

Props to Ben for commitment to the bit. All without letting it get in the way of the substance.

Suffice to say, Kotlin based performance theatre is harder to pull off than it looks.

That was day 1. As for night 1? When in Rome Munich! 🍻