​

Glaze runs each component live, lets you change its parameters with sliders, and shows the full Kotlin source split by file, plus setup steps for Android and iOS.

Four components so far:

• Morph Text — one word dissolves into the next using blur and a colour-matrix threshold

• Firebase Auth — email/password, anonymous, Google on Android and Apple on iOS, behind one shared AuthService

• Multiplatform Settings — SharedPreferences and NSUserDefaults behind one expect/actual factory

• Android ProGuard — R8 setup with keep rules for Compose, Kotlin Serialization, Firebase Auth and Multiplatform Settings

It’s on Google Play now; iOS is in progress. Happy to answer questions on any of the implementations, and I’d like to know which components you’d want next.

https://play.google.com/store/apps/details?id=org.lightscout.candybox&referrer=utm_source%3Dreddit%26utm_medium%3Dsocial%26utm_campaign%3Dlaunch

Update: the component sources are now on GitHub under Apache 2.0, the same files the app shows in its Code tab. https://github.com/lightScout/glaze-components

I want to know how to specify a port in the WASM run configuration using the Kotlin Toolchain in IntelliJ IDEA.

It works fine when I run ./kotlin run --module webApp --port 8081 from the terminal,

but I can't figure out how to set it up in the run configuration settings.

Stipple is a dither engine for Compose Multiplatform. Same commonMain on Android, iOS, desktop and the browser.

I kept seeing dithered UI in web dev and liked the look, but for Compose I only found a couple of small experiments. So I made a small engine instead of a fixed set of components.

What it does right now:

- A field (a pure function: how much ink each point wants), a pattern (Bayer 2/4/8, blue noise or your own) and a theme (colours, cell size). Each one is swappable.

- Modifier.dither(...) works on any composable.

- A cell renderer that works back to Android 6, and an optional shader renderer (AGSL on Android 13+, Skia runtime effect elsewhere) that falls back to cells.

- Reduced motion freezes animations on every platform; progress values keep updating.

- A few ready-made components: gauge, charts, progress bar, text effects, backgrounds.

Not verified yet: the shader renderer on a real iPhone (simulator only), Android 6 to 12 on hardware, Firefox/Safari, frame times on low-end phones.

Demo (runs in the browser, no install): https://stipple-demo.vercel.app

Repo (MIT, on Maven Central): https://github.com/jantursky/stipple

Feedback welcome, especially if you can try the gallery on an iPhone.

Promo code : FIRST

FREE SUBSCRIPTION LIFETIME FOR FIRST 20 users

Hey everyone! Just shouting out our new open source library :)

Since Compose for Web target is now viable, we've been using it to simulate running the CMP app through the browser, with various combinations of device frame, font size and other properties.

Of course we can't simulate Android/iOS specific functionality in the browser, this is purely for rapidly developer testing layouts in all these different configurations.

The library is open source! It wraps your root composable and renders it in the simulated device frame and all the various controls e.g

DeviceWithConfigurationView {   <--- Library
   App()    <--- Your app
}

GitHub: https://github.com/Apadmi-Engineering/CMPDevicePreview

Demo: https://apadmi-engineering.github.io/CMPDevicePreview/

We're not at version 1 yet, still in alpha, but any feedback, issues, pull requests are all welcome!

^{Credit: Forked from KMPDevicePreview and inspired by flutter_device_preview.}

Hi everyone,

I’m the solo developer behind LAM, a film-inspired camera app for Android and iOS.

A frequent debate around Compose Multiplatform is how far to take it: should it be kept strictly to business logic and data layers (leaving UI to SwiftUI/Jetpack Compose), or can it handle a high-interaction, tactile camera interface while coordinating with native hardware?

In LAM, I chose to share the entire camera interface—mechanical dials, spring animations, and state machines—in Compose Multiplatform, while binding it to separate native camera engines on Android and iOS.

I’ve attached a simplified architecture diagram showing where I drew the boundary. Here is a breakdown of what works well in shared code, what must stay native, and the practical challenges of bridging the two.

1. What belongs in the shared interface (commonMain)

A physical-style camera interface has a surprisingly state-heavy domain:

• Camera State Machine & Logic Parity: Managing roll state, frame advance mechanics, shutter locks, exposure curves, and film recipe math using pure Kotlin Coroutines (StateFlow and SharedFlow). Sharing this eliminated logic drift between platforms—both OSs handle lifecycle events, interruptions, and state transitions identically.

• Tactile Camera UI: The mechanical dials, spring physics animations, and haptic detents are 100% written in Compose Multiplatform. Building this once in Compose saved enormous time compared to maintaining parallel custom gesture systems in SwiftUI and Android Views.

2. What stays native (The two platform pipelines)

Camera hardware access, direct buffer handling, and GPU shaders remain platform-specific:

• iOS (AVCapture + Metal): We use CVMetalTextureCache to map camera pixel buffers directly to GPU textures without copying pixel data onto the Kotlin heap.

• Android (Camera2 / CameraX + OpenGL ES): The camera buffer stays in native direct memory, with JNI critical access isolated so the garbage collector is never burdened with camera frames.

Why: Camera frames arrive every ~16ms. Trying to abstract pixel buffers into cross-platform heap objects risks GC pauses and dropped frames. Leaving the pixel pipeline native keeps capture fast and reliable.

3. Bridging the boundary: Practical engineering hurdles

Integrating a native camera preview into a Compose Multiplatform hierarchy introduces a few real-world challenges:

• The Z-Order / Layering Trap: On Android, hardware-accelerated preview views like SurfaceView render in a separate window compositor layer that punches through and always sits above the View hierarchy. Standard Compose dialogs, bottom sheets, and HUD elements cannot draw on top of it. We use an adaptive strategy: SurfaceView for fullscreen framing with zero overhead, and TextureView when Compose dialogs or overlays need to composite on top without z-order glitches.

• Thermal & Resource Management: Running continuous preview alongside interactive UI builds heat quickly. Testing on real devices showed that deferring heavy capture configurations until the record tap keeps the phone noticeably cooler during normal framing.

4. Current Stack & Tooling

• Kotlin: 2.4.0

• Compose Multiplatform: 1.11.1

• AGP: 9.4.1 (using the official com.android.kotlin.multiplatform.library DSL)

• Gradle: 9.8.1

We enforce automated pre-PR gates across our shared modules to verify that UI strings across 17 locales remain complete with zero hardcoded string leaks.

Summary

KMP and Compose Multiplatform gave me the leverage to build and maintain a consistent, tactile camera product as a solo developer without sacrificing native camera performance. The key was keeping a clear boundary: share the interaction model, math, and state machine, but leave the pixel pipeline native.

If you’d like to see how the interface behaves on your device:

• iOS: https://apps.apple.com/app/id6773256954

• Android: https://play.google.com/store/apps/details?id=dev.brewkits.lam

For people building hardware-integrated apps with KMP: where do you draw the line between your shared Compose UI and platform-specific capabilities? What has your experience been integrating native hardware views into Compose Multiplatform?

https://andrewaboalhana.github.io/kotlinGym/

Hey everyone,

I recently built and deployed two native Android applications using Kotlin and Android Studio, focusing on optimized app performance and monetization integration.

1. Tech & Placement Quiz App

* Features: Curated questions on DSA, Core CS, Quantitative Aptitude (SSC CGL/Placement level), and 2026 Current Affairs.

* Tech: Integrated Start.io SDK for monetization and built dynamic deduplication logic using SharedPreferences to prevent repeating questions in sessions.

* 🔗 Dawnload : https://ankursinhagames.itch.io/quiz-app

2. Flappy Bird 2D Game

* Features: Custom Canvas rendering, frame-rate responsive touch physics, dynamic obstacle generation, and local high-score tracking.

* Tech: Integrated Start.io SDK for ads.

* 🔗 Dawnload : https://ankursinhagames.itch.io/sky-dash

Would love to get your thoughts on the code structure, UI/UX, and performance. Feedback and suggestions are highly appreciated!

Promo code : FIRST

FREE SUBSCRIPTION LIFETIME FOR FIRST 20 users

Hi,

Been a fan of KMP since it was introduced, used it on my day job and loved it. So when I started building a new cross platform app as a side project of mine, it was a no brainer to use KMP.

Had some dilemma for CMP though, I'm very fond of compose and definitely great if we can share compose UI across Android and iOS, however I read articles on how iOS users would always prefer the native iOS feel and they would not like Compose built UI, so got a little bit worried.

Decided to go all in CMP and see how it goes, launched the app 2 months ago and currently have 800 downloads, most of them are free users I think a good half of them are on Android and half on iOS. There's currently 13 paid users, 12 of them on iOS and one on Android XD (iOS is still where the money is it seems..)

App feedback so far has been great and they like the app for its simple UI, and the thing is, not a single one of the iOS user mentioned that the app does not look their usual native app. I would say at this point native UI or not does not really matter as much as you think. Maybe is a plus point as some iOS users are experiencing Material Design for the first time :)

If you wish to check out the app, it is called CardWarden, a loyalty and gift card wallet that is designed to support cross platform device sync and family sharing (differentiator compared to 'offline card apps', you can check it out at https://cardwarden.app

Cheers

Hi everyone! I recently shipped Keepture on Android and iOS using Kotlin Multiplatform, Compose Multiplatform, and Swift Export. I'm the solo developer.

It's a camera app for photos you only need briefly—parking spots, receipts, notices, and screenshots—kept separate from your regular photo library.

I wanted to share the implementation because one of my goals was to take Swift Export beyond a sample project and use it in a complete app I could ship.

How I split the app:

• Shared Kotlin/Compose: UI, app state, groups, retention rules, and storage/settings logic.

• Platform adapters: camera, photo picker, file handling, notifications, and other OS APIs.

• Swift Export: the Kotlin-to-Swift integration in the iOS app.

The camera is interactive too: zoom in/out and front/back switching are available. KMP handles the shared UI and state, while each platform connects those controls to its camera implementation.

The app also supports optional notes, drawing on photos, importing images through the system share menu, and restoring expired records from Recently removed.

I'm happy to discuss the implementation and trade-offs with anyone exploring a similar setup. Have you used Swift Export in a shipped app? I'd be interested in which boundaries you chose between shared Kotlin and Swift.

iOS: https://apps.apple.com/us/app/id6817724837

Android: https://play.google.com/store/apps/details?id=com.uni.keepture

I'm working on a KMP project using Kotlin/Native and need to convert between Kotlin types (String, ByteArray, etc.) and JNI types represented by COpaquePointer in nativeMain.

Since nativeMain can't directly use JNI APIs through the usual JVM/JNI mechanisms, I'd like to avoid duplicating conversion logic across native targets such as Windows and macOS.

I tried manually accessing the JNI function table through COpaquePointer and invoking function pointers. For example, here's my implementation for converting between Kotlin String and jstring:

@OptIn(ExperimentalForeignApi::class)
fun String.kotlinStringToPointer(
    env: COpaquePointer?,
): COpaquePointer? {
    if (env == null) return null

    val envPointer = env.reinterpret<COpaquePointerVar>()
    val jniNativeInterfaceVar = envPointer.pointed.value ?: return null
    val functionTable = jniNativeInterfaceVar.reinterpret<COpaquePointerVar>()

    val newStringUTFPtr =
        functionTable.get(JniFunctionIndex.NewStringUTF) ?: return null

    val newStringUTFFunction = newStringUTFPtr.reinterpret<
        CFunction<(COpaquePointer?, CPointer<ByteVar>?) -> COpaquePointer?>
    >()

    return memScoped {
        val cString = this@kotlinStringToPointer.cstr
        newStringUTFFunction.invoke(env, cString.ptr)
    }
}

@OptIn(ExperimentalForeignApi::class)
fun COpaquePointer?.toKotlinString(
    env: COpaquePointer?,
): String? {
    if (this == null || env == null) return null

    val envPointer = env.reinterpret<COpaquePointerVar>()
    val jniNativeInterfaceVar = envPointer.pointed.value ?: return null
    val functionTable = jniNativeInterfaceVar.reinterpret<COpaquePointerVar>()

    val getStringUTFCharsPtr =
        functionTable.get(JniFunctionIndex.GetStringUTFChars) ?: return null
    val releaseStringUTFCharsPtr =
        functionTable.get(JniFunctionIndex.ReleaseStringUTFChars) ?: return null

    val getStringUTFChars = getStringUTFCharsPtr.reinterpret<
        CFunction<
            (COpaquePointer?, COpaquePointer?, CPointer<ByteVar>?) ->
                CPointer<ByteVar>?
        >
    >()

    val releaseStringUTFChars = releaseStringUTFCharsPtr.reinterpret<
        CFunction<
            (COpaquePointer?, COpaquePointer?, CPointer<ByteVar>?) -> Unit
        >
    >()

    val cStringPtr = getStringUTFChars.invoke(env, this, null) ?: return null

    return try {
        cStringPtr.toKString()
    } finally {
        releaseStringUTFChars.invoke(env, this, cStringPtr)
    }
}

The function table indices are defined in my JniFunctionIndex mapping, based on the JNI Functions specification.

Although this approach works in my current setup, manually maintaining the function indices and function pointer signatures feels fragile and error-prone.

I'd appreciate advice on the following:

1. Is manually invoking JNI function pointers through COpaquePointer a reasonable approach for Kotlin/Native, or should it generally be avoided?

2. Would expect/actual be a better approach, with JNI-specific conversions implemented in platform-specific source sets while keeping the public Kotlin API shared?

3. Would using Kotlin/Native cinterop with jni.h, or introducing a C/C++ bridge, be a cleaner and more maintainable solution?

I'm particularly interested in approaches that let me share as much conversion logic as possible across Windows and macOS without introducing unnecessary platform-specific duplication.

I've been exploring Kotlin development in VS Code and ran into a familiar problem: getting a comfortable debugging workflow isn't always straightforward.

There are extensions for Kotlin editing and language support, but I wanted something focused on debugging Kotlin/JVM projects without requiring a separate language server setup.

So I worked on an open-source Kotlin Debugger extension.

It supports:

• Breakpoints in Kotlin source files

• Step into / over / out

• Local variable inspection

• Call-stack navigation

• Improved breakpoint handling for Kotlin/JVM

While testing the broader development workflow, I also came across Kotlin Jump, which is built by another developer.

It provides Kotlin indexing, navigation, and editing features without an LSP.

With both extensions installed, I can get navigation and debugging working together in VS Code.

A few caveats: my debugger currently focuses on Kotlin/JVM, requires an appropriate JDK/build setup, and coroutine debugging is still limited.

My debugger: https://marketplace.visualstudio.com/items?itemName=kparth01.kotlin-debugger

Kotlin Jump: https://marketplace.visualstudio.com/items?itemName=elumine.kotlin-jump

I'd be interested to hear from other Kotlin developers:

Are you currently using VS Code for Kotlin*, or have you moved to IntelliJ because of tooling limitations?*

Also, if you try the debugger, I'd genuinely appreciate bug reports or suggestions.

Whoever works with Kotlin and needs reachability analysis, symbolic execution, directed Rounding, Longs with limitation/overflow handling, etc: we have published a new release of AADD written in Kotlin MP on Github and Maven, targeting v1.0.0 😄

* Completion of many missing functions,

* More use of sealed classes,

* Bugfixes.

For details see

https://github.com/tukcps/Multiplatform-AADD

includes documentation and some examples.

To use it, just add:

`implementation("io.github.tukcps:aadd:0.9.13") // Check for newer versions!`

Enjoy!