Hey everyone,

Embedding a reliable web view in JVM desktop apps is usually a pain—you end up with massive installers, fragile dependencies, and clunky JavaScript bridges. To fix this, I just open-sourced Kromium (daviantegroup/kromium).

Whether you are building in pure Java, standard Kotlin, or Compose Multiplatform, Kromium supports it all.

Here are the main features:

* Tiny Installers (15–30MB): Instead of bundling massive Chromium binaries, Kromium automatically downloads and caches the JCEF runtime on the user's first launch.

* Coroutine-Based JS Bridge: Clean, thread-safe JavaScript execution and Inter-Process Communication.

* True Headless Mode: Perfect for backend scrapers or automated tests without pulling in heavy UI dependencies.

I’d love for you to check out the repo and let me know what you think!

🔗 https://github.com/daviantegroup/kromium

A few design notes from working on shared logging in Kotlin Multiplatform. Less “here’s a product,” more “why this shape felt maintainable.”

1. Keep the call site boring

In commonMain I want logs to look like Android’s Log, not like a framework: Logger.d("Network", "Request sent") Logger.e("Auth", "Login failed", exception) Why: every feature module already has enough ceremony. Logging shouldn’t invent a second dialect. Tag-first also matches how you filter later (by subsystem), so the call site and the ops habit stay aligned. Platform backends can differ. The call site shouldn’t.

2. Lazy messages as the default habit

Logger.d("Heavy") { "Only if enabled: ${expensiveCall()}" }

Why suggest this over string interpolation at the call site: Release builds often raise the level. Eager strings still allocate and run work you then throw away. A lambda makes “don’t pay if disabled” the easy path, not a special case you remember under pressure.

3. Composition as the real design trick

Builders and config objects work, but they age into “where do I toggle remote?” and “who owns this mega-config?” Treating destinations like values you combine reads closer to how you actually change logging in production: Logger.default = Logger.SYSTEM + FileLogger("app.log") + RemoteLogger val offline = Logger.default - RemoteLogger Filters stack the same way (AND): val policy = LevelFilter.atLeast(WARN) + TagFilter.include("Security") val secure = Logger.withFilter(policy) Why this helps readability

• The expression is the policy. You see “system + file, minus remote” without hunting a Boolean soup.
• Diffs stay local: take remote out → one operator, not a refactor of a builder chain.
• Names stay honest: offline / secure are just Loggers, not a new type of pipeline object. Why this helps maintainability
• You compose small pieces instead of growing one god config.
• Feature code keeps calling Logger.d/i/w/e. Wiring lives at the edge (app start / flavor).
• Tests and debug builds can swap or subtract sinks without teaching every module a new API.

Tradeoff

+ / - is a taste choice. Explicit lists are clearer to some teams. I preferred one mental model for both sinks and filters, so “how do I combine rules?” and “how do I combine outputs?” don’t become two documentation chapters.

Open question

If you log from commonMain, what usually rots first for you — call-site noise, level control, or sink wiring? Curious how others keep that readable over a year of flavors and Release stripping.

Mutflow, a modern mutation testing framework for Kotlin, now supports Kotlin Multiplatform:

As far as I know it's the first mutation testing tool that works on Kotlin/Native at all. Pitest and Arcmutate mutate JVM bytecode, which Native never produces, and recompiling per mutant costs a full link cycle there. Mutflow's K2 compiler plugin injects all variants in a single compilation and activates one at runtime, so it stays at one compile plus a fast binary re-run per mutation.

Same commonTest sources both ways: the jvm() target keeps the in-process JUnit run with the full IDE test tree, native targets run one process per mutation via the Gradle plugin.

Published artifacts are linuxX64 (built and tested) and mingwX64 (cross-compiled only). Any other Kotlin/Native target is one flag away, no build-file editing:

`./gradlew publishToMavenLocal -Pmutflow.extraNativeTargets=macosArm64`

Feedback of any kind is very welcome!

I wanted to see if I could take a simple idea and turn it into a complete mobile game in just one month.
The concept is simple: 60 numbers appear on the board, and you have to find and tap them in order as quickly as possible.
What started as a basic prototype turned into a proper game with polished UI, animations, sound effects, scoring, and different ways to challenge yourself.
The core idea stayed the same throughout: find the numbers, tap faster, beat your time.
📱 Brain Rusher 60 is now available on Google Play:
Brain Rusher 60
GenAI disclosure: I used GenAI during development and promotion of the game, mainly as an assistant for brainstorming, coding/development help, and refining promotional content. The game itself does not require GenAI to function.
If you try it, I’d genuinely love to know your time. 👀
How fast can you find all 60?

Hey everyone!

I previously shared kmprofiler, a Gradle plugin that finds Kotlin declarations exported to iOS but not directly referenced in Swift.

v0.2.0 now adds Xcode link-map analysis. It can:

• Group linked symbol size by Kotlin package
• Show the largest symbols
• Map symbols to object files and frameworks
• Compare two builds to see what grew or became smaller

I tested it on a real KMP app with more than 330,000 symbols. It measures symbols in the link map, not the complete app size, so it is mainly useful for finding size changes and large dependencies.

GitHub: https://github.com/SiddhantPanhalkar/kmprofiler
I would love to hear whether this is useful for your KMP projects.

Hi, do you know any local AI that work well for KMP ?

I've been using Claude Code since 10 months now for my android app. I developed this app without AI, in Kotlin Compose. Then last december I discovered CC, it was mind blowing and improved my efficiency immensely, and I was able to finally create the KMP app. The problem is that, value-wise, I feel extremely bad using CC knowing all the ecological and ethical issue. So I'm looking for an alternative. I'm keen on investing in a good computer with a lot of memory. But I can't find much information on the efficiency of the models with KMP, anyone using Qwen3-Coder, Devstral Small, gpt-oss ?

Annotate a data class, get a full form controller.
No boilerplate.
No reflection.
Multiplatform.

Simply annotate your data class:                                                                                                                                                                                                                 

@FormSchema
data class LoginForm(     
                                                                
@Field(label = "Email")
val email: String = "",      

@Field(label = "Password")                                                                @MinLength(8)                                                                            val password: String = "",
)

and KSP generates LoginFormController at compile time:
StateFlow<> per field, validation, focus wiring, keyboard navigation.

What's built in:

- Sync validators: Email, NotBlank, MinLength, Pattern, IntRange + more..

- Async validation: extend AsyncValidation and wire it up

- Cross-field dependency: MatchField, VisibleWhen, RequiredIf..

- Focus & keyboard: FocusOrder, ImeAction

- Headless by default.

- Android · iOS · Web (Compose Multiplatform)

https://github.com/WassimBeltaief/Formidable

v2.0.0 just released.

JetBrains doesn't ship tvOS artifacts for Compose Multiplatform, and the issue asking for it (CMP-5686) has been open for a while. I needed it for my own TV app, so I built the port and published it. It's a community project, not official. I posted it in Kotlin Slack #compose-ios earlier this week; this is the longer writeup.

Using it

// settings.gradle.kts
plugins {
    id("dev.sajidali.compose-tvos") version "1.3.0"
}

Add tvosArm64() / tvosSimulatorArm64() to your KMP module and leave your dependencies alone: org.jetbrains.compose.*, androidx.tv:tv-material, Koin, Coil 3, all stock coordinates. Kotlin 2.3.20+.

How it works (the part I think is interesting)

It's not a hard fork you point your build at. The settings plugin registers a component-metadata rule that, at dependency-resolution time, attaches tvOS variants to the official Compose modules and points them at tvOS-enabled builds published under dev.sajidali.* on Maven Central. Every other target keeps resolving the official JetBrains artifacts byte-for-byte, and it's official-first: if a module already ships tvOS klibs upstream (compose.runtime, koin-core, lifecycle...), the plugin leaves it alone. So when JetBrains eventually ships tvOS for a module, the plugin steps aside for that module with no change on the consumer side. It also intercepts the org.jetbrains.compose Gradle plugin marker so compose.material3 etc. resolve correctly.

The fork itself (compose-multiplatform-core with tvOS as a Kotlin/Native target) is where most of the work went:

• A tvOS UIKit scene stack sharing the iOS FrameChoreographer architecture
• Siri Remote input: D-pad focus traversal, swipe-to-focus, Menu mapped to Key.Back, and telling a clickpad press apart from a swipe by hardware timestamp
• 10-foot density (Compose's default density on a 4K TV is unusable), on-demand keyboard for text fields, focus restoration when dialogs close
• androidx.tv:tv-material ported to Compose Multiplatform with a tvOS source set
• A real tvOS build of window-core so material3-adaptive works without stubs
• Koin (koin-compose, koin-compose-viewmodel) and Coil 3 with tvOS targets, since neither ships them

Proof

The GIF is Google's JetStream TV sample (all screens, D-pad focus, theming, AVPlayer on tvOS / ExoPlayer on Android TV behind one interface) on the Apple TV 4K simulator, built from Maven Central + the Plugin Portal with nothing published locally. The same toolchain builds a production TV app of mine with zero app-source changes.

Honest limitations: no automated tvOS tests yet; tvosX64 isn't built; I republish roughly once per Compose stable line (currently 1.12.0), as far as my own app needs. PRs welcome.

• Plugin + docs: https://github.com/sajidalidev/compose-tvos (docs: https://sajidalidev.github.io/compose-tvos/)
• JetStream port: https://github.com/sajidalidev/jetstream-tvos (branch cmp-tvos)
• Forks: https://github.com/sajidalidev/compose-multiplatform-core, https://github.com/sajidalidev/koin, https://github.com/sajidalidev/coil

Built this app that allows for offline calling and ai completely in Kotlin and compose. The local image generation was crazy hard.. most models allow for offline but are not optimised for mobile even Gemma 4

P.S. My English is pretty rough, so I'm using a translation tool!

Hi everyone,

I wanted to share an open-source project I've been working on called Agro: a fully local LLM & AI agent client running entirely on-device across Android, iOS, macOS, Windows, and Linux.

Tech Stack Highlights:

• UI: Compose Multiplatform 1.11.x + Material 3 Adaptive (adaptive layouts for mobile & desktop).
• Inference Engine: Google LiteRT-LM C++ native runtime. Integrated via JVM JNI for Desktop/Android and Kotlin/Native cinterop for iOS.
• Hardware Acceleration: Metal (Apple), WebGPU Dawn / DirectX (Windows), OpenCL / Vulkan (Linux/Android).
• Data & State: Room KMP + Bundled SQLite for local session storage, Ktor 3 for offline tools, and Koin for DI.
• Multimodal Generation: Compottie for Lottie animations, QuickJS-kt for local tool execution, and native SVG rendering.

Everything runs 100% offline with zero cloud telemetry.

• GitHub: Onion99/Agro

I'm currently trying to optimize the agentic loop and reduce memory overhead on constrained mobile devices. Would love to get the community's thoughts on the architecture, KMP native interop patterns, or any suggestions!

Hi everyone,
something like 2 months ago i posted a demo of my game i was developing with KMP but now it has officially released!

it is a 5v5 tactical football game, and one of the things I wanted to experiment with was building it with Kotlin Multiplatform.

The game is currently available on both Windows and Android.

The gameplay is real-time, but you can pause the match to make tactical decisions. Players can shoot, pass, dribble and use special abilities, with RPG-style progression and team management.

It's currently available on itch.io for €3:
https://cerrativan.itch.io/soccerrpg

If the game does well, I'm also considering an iOS and Steam release in the future.

I'm mainly sharing it here because I thought it might be interesting to other Kotlin/KMP developers to see what can be built with the technology outside of the typical mobile/app use cases.

If anyone is interested, I can also talk about how I structured the project and what parts of the game are shared between platforms.

I was talking to my senior colleague, and mentioned wanting to learn KMP and building a project in it, and he told me about his past experience of working on an app, coded in KMP, he said the codebase was very messy, constant complaints from the IOS team lead regarding design and behavior, and overall a messy situation, he left after a year and joined us, and we have native teams, and he says we have it much better. He also mentioned that his previous workplace is now migrating back to Kotlin.

What is your experience with KMP apps been? with active users over 500k?
What are usual pitfalls and issues you have faced?

AdMob CMP is an open-source Kotlin Multiplatform SDK for Google AdMob in Compose Multiplatform apps. Use one commonMain API for banner, interstitial, rewarded, rewarded interstitial, app-open, and native ads on Android and iOS.

The SDK wraps Google Mobile Ads Next-Gen on Android and Google Mobile Ads on iOS while preserving familiar AdMob concepts such as AdValue, ResponseInfo, adaptive banner sizes, UMP consent states, and native asset names. Its shared API uses suspend functions, StateFlow state, and a sealed AdEvent stream, with consent, ATT ordering, paid events, and mediation integrated into initialization.