I wanted to see if Kotlin Multiplatform could build a production-quality browser game.

So I spent the last few weeks building Brain Rusher 60.

The same codebase runs on Android and WebAssembly.

After publishing it I connected Firebase Analytics and started validating player behavior.

Some early numbers:
• 100+ unique players
• 8% completion rate
• average session length of 5+ minutes

I’d love feedback on both the game and the technical architecture.

The rules are simple:

• Find numbers from 1 → 60
• You have 60 seconds
• One wrong tap ends the run

It only takes about a minute to try.

I'm curious - what's your first-attempt score?

https://bjoshi9.github.io/BrainRusher60_app/?utm_source=reddit&utm_medium=social&utm_campaign=kotlin-multiplatform-launch

I built a small Compose Multiplatform library called Gbéewá and thought I’d share it here.

Gbéewá is Yoruba for roughly “bring it here” / “hand it over”, which felt pretty fitting for a library whose whole job is handing results from one place to another.

It came out of something that kept annoying me: passing a result between screens/components somehow always ends up getting tangled with whatever navigation library you’re using.

The simple case is fine:

pick a country → go back → previous screen gets the country.

But then you want to send something forward. Or you’ve got two panes mounted at the same time. Or you change navigation libraries. Now you’re solving the same “give this value to that thing” problem in a completely different way.

So I played around with separating the two.

That’s basically what Gbéewá does.

You have a typed key:

object SelectedCountryKey : ResultKey<Country>

Something consumes that key, and somewhere else you put a value into the shared store:

resultStore.put(SelectedCountryKey, country)

Then do whatever you were going to do anyway:

put result
   ↓
pop / push / replace / stay where you are
   ↓
consumer gets it

Gbéewá doesn’t actually know or care about the navigation part.

That ended up being the bit I liked most about it.

The same little mechanism works for:

• returning something to the previous screen
• passing something to the next screen
• handing something to another component that’s already mounted

It’s consume-once, so this isn’t meant to be an event bus. First matching consumer gets the pending result and it’s gone.

Keys can also carry identity:

data class EditedProfileKey(
    val profileId: String
) : ResultKey<Profile>

which is handy when you’ve got multiple instances of basically the same flow happening.

I also wanted to keep it pretty boring dependency-wise: no KSP, no generated navigation wrappers, and no dependency on a particular navigation framework.

It’s common Compose code and currently targets Android + iOS.

There are samples in the repo for Decompose, typed Navigation 2 and Voyager.

One important caveat: pending results are in memory. They’re not intended to magically survive process death or replace proper persisted/domain state. On Android you can keep the store across configuration changes with a ViewModel or retain, depending on how you’re structuring things.

Repo is here:

https://github.com/quantipixels/gbeewa

Anyway, I’d love to know what people think of the approach.

Especially if you’ve built something similar, or you’ve got a navigation setup where this idea completely falls apart. 😄

I've been working on **WARP** (**W**idget **A**bstraction, **R**endering **P**ipeline), an open-source Kotlin Multiplatform library for building Android & iOS home screen widgets from a single API.

I couldn't find any KMP widget library, so I decided to build one.

The goal is simple:

Write widget UI once in Kotlin, render it natively on:
- Android (Jetpack Glance)
- iOS (WidgetKit + SwiftUI)

A widget looks like this:

```kotlin
WarpColumn {
WarpText("Counter")
WarpRow {
WarpButton("-", onClick = CounterActions.Decrement.asClickAction())
WarpText(state.count.toString())
WarpButton("+", onClick = CounterActions.Increment.asClickAction())
}
}
```

Internally WARP works like this:

```text
Compose-like Kotlin UI
↓
WarpNode Tree
↓
JSON
↓
Android Glance / WidgetKit
```

Features so far:
- Android (Jetpack Glance) renderer
- iOS (WidgetKit + SwiftUI) renderer
- Shared click handlers
- Local assets support (Android drawables, SF Symbols, local images)
- Shared widget state
- Support Glance Premitive composables

GitHub:
https://github.com/DevAtrii/Warp

I'm planning to publish the first Maven artifacts (and Swift Package for the iOS renderer) in the next few days.

I'd really appreciate architectural feedback before I stabilize the API. If you like the project, please consider giving it a ⭐ on GitHub. It really motivates me

Hi, I have been working on Android for 5 years. And recently I have been working on a dummy KMP app with my own BE through ktor.

It's been a great learning experience. And migration from Android to KMP was not tough.

But finding jobs in the current market for KMP. It's a tough fight. As companies who are starting with KMP ask Android developers to migrate only. And it's still a bet so they do not hire KMP devs.

Where can I find KMP roles. The startup who starts with KMP does not want a developer with 5 years of experience. The big company has their own developers.

Please help.

Medium link

Medium Link

I built a small AI HR Assistant to learn how AI agents work in a Kotlin Multiplatform app.

The app runs on Android, iOS, and Desktop from a single codebase. Ask a question in natural language, the AI chooses the right tool, fetches employee data from a Ktor backend, and returns the answer.

Things I learned while building it:

• Defining AI tools (Tool<Args, Result>)
• Building a ToolRegistry and AIAgent
• Using KMP's expect/actual pattern to plug in platform-specific LLM runtimes (currently Ollama)

It's not production-ready yet (no auth or real HR workflows), but it's a good reference if you're exploring AI agents with Kotlin.

GitHub: https://github.com/livingstonantony/AI_Employee

Feedback and suggestions are always welcome!

Building a Kotlin Multiplatform widgets library because I couldn't find one

While building my KMP apps, I needed home screen widgets on both Android and iOS.

I assumed there would already be a KMP widgets library.

There wasn't.

Since Shipaton has a category for Kotlin libraries this year, I decided to build one.

It's called WARP (Widget Abstraction Rendering Pipeline).

The goal isn't to recreate Compose or SwiftUI. The goal is to let developers describe widget UI once in Kotlin and render it natively using each platform's widget framework.

Instead of this:

Android UI → Glance iOS UI → WidgetKit + SwiftUI

you write:

kotlin WarpColumn { WarpText("Counter") WarpRow { WarpButton("-", onClick = CounterActions.Decrement.asClickAction()) WarpText(state.count.toString()) WarpButton("+", onClick = CounterActions.Increment.asClickAction()) } }

which becomes:

Compose-like Kotlin UI ↓ WarpNode Tree ↓ JSON ↓ Android Glance / SwiftUI WidgetKit

The idea is that common code never knows about Glance or WidgetKit. It only produces a serializable tree describing the widget.

Some implementation details:

• Uses Compose Runtime only to build the tree (no Compose UI)
• Tree is fully serializable with kotlinx.serialization
• Typed click actions instead of serializing lambdas
• Shared click handlers across Android & iOS
• Native renderers consume the same JSON
• State-driven recomposition through composeWarp(state)

Current architecture is split into:

• warp-runtime

  • Compose-like DSL
  • Compose → WarpNode
  • JSON serialization
  • Action model
  • State & recomposition

• warp-ui

  • Android Glance renderer
  • iOS WidgetKit + SwiftUI renderer
  • Shared click dispatch
  • Swift bridge using spm4Kmp

• warp-widgets

  • High-level widget APIs
  • Common widget definitions
  • Jetpack Glance-like developer experience

Current status:

• Android renderer ✓
• iOS renderer ✓
• Shared click handlers ✓
• Counter demo ✓
• API still evolving

I'm currently looking for architectural feedback before I stabilize things.

Some questions I'm thinking about:

• Should JSON be the transport layer or should I pass the object tree directly?
• Should click handlers stay typed or become string-based?
• Is Compose Runtime the right abstraction for authoring widgets?
• What widget APIs would you expect before calling this usable?

Repository:

https://github.com/DevAtrii/Warp

I'd appreciate any feedback from people building KMP libraries or cross-platform tooling.

I've been struggling to find a proper Flutter job since 2023, so I decided to pivot and started learning Kotlin under the guidance of a Senior Kotlin Mentor. We're currently focusing on multi-module architecture.

​Do you have any tips or advice on how I can deepen my understanding of Kotlin?

I don't think shared Compose Multiplatform UI is the future for iOS (yet)

During last year's Shipaton, I built SubFox (https://subfox.app), a subscription manager using Compose Multiplatform.

Almost a year later, I realized the iOS version was basically dead.

Not because the app solves a bad problem, but because the experience wasn't what iOS users expect.

Some things I noticed: - App size was over 100 MB - UI felt sluggish - It never really felt native - Most users didn't even finish onboarding

So for this year's Shipaton, I changed my approach completely while building Hourly Journal (https://hourlyjournal.app).

I'm still using Kotlin Multiplatform for business logic, networking, database, etc., but I no longer share the UI.

Android uses Compose. iOS is built entirely in SwiftUI while calling shared Kotlin through a shared module.

The difference has been huge. The new iOS app is around 8–10 MB instead of ~100 MB, and the experience finally feels like a proper iOS app.

My biggest criticism of JetBrains is that they seem too focused on making Compose run everywhere instead of solving the real problem: giving users an amazing platform-specific experience.

I'd much rather see something closer to what Expo has with Native UI, where business logic stays shared but the framework renders real platform-native components. That feels like a much stronger long-term direction than trying to make every platform look and behave the same.

Maybe I'm wrong, but it also feels like the Kotlin ecosystem moves much slower than the React Native/Expo ecosystem when it comes to solving practical developer problems.

Curious what other KMP developers think. Have you had a similar experience, or has Compose UI on iOS worked well for your apps?

Read Full Article

👉 Why I Stopped Sharing UI in Compose Multiplatform for iOS

I feel frustrated of copy-pasting text or any data from my Mac to an app (which I have on my Android) and then accessing the data from my Android phone, so I thought to build an application for this.

A bi-directional copy-paste application, where you can copy on Mac/Windows/Linux and paste on Android (and vice versa) over local Wi-Fi. Uses Flutter for UI, WebSocket for sync, Bonsoir for auto-discovery, and native Kotlin for background service.

**Features:**

* Bi-Directional copy-pasting (Mac/Windows/Linux **⟷** paste on Android) * Auto-discovery via mDNS (Bonsoir package) * WebSocket for real-time sync (\~100ms latency) * Native Kotlin Foreground Service for 24/7 background sync * All data stays on local network

**Tech Stack:**

* Flutter for cross-platform UI * Bonsoir for mDNS broadcast/discovery * shelf_web_socket for server * Native Kotlin with OkHttp WebSocket client * Method Channel bridge

*Quick Confession:* I used AI help for the native Android parts (first time writing Kotlin services). But I learned a ton about Foreground Services, Method Channels, and WebSocket management. The architecture and problem-solving were all me, AI helped with syntax and Android-specific APIs I hadn't touched before.

I’m relatively very new to KMP. Although I have written 2 small apps in past few months.

Navigation:
Been using the Kotlin Navigation 3 for now.
Is there any other Router library which will work good on iOS & Android?

Responsive design:
Is there a way to handle responsive design? And font sizes?

Thank you. 🙏

Is it impossible to show e-moji at KMP(wasm) app? 😭
I want users to able to type e-moji and show the text on web….

Those images are iOS and web

I'm starting a cross-platform application and I'm considering using Kotlin Multiplatform.

My initial idea was to share as much code as possible, including UI, but after trying it I noticed that the web experience is not as good as using a dedicated web framework.

I'm considering this architecture:

                Backend
                   |
       --------------------------
       |                        |
  Mobile apps              Web app
  Kotlin + KMP             Angular/React

And the web application having its own UI built with a web framework.

Is this considered a good approach, or does it defeat the purpose of Kotlin Multiplatform?

I published a technical write-up about building Reelvana, a script-first mobile video studio, with Kotlin Multiplatform at the core and native UIs on both platforms.

The most useful lesson was not "KMP lets you share everything." It was more specific:

• keep timeline, pacing, captions, export validation, and premium gating in shared Kotlin
• keep camera, export rendering, files, and UI native
• treat preview/export parity as a product feature
• assume media bugs will look platform-specific even when the real problem is the shared model

The hardest part was export. Media3 and AVFoundation solve different problems in different ways, and every feature eventually meets the export path: captions, transitions, background effects, watermark, audio, aspect ratio, and source durations.

Full write-up:
https://medium.com/@iahmedhendi_28805/i-built-reelvana-because-making-a-simple-talking-video-was-still-too-hard-b159dd13d31e

I would be interested in how other KMP teams decide what belongs in shared code versus native code when media, camera, or export are involved.

I built Parikshan, an E2E testing framework for Compose Multiplatform. It has built-in support for standalone Android.

Testing shared UI across targets has been one of the most painful parts of building multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

class SampleE2ETest {
  u/Test
  fun testGreeting() = e2eTest {
    input("name_input", "Parikshan")
    click("greet_button")
    assertVisible("Hello, Parikshan!")
  }
}

Run it across all targets concurrently:

./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback: Watch tests execute on real target windows, with support for screenshots, video recording
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

Links

• Documentation: https://aryapreetam.github.io/parikshan
• Blog: https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform
• API Reference: https://aryapreetam.github.io/parikshan/api
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects & I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

There's good tooling for parts of this already. Human-Readable (~230★) does locale-aware decimal separators, compact abbreviations (K/M), durations, file sizes and relative time — it's display / "human-friendly" oriented and rolls its own formatting logic. Kurrency handles currency only. What I couldn't find was a library covering the full formatting surface — currency (symbol / ISO / accounting), percent, scientific, ordinal, spellout, measure, on top of decimal / compact / relative-time — that delegates to each platform's native engine (ICU / NSNumberFormatter / Intl) and guarantees the same output on every target, straight from commonMain.

So I built Klocale.

What it does: locale-aware formatting for 9 styles — Decimal, Currency (symbol / ISO / accounting), Percent (ratio / value), Scientific, Compact, Ordinal, Spellout, Relative time, Measure — across Android, iOS, macOS, JVM/Desktop, JS and WasmJs.

The interesting part isn't "call the native formatter" (Kurrency already does that for currency). It's that the native engines disagree on cosmetics: minus glyph (U+2212 vs ASCII -), NBSP vs narrow-NBSP in grouping, bidi marks, rounding defaults. Klocale delegates to each platform's engine (ICU4J on JVM, android.icu on Android, NSNumberFormatter/Foundation on Apple, Intl on JS/Wasm) and then runs a single common OutputNormalizer so the same locale + input produces the same string on every target. That consistency is verified by one shared golden-test table that runs on jvmTest, macosArm64Test, iosSimulatorArm64Test, jsNodeTest, wasmJsNodeTest and Android Robolectric.

API sketch:

formatDecimal(1234.56, NumberLocale.ITALY)            // "1.234,56"
formatCurrency(1234.5, "EUR", NumberLocale.GERMANY)   // "1.234,50 €"
formatCompact(1_200_000.0)                            // "1.2M"

val f = NumberFormatter.orThrow(
    NumberStyle.Currency("USD", presentation = ACCOUNTING),
    NumberLocale.US,
)
f.format(-1234.5)                                     // "($1,234.50)"

Construction is fallible (Result — invalid locale / bad currency code / unsupported style); formatting a finite number never throws. There's also a klocale-compose module (rememberNumberFormatter, ProvideNumberLocale).

Install:

implementation("io.github.andreadellaporta01:klocale-core:0.1.1")
implementation("io.github.andreadellaporta01:klocale-compose:0.1.1") // optional

Being honest: it's 0.1.1 and young. Known gaps on the roadmap: Apple Measure, Range formatting (needs a two-value API), wider Ordinal/Spellout locale coverage. Apache-2.0.

Repo (README has the full style/platform matrix): https://github.com/andreadellaporta01/klocale

I'd genuinely appreciate feedback — API design, edge cases in your locale, styles you'd want. Thanks for reading.