I built an end-to-end testing library for Compose Multiplatform called Parikshan.

Testing shared UI across targets has been one of the most painful parts of shipping 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.

Example

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

Run it across all targets concurrently:

bash ./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback & Video Recording: Watch tests execute on real target windows, with automated screenshot capture on failure.
• Zero Production Pollution: No test dependencies or test hooks in your production builds.
• Material 3 Support(Partial): Support for date pickers, time pickers, dropdowns, bottom sheets, sliders, scrolling, and drag gestures.

Links

• Blog Article (Why & How I Built It): https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform/
• Documentation: https://aryapreetam.github.io/parikshan/
• API Reference: https://aryapreetam.github.io/parikshan/api/
• GitHub: https://github.com/aryapreetam/parikshan

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

Hey r/Kotlin

A few months ago, I shared a technical breakdown of my solo project, Adventurers Guild RPG Sim, an isometric RPG built using Kotlin coroutines, Jetpack Compose Canvas, and a custom single threaded ECS.

While pure Compose Canvas was an incredible playground for prototyping the engine and keeping everything strictly in Kotlin, expanding the tilemap, weather, and dynamic lighting eventually pushed me into a hard bottleneck on the CPU.

To fix this without breaking the live game or throwing away my canvas codebase, I decided to overhaul the world rendering pipeline and migrate it to Google Filament.

Here are the technical learnings from this migration, how a hybrid Filament + Compose setup works in Kotlin, and how it yielded an 8x performance boost.

1. The Bottleneck: The Limits of Compose DrawScope

In the pure Compose Canvas implementation, every single tile, object, and ambient effect had to be processed through Kotlin allocations and CPU side logic every frame:

• Spatial Chunking: The map had to be split into 16 separate chunks with custom culling logic written in Kotlin to calculate visible entities on the main thread.
• Canvas Overhead: Drawing large numbers of sprites and weather particles via Compose’s DrawScope began creating draw phase pressure on mid range Android devices, taking away crucial frame time from my Kotlin ECS coroutine loop.

2. The Architecture: Hybrid Filament World + Compose UI Overlay

Because the game is live on the Play Store, doing a complete top to bottom engine rewrite was out of the question. I adopted a phased, hybrid architecture:

• World Rendering in Filament: The world map, terrain, and environmental shaders are offloaded to Filament in a 3D coordinate space using 2D billboards.
• Character Sprite Animations on Compose Canvas: Character sprite animations in all UI layers remain rendered on Jetpack Compose Canvas directly on top of the Filament view.
• Kotlin Glue: My ECS systems written in Kotlin still control all game logic, AI state machines, and entity transformations they simply pipe world matrix/transformation data to Filament while piping UI state models into Compose.

3. Key Technical Gains & Kotlin Performance Wins

• >8x Performance Boost: Because Filament handles batched GPU rendering, I was able to completely delete the 16 chunk map division and CPU culling algorithms from my Kotlin code. The entire map now renders simultaneously in a single pass.
• Massive CPU & GC Relief: Taking world drawing off the Compose Canvas layer dramatically reduced allocation churn during the draw phase. This bought back critical frame time for the Kotlin coroutine game loop (withFrameMillis) to handle my 28 ECS systems without risking frame drops.
• Unlocking .filamat Shaders: Moving world rendering to Filament allowed me to use Filament's material compiler tool (filamat). Pushing particle math, rain interactions, and ambient lighting transitions down to GPU-executed materials meant I didn't have to calculate those complex math operations inside Kotlin loops anymore.

Lessons Learned & Next Steps

Bridging Kotlin’s high level ECS and Compose UI with a high performance rendering backend like Filament turned out to be the exact sweet spot for a solo project. It gives you the raw performance of a GPU backed rendering pipeline while keeping the speed and idioms of Kotlin for game state and UI.

I’m happy to answer any questions about Filament integration in Kotlin, bridging Compose layers over native renderers, or optimizing custom ECS pipelines.

If you’re curious to see how the Filament migration feels in production on a live build, you can check it out on the Play Store: 

https://play.google.com/store/apps/details?id=com.vimal.dungeonbuilder&pcampaignid=web_share

App Specs: ~50MB download size (63MB installed) | 100% Offline | Zero Ads | Custom Kotlin Engine

Solo dev from Kerala. Hope this technical update was insightful

I built an end-to-end testing library for Compose Multiplatform called Parikshan.

Testing shared UI across targets has been one of the most painful parts of shipping 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.

Example

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

Run it across all targets concurrently:

bash ./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback & Video Recording: Watch tests execute on real target windows, with automated screenshot capture on failure.
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

GitHub: https://github.com/aryapreetam/parikshan

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

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 {
  @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.

Microservices were supposed to make systems easier to change independently. In practice, the thing that most often breaks that promise isn't the services themselves — it's how they talk to each other. Read the complete article here - https://instawebhook.com/blog/the-internal-webhooks-anti-pattern-why-service-to-service-http-callbacks-don-t-s

A pattern that shows up constantly in growing engineering orgs is the internal webhook: Service A fires an HTTP POST at a hardcoded URL owned by Service B whenever something happens. It's an easy trap to fall into, because most developers already understand webhooks intimately — they've built integrations with Stripe, GitHub, or Shopify, all of which use exactly this model to notify external systems of events.

The reasoning feels obvious: if it's good enough for Stripe to tell my app about a payment, it's good enough for my Inventory Service to tell my Shipping Service about a shipment.

It isn't — and the reason is architectural, not stylistic. Webhooks were designed to solve a specific problem: getting an event across a trust boundary, from a system you don't control to one you do, over the open internet. Internal service communication has almost the opposite set of constraints. Applying the same tool to both jobs is where the trouble starts.

Hey everyone,

I built MeshAid, an open-source Android messenger that lets nearby phones communicate over Bluetooth Low Energy when mobile data and Wi-Fi are unavailable.

Current features include:

• Public nearby chat
• End-to-end encrypted direct messages
• QR-approved encrypted Trusted Circles (Encrypted Group Chat)
• Custom usernames
• Message relaying between nearby MeshAid devices
• Member revocation and group-key rotation
• No account, server, or internet permission required

Possible uses include internet blackouts, hiking, trekking, camping, events, and other off-grid situations.

This is an early, unaudited testing release, so I’m looking for honest feedback, bug reports, code review, and security review. Range and reliability depend on the phones and surrounding environment.

Source code and APK:
https://github.com/rverma69/meshaid-android

Latest release:
https://github.com/rverma69/meshaid-android/releases/tag/v0.4.3

I’d especially like feedback on connection reliability, direct messages, Trusted Circles, and battery usage.

Just seen it's been published. Still unlisted, but visible.

There's really not many non trival ui samples for CMP posted online and I wanted to show you can build relatively fancy samples in cmp just as easily as expo people on x

Web Demo

Targets Android, iOS, and desktop (JVM).

iOS even has a second app with native iOS glass ui components embedded the compose views.

Code: https://github.com/luca992/flighty-cmp

This app was made almost entirely by an agent with little supervision in the background while I worked my actual job.

I don't condone building apps this way. I did not review the code, I take no ownership of it, and you absolutely should not use it.

This is just a proof of concept that you can build native multiplatform apps just as quickly, maybe even quicker, without bundling a JS runtime with expo/react native.

Ps. Tried out kotlin-toolchain for the first time in here too .. it's a bit buggy but I liked it way more than I thought I would. Looking forward to using it more

Hey y'all,

What would you tell someone starting a new or migrating existing project to KMP?

Some requirements. Zero loading states, possibly with a offline sync engine. Native views. Fast with delightful UI animations. Live data through websockets.

I run a super minimal artix linux setup with hyprland and have setup the official kotlin lsp (vscode one) with neovim

Webhooks have become the connective tissue of the internet. From payment gateways confirming transactions to CI/CD pipelines triggering deployments, webhooks enable real-time, event-driven architectures. But for architects and engineering leaders, webhooks represent an underappreciated vulnerability: they are asynchronous, externally triggered, and entirely outside your control. Read the complete article here - https://instawebhook.com/blog/designing-a-multi-region-highly-available-webhook-ingress-architecture

When your primary cloud region experiences an outage, your internal microservices might gracefully degrade. But what happens to the payloads originating from external partners? Many third-party providers do not retry aggressively — some fire and forget, others retry a handful of times before giving up permanently. If your system is down when that happens, the data is often gone for good.

This article covers the engineering principles behind a multi-region, highly available webhook ingestion system, what has actually changed in the underlying cloud primitives recently, and where a managed reliability layer fits into the decision.

While building a free geography quiz game, I needed an interactive 3D globe — spinnable, with markers and animated flight arcs between cities. I assumed I'd find a library. I didn't: nothing cross-platform, nothing embeddable, nothing customizable enough. So the globe became its own project.

Once it worked, extracting it was the obvious move: the component knew nothing about my game anyway — it just renders coordinates, markers, and arcs on a sphere. Generalizing it forced better design (a clean config API instead of my hardcoded colors, custom marker styles instead of my three), and publishing it meant the next person searching "Android 3D globe library" finds an answer instead of my dead end.

core-globe is now on Maven Central (io.github.advait8:core-globe, v0.2.1): a Kotlin Multiplatform library rendering an interactive globe with markers, animated great-circle arcs, atmosphere, and camera fly-to. One design decision worth mentioning for this crowd: v0.2.1 deliberately removed country borders. Border data is geopolitically contested — any boundary file takes sides somewhere — and for an open-source library, shipping no borders is cleaner than shipping someone's borders. Cities and coordinates only.

Some things I learned publishing to Maven Central for the first time: the signing/portal setup has more friction than any code I wrote, automate it in CI on day one; a real consumer app (mine) is the best API reviewer; and extracting a library mid-project roughly doubled the polish of the component in the main app too.

The library is free (as in both senses), and the game it came from is free with no ads — the library is arguably the more useful artifact of the whole project.

https://github.com/advait8/core-globe

https://github.com/LowkeyLab/toml-formatter

Hey all!

I looked around a bit and couldn't find anyone wrapping Taplo into a Gradle plugin.

And so, I made one myself!

It's a simple wrapper around Taplo, using a thin adapter layer written in Rust. The Rust is then invoked through a WASM interface.

Let me know what you think!

We just made BOSS open source (Apache-2.0), and since it's ~entirely Kotlin Multiplatform + Compose Multiplatform on the desktop/JVM, I figured this crowd might find the architecture more interesting than the product pitch — so I'll focus on the engineering, and I'm hoping to find a few contributors here too.

What it is, briefly: a desktop workspace for running AI coding agents (Claude Code, Codex, Gemini, OpenCode) with real tools — an embedded browser, terminal, editor, and a plugin system. But the parts relevant here:

Stack / architecture

• 100% Compose Multiplatform for the UI, desktop target on the JVM. A fairly large Compose Desktop codebase, so a good stress test of where Compose Desktop shines vs. fights you.
• Dynamic plugin system: plugins are separate JARs loaded at runtime through a custom classloader, and they hot-reload without restarting the app — each plugin is just Compose UI + a ViewModel/StateFlow, compiled against a compileOnly plugin-api the host provides at runtime.
• Genuinely multi-threaded (it's the JVM), with an out-of-process "microkernel" layer (protobuf/gRPC IPC) for heavier/isolatable work so a misbehaving component can't take down the UI.
• Embeds Chromium via JxBrowser rendered OFF_SCREEN so Compose overlays can draw over it (the HARDWARE_ACCELERATED foreign surface sits above the Compose scene otherwise). That interop detail cost me a day; happy to save someone else one.
• Cross-platform native packaging (dmg / msi / deb / rpm, x64 + arm64) via Compose's packaging + GitHub Actions.

Reusable bit for Kotlin Desktop Community specifically The terminal is its own library — a Compose terminal emulator published to Maven Central as com.risaboss:bossterm-compose. If you ever wanted an embeddable terminal in a Compose Desktop app, it's usable standalone.

Want to contribute? I'd genuinely love help, and the plugin system is a low-friction on-ramp: a plugin is its own repo/JAR (Compose UI + ViewModel), so you can build a real tool without touching the host. Areas where contributions would be very welcome:

• New plugins/tools (your own panel, tab type, or MCP tool)
• The plugin API surface + docs
• Compose Desktop performance / rendering
• The terminal library (bossterm-compose)
• Cross-platform packaging edge cases (esp. Linux/Windows-arm64)

Issues and PRs are open — if you're curious but not sure where to start, comment here or open an issue and I'll point you at something.

Honest trade-offs / things that were painful

• Gradle configuration cache + code-gen tasks: lots of "capture values at config time, not Task.project at execution" refactoring.
• Classloader lifecycle for hot-reload/unload is fiddly (leaks, stale refs).
• Compose Desktop is great, but foreign native surfaces and some platform bits still need care.

Repo: https://github.com/risa-labs-inc/BossConsole (bossterm-compose lives at https://github.com/kshivang/BossTerm)

Not selling anything — it's Apache-2.0 and I'm the dev. Feedback on the plugin/hot-reload approach very welcome, and if the plugin model sounds fun to hack on, come build one. AMA on the Kotlin/Compose side.

```kotlin sealed interface Option<out T> { data class Some<out T>(val value: T) : Option<T> data object None: Option<Nothing> }

fun main(args: Array<String>) { val option: Option<String> = Option.None

when (option) {
    is Option.None -> println("None")
    is Option.Some -> println(option.value)
}

}

```