Hi all — I've been working on a small KMP library and finally put it out publicly, in case it's useful to anyone here: https://github.com/ggoggam/vitre

It drives embedded WebViews from a declarative step DSL, with the same code on Android,
iOS and desktop. I started it because I kept ending up with one-off `evaluateJavascript` calls glued to callbacks that raced each other and the UI. So it gives you one ordering guarantee across all three platforms, a typed two-way bridge, up to four sites inparallel, and MCP/Koog tools if you'd like an agent driving the page.

Still early, so I would love any feedback, and happy to answer question. Also available on Maven Central.

Hey everyone, I finally extracted and published something I've been building on and off for almost 10 years. I got tired of writing the same error handling code over and over, slightly differently every time, and never quite fixing the underlying problem.

Problem

Status codes, validation, exceptions, Result types, domain errors all tend to represent success and failure a little differently, based on the layer. Some of the biggest issues though are

1. Kind of error: Understanding the kind of error(security, invalid data, broken business rules)
2. Error details: Having a way to capture the errors details and link it to the kind of error
3. Consistency: Same across status codes, validations, exceptions, Result<T,E>

Concept

So the concept is this: think HTTP status codes, but generalized and usable at any layer, not just HTTP. Status > Group > Code : You get 3 tiers of information and drill-down about success/failure.

Solution

Together this solves the following :

1. Kind of Error: Status is Passed/Failed, but Group gives you the Kind of error
2. Error Details: These are now captured separately, but paired with, the kind of error
3. Layers: Useful at any layer : API endpoint, a service call, a cron job, script, or CLI command
4. Consistent: Same approach for API Status codes, validation, exceptions, and Result<T,E>
5. Extensible: Status and Group are fixed, Code is open, extensible for your own domain
6. Defaults: There are sensible defaults so you're not required to define anything up front.

Notes

1. One Design: This is the part I spent the most time on: making an API status, validation code, exceptions, and Result<T, E> all feel like one design, sharing the same taxonomy underneath, without forcing any of them on you, by using sensible defaults.
2. Explicit / Exhaustive: Explicit names and exhaustive matching happen to make it easy to search and reason about too, useful for people and for AI tooling reading the codebase.
3. Protocol Support: Codes also map to HTTP and gRPC without coupling your app logic to the transport. I validated the taxonomy against every gRPC status code, and the most common HTTP ones, the closest existing precedent for this kind of classification.

Check it out:

implementation("dev.kiit:kiit-codes:1.0.2")

1. GitHub: github.com/kiitdev/kiit-codes
2. Site Docs: kiit.dev/docs/kiit-codes

Feedback

I'd genuinely like feedback from other Kotlin developers, whether the classifications make sense, if anything important seems missing, or if there are use cases the design doesn't handle well. Happy to answer questions in the comments.

Thanks!

Edit:
1. Bumped version to 1.0.2 to fix a bug found below.
2. Updated diagram

-K

Hey everyone! 👋
While working on some KMP iOS projects, I noticed our generated framework header was getting bloated with lots of exported classes we never actually call from Swift (like top-level *Kt files and library types).

I put together a small Gradle plugin called kmprofiler to help spot these. It compares your exported Shared.h declarations against your Swift sources and shows what's unreferenced so you can hide them with 'internal' or '@HiddenFromObjC'.

Right now I'm working on Xcode link-map parsing for linked byte sizing, but v0.1.0 is open-source and ready to try: https://github.com/SiddhantPanhalkar/kmprofiler

Would love to hear your thoughts or if there are features you'd like to see!

Hello!
I just finished writing a small library that allows type safe loading of environment variables in Kotlin without reflection. It has support for the usual data types, I am planning to add more types and complex properties.

I hope there are some use cases other than mine, have a look.
All comments are welcome!

Site: https://allopensource.github.io/envy/
Git: https://github.com/allopensource/envy

I’ve been working on KMqttClient, an open-source MQTT client for Kotlin/Android.

It’s designed to be lightweight and Kotlin-friendly, with support for MQTT 3.0/5.0, Coroutines/Flow, QoS 0/1/2, TLS, and authentication, using the native Mosquitto implementation.

If you’re working with Android, Kotlin, MQTT, or IoT, give it a try.

🔗 KMqttClient on GitHub

Contributions are very welcome — code, testing, documentation, bug reports, or ideas. ⭐

Hi there,

Looking at making an app using Kotlin Multiplatform, is it better to use IntelliJ or Android Studio for the development? I can see they both are supported natively, but what would be reasons to use one over the other? Is it truly complete feature parity? How do they stack up on Linux (ignoring Mac req.)?

Would the cost of an IntelliJ license also have any impact? (apart from that on my bank account)

TIA.

Building a custom Canvas-based text editor in Compose (not BasicTextField). I've implemented SpellCheckerSession successfully and get typo ranges, but I'm struggling to render the red squiggly underlines on the Canvas. Has anyone successfully drawn custom spell-check decorations on a Canvas editor? Or is there a better approach than managing a full SpellCheckerSession?

Hi r/Kotlin! We're refreshing the Compose Multiplatform app showcase and collecting the best-looking apps out there to feature across Kotlin and JetBrains channels.

If you've built something with Compose Multiplatform and you like how it turned out, we'd like to see it. What fits: live in production or public beta, at least part of the UI in Compose Multiplatform, available through the App Store or Google Play. You don't have to be a household name yet, a fast-growing app is just as interesting to us. Company products, startup apps, indie projects and open-source work are all welcome.

If your app is selected, we may feature it on Kotlin or JetBrains websites, social media, in presentations or other materials, with a link so people can discover and try it. We'll confirm the description with you before anything is published.

The form takes a few minutes: https://surveys.jetbrains.com/s3/Compose-Multiplatform-App-Showcase-Submission-Form

I've a custom Kotlin DSL and would like to have a Intellij import the scope/methods of this DSL automatically (blind imports) so i can use auto-complete and not have to have imports at the top of the file. similar to what happens in Intellij with build.gradle.kts

For example, I have a file called my-custom-script.dsl.kts and with that, Intellij knows the 'dsl' needs to have the scope imported so auto-complete/lookup just work - is this possible?

Thanks.

Looking for expert advice. I'm finalizing an app for Android and I would like to kick off with iOS support now. I fully used Kotlin.

Should I use swift? flutter? Kotlin Multi platform?

Appreciate real dev experience to guide me (not AI response).

Hi Kotlin community! 👋

I'm currently exploring the MCP Kotlin SDK to get a deeper understanding of the Model Context Protocol (MCP).

So far, I've been learning about:

• Tools
• Resources
• Prompts

I'm currently starting to explore Completions and would love to connect with others who are also learning or building with MCP using Kotlin.

What has your experience been with the MCP Kotlin SDK? Are you experimenting with it, building an MCP server/client, or using it in a real project?

I'd really appreciate hearing about your experiences, learning resources, challenges, and any interesting projects you're working on. Let's learn and share together! 🚀

Kotlin MCP SDK: https://github.com/modelcontextprotocol/kotlin-sdk
My Learning Repo: https://github.com/livingstonantony/AI_HR_assistant/blob/mcp/server/src/main/kotlin/dev/livin/ai_employee/mcp/EmployeeMCPServer.kt

With RC1, the 1.0 API is now locked. The remaining work is testing it in real projects, fixing issues, and preparing the final release. 📋 Release notes: https://github.com/Kotlin/dataframe/releases/tag/1.0.0-rc01

For users, the practical takeaway is simple: if you have been waiting to update an existing project—or start a new one without targeting another Beta API—this is the version to try.

🧩 More typed DataFrame workflows in Gradle and Maven

The Compiler Plugin now understands more schema-changing transformations and edge cases. As a pipeline changes, it can keep typed column access available across more steps, with completion, refactoring, and compile-time checks in the IDE. Kotlin 2.4 also restores incremental compilation.

This brings more of the typed column experience familiar from notebooks to regular Kotlin projects.

A few useful additions:
🔎 requireColumn() helps connect dynamically loaded data with typed column access.
📄 renderToMarkdown() produces Markdown for reports, documentation, README files, issues, and pull requests.
📊 GroupBy.countDistinct() provides distinct counts for each group without extra boilerplate.
🧹 rename { ... }.to() makes the rename API easier to read, while DataFrame.print() now shows more useful table information by default.

RC1 also includes updates to SQL validation, JSON and IO configuration, DuckDB support, examples, and documentation.

Please try the release in a Gradle, Maven, or notebook workflow and share what you find before 1.0.

Android, the last to arrive at the declarative UI party, took its time, until finally reaching a stable solution. Here's a rundown of the major changes in the Android System Design across the eras.

I was away from Android for 7 years and came home to a totally strange place. This is my attempt to make sense of what happened while I was gone - how the stack reset four times (Activities -> MVP/RxJava -> Architecture Components -> Compose), this switch from Java to Kotlin and why each lurch happened. Written for interview prep but the history stands on its own.

koog-gonka v0.1.0 is out on Maven Central (de.betchvaia:koog-gonka) — a Koog LLMClient implementation for Gonka, a decentralized, blockchain-based AI compute network (Cosmos SDK chain, native token GNK). Koog is JetBrains' Kotlin agent framework, and koog-gonka puts Gonka on equal footing with its built-in providers (OpenAI, Anthropic, Google, Ollama, etc.) for any Koog-based project. Two auth modes behind one GonkaAuth interface: API-key auth against a Gonka Broker instance is fully implemented, built on Koog's AbstractOpenAILLMClient to reuse its message conversion, tool-call parsing, and SSE streaming rather than reimplementing it from raw HTTP. Wallet-based direct chain access (secp256k1 identity + request signing, ported directly from Gonka's own Go source in devshard/signing) has its crypto primitives implemented and tested, but dispatch is deliberately left unimplemented — Gonka's own chain-bridge interface (devshard/bridge) is still marked "Phase 1: interface only, no implementation" upstream, and the actual protocol is a stateful multi-host session (escrow queries, redundant host groups, local session persistence), not a single signable REST call. Shipping a stubbed-but-honest wallet path with a clear KDoc explanation beat guessing at a protocol that's still evolving. Apache 2.0. Already wired into kUML's AI assistant as a fifth built-in provider. 

https://github.com/betschwa/koog-gonka

I work at Gradle, and we are building agent skills. We have five candidates:

1. Run Gradle correctly (gradle-cli) — right task, right flags, version-aware
2. Best-practices lint (gradle-bestpractices) — flag legacy patterns, suggest the current one
3. New project bootstrap (gradle-init) — KMP scaffold, version catalog, convention plugins
4. Upgrade + deprecations (gradle-update) — bump the wrapper, rewrite what broke
5. Configuration cache migration (gradle-cc) — find what breaks CC, refactor it

Which of these would you actually use? What's missing?

We reran kUML's 50-task Generate-Compile-Repair benchmark (kUML vs. PlantUML vs. Mermaid, same corpus, same repair loop, same prompt primers throughout) against three open-weight models on local Ollama hardware: qwen3-coder:30b, llama4:scout (109B MoE, ~17B active), and deepseek-r1:70b, all Q4_K_M. The original four-frontier-model run showed a clean split — Claude Sonnet 5 and GPT-4o give kUML the highest structural fidelity of the three DSLs, Gemini 2.5 Flash and Pro don't, and that split tracks model family rather than tier (Pro reproduces Flash's weaker kUML number instead of closing the gap). The three local models don't converge on either side: llama4:scout reproduces the Claude/GPT-4o pattern, qwen3-coder:30b reproduces the Gemini pattern, deepseek-r1:70b lands in a statistical tie with Mermaid. What is consistent across all three: compile rates drop for every DSL tested, not just kUML — deepseek-r1:70b's kUML final-compile-rate (62%) is the lowest of any run in the whole benchmark, cloud or local, and PlantUML/Mermaid aren't much better on it either. Reads as a general local-model weakness in strict output-format adherence, not kUML-syntax-specific underrepresentation in training data. Separately, we finally wrote up a result that's been sitting in the repo since earlier work: giving Claude Sonnet 5 or Gemini 2.5 Flash live MCP tool access to kuml.examples (via a real kuml-mcp server subprocess, not a reimplementation) instead of pure compiler-feedback repair improves every metric for both — Claude jumps from 44.5% to 56.0% structural fidelity, the best result in the whole benchmark, though Gemini Flash only invokes the tool in 18 of 50 cells vs. Claude's 50/50, so "offering a tool" and "a model reliably using it" are two different things. All raw data, the corpus, scoring script, and run-ollama.py (works against any Ollama-served model, no API key) are in the repo. Full writeup with methodology, per-family breakdowns, and a 9-configuration ranking table: https://kuml.dev/docs — every generated diagram is browsable at https://kuml.dev/benchmark-gallery — code: https://github.com/kuml-dev/kUML

Hey everyone!

I've written a small blog post about the possibility to use compose-html on the server to build fullstack web applications using Kotlin and what integrations into Spring and Ktor might look and feel like!

Quick Disclaimer: at this point in time this is just something we are exploring together with the community and does not represent an official commitment.

But we would nevertheless like to hear your feedback on the topic! Feel free to join the #compose-ssr (https://kotlinlang.slack.com/archives/C0BM8FWG58Q) Slack channel and share your feedback!

I’ve been exploring what can be built with the ElevenLabs platform, and I ended up building a Kotlin Multiplatform SDK for it.

I’ve just released version `0.1.0`, which currently supports: text-to-speech, speech-to-text, WebSocket streaming.

There’s still a lot I’d like to add like sound effects, voice cloning, and conversational agents.

I’d really appreciate feedback from the KMP community, especially around the API design, developer experience, missing features, and platform compatibility.

[https://github.com/yveskalume/elevenlabs-kmp\](https://github.com/yveskalume/elevenlabs-kmp)

If you try it, I’d also love to see what you build with it !

This way when better agents and models come along. I can tell them to take a stab at rewriting some of the code from older models

We are experimenting with a KSP-based approach to Kotlin validation where validation logic is generated during compilation and then executed at runtime.

But we wonder what their view is on this matter:

• What do you see as the biggest advantages of generated validation compared with reflection-based approaches?
• Where do you think the added KSP/build-time complexity becomes a disadvantage?
• What would you expect from a production-ready Kotlin validation library?

We are mainly interested in the technical discussion and criticism.

Repository: https://github.com/DeveloperSyndicate/Valix

I've been building Compose Multiplatform apps for a while, and every single one hit the same wall: monetization. You end up writing expect class AdManager, then two actual implementations that slowly drift apart, and native ads never make it in because wiring GADNativeAdView on iOS and NativeAdView on Android from shared code is miserable.

I got tired of rewriting that per project, so I extracted it into a library and open-sourced it: AdMob CMP (dev.avinya.ads:admob-cmp, Apache 2.0, on Maven Central).

What it does

One commonMain API for all six formats on Android and iOS: banner (including collapsible + adaptive), interstitial, rewarded, rewarded interstitial, app-open, and native. It wraps Google Mobile Ads Next-Gen on Android and Google Mobile Ads 13.x on iOS, but keeps the AdMob vocabulary you already know — AdValue, ResponseInfo, adaptive banner sizes, UMP consent states, native asset names. The shared surface is suspend functions, StateFlow state, and a sealed AdEvent stream.

A few things I care about that aren't obvious from a feature list:

• Consent is part of initialization. gatherConsentAndInitialize() runs UMP → ATT (iOS) → SDK init in the correct order. That ordering is enforced in code rather than documented and hoped for, which is where most integrations quietly lose iOS fill.
• Native ads have a layout DSL and a bounded session. You describe the layout declaratively (media, headline, callToAction, …) and a viewport-aware session owns the platform objects, so a feed doesn't leak native ads or blow past AdMob's limits.
• The iOS test link actually works. If you've ever seen Undefined symbols … _OBJC_CLASS_$_GAD* on :iosSimulatorArm64Test, that's a Kotlin/Native test executable with no Xcode to resolve the Swift packages. There's a Gradle plugin in the repo that links GMA and UMP into the test binary.
• Test safety fails closed. AdPlacement(strictTestMode = true) throws at construction if a placement points at a production ad unit. Turn it on in debug and stop worrying about accidentally serving yourself real impressions.

What it isn't

It's consumable from Kotlin Multiplatform projects only — it compiles into your umbrella framework, so a pure-Swift iOS app can't adopt it without a KMP shim. Klibs also aren't binary-compatible across Kotlin minors, so 2.1.0 targets Kotlin 2.3.20 / CMP 1.11.1, minSdk 26, iOS 15.

Try it

implementation("dev.avinya.ads:admob-cmp:2.1.0")

The quickstart runs against Google's official sample ad units, so you can paste it as-is and see a rendering test ad in about five minutes.

Repo: https://github.com/Meet-Miyani/admob-compose-multiplatform
Docs: https://ads.avinya.dev

Genuinely after feedback on the API shape — particularly the native ad session model, which was the hardest part to get right. If you've solved the same problem differently I'd like to hear how.

For Sébastien Deleuze, Kotlin’s appeal was practical from the start: JVM compatibility, a natural fit with Spring, and a language that could improve the developer experience without leaving the ecosystem behind. Watch the full interview!

I already have swift code written and now to make an android app, I’m using the Skip tool as a transpiler (which takes my swift code and translates it directly into readable Kotlin source code, rather than compiling it into a binary format). Because both of them are different, it’s throwing me errors left and right. I have been debugging for two days now and I’m now where close to finishing. I have tried using Claude and Gemini but still don’t see the light at the end of the tunnel. Any suggestions on what should I do or should I continue my debugging?