This is where STOMP comes in, and understanding why matters if you’re designing any real-time feature beyond a simple chat.

The Problem with Raw WebSocket

WebSocket gives you a bidirectional pipe. You open a connection, you send text or binary frames, and the other side receives them. That’s the entire contract.

webSocket("ws://server/signaling") {
    send("some json string")
    incoming.collect { frame ->
        // What kind of message is this?
        // Who is it for?
        // Which handler should process it?
    }
}

Now imagine building a voice call system. You need to handle three completely different message streams over a single connection:

• Incoming calls — someone is calling you
• Call events — the call ended, was rejected, timed out
• WebRTC signaling — SDP offers, ICE candidates, answers

With raw WebSocket, every incoming frame hits the same collect block. You'd have to inspect each message, parse its type, and route it yourself. You'd also need to build your own subscription mechanism, your own heartbeat, and your own reconnection logic.

We’ve seen teams do this. It works until it doesn’t — usually at 2 AM when messages arrive out of order and nobody can reproduce it.

What STOMP Actually Is

STOMP (Simple Text Oriented Messaging Protocol) rides on top of WebSocket the same way HTTP rides on top of TCP. It adds structure to the raw pipe:

SEND
destination:/topic/signal.create
content-type:application/json

{"callId":"abc-123"}
^@

That’s a real STOMP frame. It has a command (SEND), headers (destination, content-type), and a body. Compare this to raw WebSocket where you'd send {"callId":"abc-123"} with no metadata about where it should go.

STOMP gives you three things that raw WebSocket doesn’t:

Destinations — messages have addresses. Instead of sending into the void, you send to /topic/signal.create or subscribe to /topic/public. The server knows exactly where to route each message.

Subscriptions — you explicitly declare what you want to receive. The server only sends you messages for topics you subscribed to, not everything happening on the connection.

Frame structure — every message has a command, headers, and body. No ambiguity about what a message means or how to parse it.

How Our Signaling System Uses It

Here’s how the connection layer works. We wrap a STOMP client around Ktor’s WebSocket transport, injecting authentication at the connection level:

class SignalingStompClient(private val httpClient: HttpClient) {

    suspend fun connect(url: String, token: String): SignalingSession {
        val transport = WebSocketDelegate(httpClient, token)
        
        val stomp = StompClient(transport) {
            heartBeat = HeartBeat(
                minSendPeriod = 150.seconds,
                expectedServerPeriod = 150.seconds
            )
            connectionTimeout = 30.seconds
        }
        
        val raw = stomp.connect(url)
        
         return SignalingSession(raw)
    }
}

Notice the heartbeat configuration — 150 seconds. This is how STOMP keeps the connection alive. Every 150 seconds, client and server exchange heartbeat frames. If one side stops responding, the other knows the connection is dead. With raw WebSocket, you’d implement your own ping/pong loop.

Once connected, the real power shows. We subscribe to three separate topics over one connection:

class SignalingConnection(private val client: SignalingStompClient) {
    fun observe(url: String, token: String): Flow<String> = flow {
          val session = client.connect(url, token)
          val streams = listOf(
              session.subscribe("/topic/public"),
              session.subscribe("/user/queue/call-events"),
              session.subscribe("/user/queue/webrtc"),
          )
          
          emitAll(streams.merge())
    }
}

Three subscriptions. Three independent message streams. One WebSocket connection. Each subscription gets only the messages it cares about — incoming calls don’t mix with ICE candidates, call events don’t arrive in the WebRTC handler.

With raw WebSocket, you’d receive all messages in one stream and write a routing switch:

// What you'd have to build without STOMP
incoming.collect { frame ->
    val json = Json.parseToJsonElement(frame.text)

    when {
        "callerId" in json -> handleIncomingCall(json)
        "status" in json   -> handleCallEvent(json)
        "sdp" in json      -> handleWebRtc(json)
        else               -> log("Unknown: $json")
    }
}

This works for three message types. It breaks down when you add ten. And debugging becomes detective work — “why did this message end up in the wrong handler?”

The Send Side — Destination-Based Routing

Sending messages shows the same advantage. Every action has a clear destination:

class SignalingSession(private val stomp: StompSession) {

suspend fun createCall(callId: String) =
        send("/topic/signal.create", CallAction(callId))

suspend fun acceptCall(callId: String) =
        send("/topic/signal.accept", CallAction(callId))

suspend fun sendAnswer(callId: String, sdp: String) =
        send("/topic/signal.answer", WebRtcAnswer(callId, sdp))

suspend fun sendIceCandidate(callId: String, candidate: IceCandidate) =
        send("/topic/signal.ice", candidate.toDto(callId))


private suspend inline fun <reified T> send(destination: String, body: T) {
        stomp.send(
            headers = StompSendHeaders(destination),
            body = FrameBody.Text(Json.encodeToString(body))
        )
    }
}

The server maps these destinations to specific handlers. /topic/signal.accept goes to the call acceptance handler. /topic/signal.ice goes to the WebRTC relay. No ambiguity, no routing logic on the client side.

The destination is a header, not part of the payload. This means your message body stays clean — just the data, no routing metadata mixed in.

The Parsing Layer — Clean Separation

Because STOMP handles routing, our parsing layer only deals with content. Messages arrive already separated by topic, so the repository can focus on one thing — transforming JSON into domain objects:

class DefaultSignalingRepository(
    private val connection: SignalingConnection,
    private val json: Json,
) : SignalingRepository {

override fun observe(): Flow<SignalingMessage> =
        connection.observe(url, token).mapNotNull { raw -> raw.toMessage() }


private fun String.toMessage(): SignalingMessage? =
        asCallEvent() ?: asIncomingCall() ?: asWebRtcSignal()


private fun String.asCallEvent(): SignalingMessage? =
        tryDecode<CallEventDto>()
            ?.takeIf { it.status == "ENDED" }
            ?.let { SignalingMessage.CallEnded(it.callId, it.reason) }

private fun String.asIncomingCall(): SignalingMessage? =
        tryDecode<IncomingCallDto>()
            ?.let { SignalingMessage.IncomingCall(it.callId, it.callerName, it.type) }

private fun String.asWebRtcSignal(): SignalingMessage? =
        tryDecode<WebRtcMessageDto>()?.let { dto ->
            when (dto.type) {
                "offer"         -> SignalingMessage.Offer(dto.sdp, dto.callId)
                "ice-candidate" -> SignalingMessage.Ice(dto.candidate, dto.callId)
                else            -> null
            }
        }

private inline fun <reified T> String.tryDecode(): T? =
        runCatching { json.decodeFromString<T>(this) }.getOrNull()
}

Notice there’s no routing logic here — no “which topic did this come from?” checks. The repository just parses content. STOMP already handled delivery to the right subscription.

Why Not Just Use a REST API?

Fair question. You could poll a REST endpoint for incoming calls and post WebRTC messages via HTTP. But consider the timing:

WebRTC negotiation requires exchanging SDP offers, answers, and ICE candidates in rapid succession — often within milliseconds. A polling interval of even 500ms would make call setup noticeably slow. And HTTP’s request-response model means the server can’t push an incoming call notification to you — you have to ask “any calls?” repeatedly.

WebSocket gives you the push capability. STOMP gives you the structure on top of it.

The Bottom Line

Raw WebSocket is a pipe. STOMP turns that pipe into a messaging system with routing, subscriptions, and structured frames. For a voice call feature juggling incoming calls, call events, and WebRTC signaling over a single connection, that structure isn’t optional — it’s what keeps the system debuggable and maintainable.

You could build all of this yourself on top of raw WebSocket. We’ve seen the code that results from that approach. It starts simple, grows custom routing, adds ad-hoc heartbeats, and eventually becomes the framework you should have used from the start.

Reference

• STOMP Protocol Specification
• Krossbow — Kotlin Multiplatform STOMP
• Ktor WebSocket Client

Why we used STOMP with WebSocket? was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will learn how to integrate a new library biometric-compose into Android applications for Biometric integration.

A new biometric-compose library simplifies the integration of biometrics into Compose-based applications.

Implementation

Dependencies

    implementation("androidx.biometric:biometric:1.4.0-alpha06")
    implementation("androidx.biometric:biometric-compose:1.4.0-alpha06")

rememberAuthenticationLauncher

• A composable function to streamline biometric authentication requests and callbacks directly in composables.
• It returns AuthenticationResultLauncher that we can use to initiate the authentication process.
• We need to pass a callback of type AuthenticationResultCallback . It will be called when an AuthenticationResult is available.

A successful or error result will be delivered to AuthenticationResultCallback.onAuthResult , and failures will be delivered to AuthenticationResultCallback.onAuthAttemptFailed, which is set by a callback.

The 👆callback will be executed on the main thread.

fun AuthenticationResult.processAuthResult(){
     when (this) {
        is AuthenticationResult.Success ->
            Log.d(TAG, "AuthenticationResult Success, \nAuth type: $authType, \nCrypto object: $crypto")

        is AuthenticationResult.Error ->
            Log.d(TAG,"AuthenticationResult Error, \nError code: $errorCode, \nErr string: $errString")

        is AuthenticationResult.CustomFallbackSelected -> {
            Log.d(TAG,"AuthenticationResult CustomFallbackSelected ${fallback.text}")
        }
    }
}

AuthenticationResultType

AuthenticationError (Error code)

🧑‍💻 Code: rememberAuthenticationLauncher

val launcher =
    rememberAuthenticationLauncher(
        resultCallback =
            object : AuthenticationResultCallback {
                override fun onAuthResult(result: AuthenticationResult) {
                    Log.d(TAG, "onAuthResult: $result")
                    processAuthResult()
                }
                override fun onAuthAttemptFailed() {
                    super.onAuthAttemptFailed()
                    Log.d(TAG, "onAuthAttemptFailed: ")
                }
            }
    )

🚀 Initiate the auth process

• Here we need to pass the AuthenticationRequest — It's basically the configuration of the request. Like title, fallbacks, subtitle, icon, etc.
• In the following code, we are using the static function biometricRequest from AuthenticationRequest class to create a AuthenticationRequest

Button(
    onClick = {
        launcher.launch(
            biometricRequest(
                title = "Biometric auth..",
                authFallbacks = arrayOf(AuthenticationRequest.Biometric.Fallback.DeviceCredential),
            ) {
                // Optionally set the other configurations. 
                // setSubtitle(), setContent(), etc.
              }
        )
    }
) {
    Text(text = "Start Authentication")
}

👇Prompt without any customization based on the above 👆 implementation

Customization of the prompt

Subtitle

Button(
    onClick = {
        launcher.launch(
            biometricRequest(
                title = "Biometric auth..",
                authFallbacks = arrayOf(AuthenticationRequest.Biometric.Fallback.DeviceCredential),
            ) {               
                setSubtitle("Subtitle goes here...")
              }
        )
    }
) {
    Text(text = "Start Authentication")
}

Logo

• This requires SET_BIOMETRIC_DIALOG_ADVANCED permission.
• This permission is granted only to system apps, so it would be better to let the library show the application’s logo in the prompt.

Button(
    onClick = {
        launcher.launch(
            biometricRequest(
                title = "Biometric auth..",
                authFallbacks = arrayOf(AuthenticationRequest.Biometric.Fallback.DeviceCredential),
            ) {               
                setLogoRes(R.drawable.food_bank_24px)
                 //....
              }
        )
    }
) {
    Text(text = "Start Authentication")
}

Description

• setContent(content: BodyContent?) : A single parameter of type BodyContent will be used to display the description.
• BodyContent: It's an abstract class, and we have the following 3 implementations that we can use
  PlainText , VerticalList, & ContentViewWithMoreOptionsButton

ContentViewWithMoreOptionsButton : Requires SET_BIOMETRIC_DIALOG_ADVANCED

BodyContent class

public abstract class BodyContent private constructor() {
    
    public class PlainText public constructor(public val description: String) : BodyContent()

    public class VerticalList
    @JvmOverloads
    public constructor(
        public val description: String? = null,
        public val items: List<PromptContentItem> = listOf(),
    ) : BodyContent()

   
    public class ContentViewWithMoreOptionsButton
    @RequiresPermission(SET_BIOMETRIC_DIALOG_ADVANCED)
    @JvmOverloads
    public constructor(public val description: String? = null) : BodyContent()
}

Button(
    onClick = {
        launcher.launch(
            biometricRequest(
                title = "Biometric auth..",
                authFallbacks = arrayOf(AuthenticationRequest.Biometric.Fallback.DeviceCredential),
            ) {
                setContent(AuthenticationRequest.BodyContent.PlainText("Description"))
                setContent(
                    AuthenticationRequest.BodyContent.VerticalList(
                        "Description",
                        listOf(
                            PromptContentItemPlainText("Item1..."),
                            PromptContentItemBulletedText("Bulleted item...")
                        )
                    )
                )
            }
        )
    }
) {
    Text(text = "Start Authentication")
}

👇Prompt with custom subtitle, and description based on the above implementation 👆

Authfallbacks

• If we don’t provide any auth fallbacks when creating the AuthenticationRequest, the default cancel button will be shown in the prompt.

Button(
    onClick = {
        launcher.launch(
            biometricRequest(
                title = "Biometric auth.."
            ) {
                // Configuration goes here,...
             
            }
        )
    }
) {
    Text(text = "Start Authentication")
}

References

Biometric | Jetpack | Android Developers

Stay in touch

https://www.linkedin.com/in/navczydev/

• JavaScript is not available.
• navczydev - Overview
• navczydev.bsky.social

Biometric Auth in Compose Made Easy: The New Library You Need was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shaders are one of the most powerful ways to create modern, high-performance UI effects — ranging from animated backgrounds to complex visual distortions. However, implementing shaders across multiple platforms has traditionally been difficult due to differences in graphics APIs and shader languages.

In this article, you’ll learn how to build a clean and reusable shader abstraction using Compose Multiplatform that works seamlessly across Android, iOS, Desktop (Windows/macOS/Linux), and Web (WASM/JS) from a shared commonMain codebase.

We will use AGSL (Android Graphics Shading Language) on Android and SkSL (Skia Shading Language) on all other platforms, while writing shader code in a unified way so it runs everywhere with minimal changes.

By the end of this guide, you’ll have:

• A platform-agnostic shader architecture using expect/actual
• A consistent way to pass uniforms like time, resolution, and colors
• Support for both background rendering (drawBehind) and post-processing effects (graphicsLayer)
• Safe fallbacks for unsupported Android versions (API < 33)

This approach allows you to write shader-driven UI once and run it across all Compose Multiplatform targets efficiently and cleanly.

Step 1: Project Setup

If you haven’t already created a Compose Multiplatform project, head over to the Kotlin Multiplatform Wizard website.

• Select the platforms: Android, iOS, Desktop and Web.
• Make sure that the Share UI option is selected for both iOS and Web.

(There will be a platform configuration step later — whatever you select here, some related code will be generated there. I’ll explain that in the next steps.)

• Project Name: You can set this to Shader-Animation-CMP (or any name you like)
• Project ID: You can use com.meet.shader.animation.cmp (or customize as needed)

After configuring your options, download the generated project template.

Once downloaded, open the project in Android Studio or IntelliJ IDEA.

Step 2: Configure build.gradle.kts (composeApp module)

Open the build.gradle.kts file inside the composeApp module.

Add the following configuration:

// build.gradle.kts (composeApp module)
import org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi

plugins {
    ....
}

kotlin {
    @OptIn(ExperimentalKotlinGradlePluginApi::class)
    applyDefaultHierarchyTemplate {
        common {
            group("skikoCommon") {
                withJvm() // Enable this if Desktop platform is selected, otherwise comment it
                withApple() // Enable this if iOS platform is selected, otherwise comment it
                // Enable these if Web platform is selected, otherwise comment them
                withJs()
                withWasmJs()
            }
        }
    }
    ....
}

This setup ensures that shared code can be properly organized across different platforms based on your selection.

Why skikoCommon?
iOS, Desktop, and all Web targets in Compose Multiplatform use Skia as their 2D rendering engine. By grouping them under skikoCommon, code in skikoCommonMain compiles for all four targets. Android has its own androidMain because it uses Android’s proprietary RuntimeShader API (AGSL) which is unavailable on other platforms.
This gives us exactly two actual implementation sites for the entire shader layer:

• androidMain — Android AGSL
• skikoCommonMain — everything else (Skia/SkSL)

Reference:

Hierarchical project structure | Kotlin Multiplatform

Step 3: Create expect_shader Package and Files

Inside commonMain/kotlin/<your/package>/, create a sub-package named expect_shader. Then create two empty Kotlin files inside it:

• ShaderProvider.kt
• ShaderUtils.kt

These files live in commonMain and are visible to all platforms. The actual implementations will be placed in androidMain and skikoCommonMain.

composeApp/src/
├── commonMain/.../expect_shader/
│   ├── ShaderProvider.kt           ← interface (all platforms)
│   └── ShaderUtils.kt              ← expect declarations + composable helpers
│
├── androidMain/.../expect_shader/
│   ├── ShaderProviderImpl.kt       ← Android 13+ (RuntimeShader)
│   └── ShaderUtils.android.kt      ← Android actual implementations
│
└── skikoCommonMain/.../expect_shader/
    ├── ShaderProviderImpl.kt       ← iOS / Desktop / Web (Skia)
    └── ShaderUtils.skikoCommon.kt  ← iOS / Desktop / Web actual implementations

Step 4: ShaderProvider.kt — The Uniform Interface

Open ShaderProvider.kt and add the following interface. This is shared across all platforms. it defines how you pass data (time, resolution, colors, etc.) from Kotlin into the shader.

// composeApp/src/commonMain/kotlin/<your/package>/expect_shader/ShaderProvider.kt

package com.meet.shader.animation.cmp.expect_shader

import androidx.compose.ui.graphics.Color

interface ShaderProvider {
    fun uniformInt(name: String, value: Int)
    fun uniformInt(name: String, value1: Int, value2: Int)
    fun uniformInt(name: String, value1: Int, value2: Int, value3: Int)
    fun uniformInt(name: String, value1: Int, value2: Int, value3: Int, value4: Int)

    fun uniformFloat(name: String, value: Float)
    fun uniformFloat(name: String, value1: Float, value2: Float)
    fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float)
    fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float, value4: Float)
    fun uniformFloat(name: String, values: List<Float>)

    fun uniformColor(name: String, r: Float, g: Float, b: Float, a: Float)
    fun uniformColor(name: String, color: Color)

    fun update(block: ShaderProvider.() -> Unit) { this.block() }
}

Each method maps directly to a GLSL uniform declaration in your shader string:

Always match the Kotlin method call with the GLSL uniform type declared in your shader. Mismatched types can lead to silent failures or runtime crashes.

Step 5: ShaderUtils.kt — Core expect Functions

Open ShaderUtils.kt and add the following expect declarations. These are platform-neutral contracts that must be implemented on each platform.

// composeApp/src/commonMain/kotlin/<your/package>/expect_shader/ShaderUtils.kt

package com.meet.shader.animation.cmp.expect_shader

import androidx.compose.ui.graphics.RenderEffect
import androidx.compose.ui.graphics.Shader

// Returns false on Android < 13, true everywhere else.
// Always guard shader logic with this check.
expect fun isShaderAvailable(): Boolean

// The platform-specific shader object.
//   Android  → android.graphics.RuntimeShader
//   Skiko    → org.jetbrains.skia.RuntimeShaderBuilder
@Suppress("EXPECT_ACTUAL_CLASSIFIERS_ARE_IN_BETA_WARNING")
expect class AppRuntimeShader

// Compiles an AGSL/SkSL string into a shader object.
// This is a heavy operation — always call inside remember { }.
expect fun createAppRuntimeShader(shaderCode: String): AppRuntimeShader

// Converts a shader into a RenderEffect for use with graphicsLayer { }.
//
// Use this only when your shader declares: uniform shader inputShader;
// The shaderName argument must exactly match that uniform's name.
//
// The shader receives the composable's own rendered output as inputShader,
// allowing post-processing (distortion, blur, color grading, etc.).
expect fun createAppRuntimeShaderRenderEffect(
    appRuntimeShader: AppRuntimeShader,
    shaderName: String
): RenderEffect

// Returns a ShaderProvider for setting uniform values
// (time, resolution, touch position, colors, etc.)
expect fun createShaderProvider(appRuntimeShader: AppRuntimeShader): ShaderProvider

// Converts AppRuntimeShader → Shader for use with ShaderBrush and drawBehind { }.
// Use this for background shaders and bounded inner composables.
expect fun createShader(appRuntimeShader: AppRuntimeShader): Shader

Two rendering paths:

Background shader  (drawBehind)
────────────────────────────────────────────────────────────
createAppRuntimeShader(code)
  └─ createShaderProvider(shader)         ← set uniforms
  └─ createShader(shader)                 ← convert to Shader
  └─ ShaderBrush(createShader(shader))
  └─ drawRect(brush) inside drawBehind { }


Filter / post-processing  (graphicsLayer)
────────────────────────────────────────────────────────────
createAppRuntimeShader(code)              ← must declare uniform shader inputShader;
  └─ createShaderProvider(shader)         ← set uniforms
  └─ createAppRuntimeShaderRenderEffect(shader, "inputShader")
  └─ graphicsLayer { renderEffect = ... }

Step 6: Platform actual Implementations

6a — Android (androidMain)

Create ShaderUtils.android.kt inside androidMain/.../expect_shader/:

// composeApp/src/androidMain/kotlin/<your/package>/expect_shader/ShaderUtils.android.kt

package com.meet.shader.animation.cmp.expect_shader

import android.graphics.RuntimeShader
import android.os.Build
import androidx.annotation.RequiresApi
import androidx.compose.ui.graphics.RenderEffect
import androidx.compose.ui.graphics.Shader
import androidx.compose.ui.graphics.asComposeRenderEffect

actual fun isShaderAvailable(): Boolean =
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU  // API 33

actual typealias AppRuntimeShader = RuntimeShader

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
actual fun createAppRuntimeShader(shaderCode: String): AppRuntimeShader =
    RuntimeShader(shaderCode)

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
actual fun createAppRuntimeShaderRenderEffect(
    appRuntimeShader: AppRuntimeShader,
    shaderName: String
): RenderEffect =
    android.graphics.RenderEffect
        .createRuntimeShaderEffect(appRuntimeShader, shaderName)
        .asComposeRenderEffect()

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
actual fun createShaderProvider(appRuntimeShader: AppRuntimeShader): ShaderProvider =
    ShaderProviderImpl(appRuntimeShader)

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
actual fun createShader(appRuntimeShader: AppRuntimeShader): Shader =
    appRuntimeShader  // RuntimeShader already extends android.graphics.Shader

Key points:

• AppRuntimeShader is a typealias for android.graphics.RuntimeShader, which already extends android.graphics.Shader, so createShader simply returns it.
• Every actual function requires @RequiresApi(Build.VERSION_CODES.TIRAMISU). Android Lint enforces this and will warn if missing at call sites.
• isShaderAvailable() performs a runtime API check, allowing minSdk = 24 while enabling shaders on Android 13+ devices.

Create ShaderProviderImpl.kt inside androidMain/.../expect_shader/:

// composeApp/src/androidMain/kotlin/<your/package>/expect_shader/ShaderProviderImpl.kt

package com.meet.shader.animation.cmp.expect_shader

import android.graphics.RuntimeShader
import android.os.Build
import androidx.annotation.RequiresApi
import androidx.compose.ui.graphics.Color

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
class ShaderProviderImpl(
    private val runtimeShader: RuntimeShader,
) : ShaderProvider {

    override fun uniformInt(name: String, value: Int) =
        runtimeShader.setIntUniform(name, value)

    override fun uniformInt(name: String, value1: Int, value2: Int) =
        runtimeShader.setIntUniform(name, value1, value2)

    override fun uniformInt(name: String, value1: Int, value2: Int, value3: Int) =
        runtimeShader.setIntUniform(name, value1, value2, value3)

    override fun uniformInt(name: String, value1: Int, value2: Int, value3: Int, value4: Int) =
        runtimeShader.setIntUniform(name, value1, value2, value3, value4)

    override fun uniformFloat(name: String, value: Float) =
        runtimeShader.setFloatUniform(name, value)

    override fun uniformFloat(name: String, value1: Float, value2: Float) =
        runtimeShader.setFloatUniform(name, value1, value2)

    override fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float) =
        runtimeShader.setFloatUniform(name, value1, value2, value3)

    override fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float, value4: Float) =
        runtimeShader.setFloatUniform(name, value1, value2, value3, value4)

    override fun uniformFloat(name: String, values: List<Float>) =
        runtimeShader.setFloatUniform(name, values.toFloatArray())

    override fun uniformColor(name: String, r: Float, g: Float, b: Float, a: Float) =
        runtimeShader.setFloatUniform(name, r, g, b, a)

    override fun uniformColor(name: String, color: Color) =
        uniformColor(name, color.red, color.green, color.blue, color.alpha)
}

6b — iOS / Desktop / Web (skikoCommonMain)

Create ShaderUtils.skikoCommon.kt inside skikoCommonMain/.../expect_shader/:

// composeApp/src/skikoCommonMain/kotlin/<your/package>/expect_shader/ShaderUtils.skikoCommon.kt

package com.meet.shader.animation.cmp.expect_shader

import androidx.compose.ui.graphics.RenderEffect
import androidx.compose.ui.graphics.Shader
import androidx.compose.ui.graphics.asComposeRenderEffect
import org.jetbrains.skia.ImageFilter
import org.jetbrains.skia.RuntimeEffect
import org.jetbrains.skia.RuntimeShaderBuilder

actual fun isShaderAvailable(): Boolean = true  // Skia always supports shaders

actual typealias AppRuntimeShader = RuntimeShaderBuilder

actual fun createAppRuntimeShader(shaderCode: String): AppRuntimeShader {
    val effect = RuntimeEffect.makeForShader(shaderCode)
    return RuntimeShaderBuilder(effect)
}

actual fun createAppRuntimeShaderRenderEffect(
    appRuntimeShader: AppRuntimeShader,
    shaderName: String
): RenderEffect =
    ImageFilter.makeRuntimeShader(appRuntimeShader, shaderName, null)
        .asComposeRenderEffect()

actual fun createShaderProvider(appRuntimeShader: AppRuntimeShader): ShaderProvider =
    ShaderProviderImpl(appRuntimeShader)

actual fun createShader(appRuntimeShader: AppRuntimeShader): Shader =
    appRuntimeShader.makeShader()

Key points:

• AppRuntimeShader is a typealias for org.jetbrains.skia.RuntimeShaderBuilder.
• RuntimeEffect.makeForShader(code) compiles the SkSL shader string.
• RuntimeShaderBuilder wraps the compiled effect and allows setting uniforms via .uniform(...).
• makeShader() returns a org.jetbrains.skia.Shader used with ShaderBrush.
• ImageFilter.makeRuntimeShader wraps it as a Skia image filter and converts it to a Compose RenderEffect.

Create ShaderProviderImpl.kt inside skikoCommonMain/.../expect_shader/:

// composeApp/src/skikoCommonMain/kotlin/<your/package>/expect_shader/ShaderProviderImpl.kt

package com.meet.shader.animation.cmp.expect_shader

import androidx.compose.ui.graphics.Color
import org.jetbrains.skia.RuntimeShaderBuilder

class ShaderProviderImpl(
    private val runtimeShaderBuilder: RuntimeShaderBuilder,
) : ShaderProvider {

    override fun uniformInt(name: String, value: Int) =
        runtimeShaderBuilder.uniform(name, value)

    override fun uniformInt(name: String, value1: Int, value2: Int) =
        runtimeShaderBuilder.uniform(name, value1, value2)

    override fun uniformInt(name: String, value1: Int, value2: Int, value3: Int) =
        runtimeShaderBuilder.uniform(name, value1, value2, value3)

    override fun uniformInt(name: String, value1: Int, value2: Int, value3: Int, value4: Int) =
        runtimeShaderBuilder.uniform(name, value1, value2, value3, value4)

    override fun uniformFloat(name: String, value: Float) =
        runtimeShaderBuilder.uniform(name, value)

    override fun uniformFloat(name: String, value1: Float, value2: Float) =
        runtimeShaderBuilder.uniform(name, value1, value2)

    override fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float) =
        runtimeShaderBuilder.uniform(name, value1, value2, value3)

    override fun uniformFloat(name: String, value1: Float, value2: Float, value3: Float, value4: Float) =
        runtimeShaderBuilder.uniform(name, value1, value2, value3, value4)

    override fun uniformFloat(name: String, values: List<Float>) =
        runtimeShaderBuilder.uniform(name, values.toFloatArray())

    override fun uniformColor(name: String, r: Float, g: Float, b: Float, a: Float) =
        runtimeShaderBuilder.uniform(name, r, g, b, a)

    override fun uniformColor(name: String, color: Color) =
        uniformColor(name, color.red, color.green, color.blue, color.alpha)
}

AGSL vs SkSL — Key Differences

Both are very close to GLSL ES 1.0. In practice, shaders written for AGSL will run on Skiko platforms without changes, except for one limitation.

Write shaders targeting AGSL for best compatibility across all platforms. Avoid dynamic array indexing to ensure they work everywhere.

Step 7: ShaderUtils.kt — Add Composable Helpers

Add these three composable functions to the bottom of ShaderUtils.kt. These are part of commonMain, so no expect/actual is required.

// composeApp/src/commonMain/kotlin/<your/package>/expect_shader/ShaderUtils.kt

package com.meet.shader.animation.cmp.expect_shader

import androidx.compose.animation.core.withInfiniteAnimationFrameMillis
import androidx.compose.runtime.Composable
import androidx.compose.runtime.produceState
import androidx.compose.runtime.remember
import kotlin.time.Clock

// Use when shader availability is already confirmed.
// Will crash on Android < 13 if called without a guard.
@Composable
fun rememberShaderInstance(
    shaderCode: String,
): Pair<AppRuntimeShader, ShaderProvider> {
    val shader = remember { createAppRuntimeShader(shaderCode) }
    val provider = remember(shader) { createShaderProvider(shader) }
    return Pair(shader, provider)
}

// Safe default. Returns a null pair on Android < 13.
// Always check: if (isShaderAvailable() && shader != null && provider != null)
@Composable
fun rememberShaderInstanceOrNull(
    shaderCode: String,
): Pair<AppRuntimeShader?, ShaderProvider?> {
    val shader = remember {
        if (isShaderAvailable()) createAppRuntimeShader(shaderCode) else null
    }
    val provider = remember(shader) {
        if (shader != null) createShaderProvider(shader) else null
    }
    return Pair(shader, provider)
}

// Returns State<Float> — elapsed seconds since first composition.
// Read .value inside drawBehind { } or graphicsLayer { } for deferred reads.
@Composable
fun rememberShaderTime() = produceState(0f) {
    val start = Clock.System.now().toEpochMilliseconds()
    while (true) {
        withInfiniteAnimationFrameMillis {
            val now = Clock.System.now().toEpochMilliseconds()
            value = (now - start) / 1000f
        }
    }
}

rememberShaderInstance
Returns a non-null Pair<AppRuntimeShader, ShaderProvider>. Use only when isShaderAvailable() is already confirmed — otherwise it will crash on Android < 13.

rememberShaderInstanceOrNull
Safe default. Returns null on unsupported platforms. Always check before using the shader.

rememberShaderTime
Returns State<Float> representing elapsed time in seconds. Using .value inside drawBehind { } or graphicsLayer { } avoids full recomposition and improves performance.

Step 8: Usage Examples

Example 1 — Full-Screen Background Shader

private const val PLASMA_SHADER = """
uniform float2 resolution;
uniform float time;

half4 main(float2 fragCoord) {
    float2 uv = fragCoord / resolution * 2.0 - 1.0;
    float v = sin(uv.x * 4.0 + time)
            + sin(uv.y * 4.0 + time)
            + sin((uv.x + uv.y) * 3.0 + time * 1.3);
    float r = 0.5 + 0.5 * sin(v * 3.14159);
    float g = 0.5 + 0.5 * sin(v * 3.14159 + 2.09);
    float b = 0.5 + 0.5 * sin(v * 3.14159 + 4.19);
    return half4(r, g, b, 1.0);
}
"""

@Composable
fun PlasmaBackground(modifier: Modifier = Modifier) {
    val time by rememberShaderTime()
    val (shader, provider) = rememberShaderInstanceOrNull(PLASMA_SHADER)

    Box(
        modifier = modifier
            .fillMaxSize()
            .drawBehind {
                if (isShaderAvailable() && shader != null && provider != null) {
                    provider.uniformFloat("resolution", size.width, size.height)
                    provider.uniformFloat("time", time)
                    drawRect(ShaderBrush(createShader(shader)))
                }
            }
    )
}

• drawBehind runs in the draw phase. Reading time here defers the state read, avoiding full recomposition every frame.
• ShaderBrush(createShader(shader)) wraps the platform-specific Shader as a Brush.
• isShaderAvailable() inside drawBehind is safe — it always returns true on Skiko platforms.

Example 2 — Bounded Inner Shader Card

@Composable
fun ShaderCard(modifier: Modifier = Modifier) {
    val time by rememberShaderTime()
    val (shader, provider) = rememberShaderInstanceOrNull(PLASMA_SHADER)

    Box(
        modifier = modifier
            .size(200.dp)
            .clipToBounds()   // optional
            .drawBehind {
                if (isShaderAvailable() && shader != null && provider != null) {
                    provider.uniformFloat("resolution", size.width, size.height)
                    provider.uniformFloat("time", time)
                    drawRect(ShaderBrush(createShader(shader)))
                }
            }
    )
}

• clipToBounds() is optional. In this example, the shader renders fully within the composable bounds, so clipping is not required.
• Only use clipToBounds() when your shader may draw outside its bounds (e.g., blur, distortion, or offset-based effects).

Example 3 — Filter / Post-Processing with graphicsLayer

private const val RIPPLE_SHADER = """
uniform shader inputShader;
uniform float2 resolution;
uniform float time;

half4 main(float2 fragCoord) {
    float2 uv = fragCoord / resolution;
    float2 offset = float2(
        sin(uv.y * 20.0 + time * 3.0) * 0.008,
        cos(uv.x * 20.0 + time * 3.0) * 0.008
    );
    return inputShader.eval(fragCoord + offset * resolution);
}
"""

@Composable
fun RippleFilterScreen() {
    val time by rememberShaderTime()
    val (shader, provider) = rememberShaderInstanceOrNull(RIPPLE_SHADER)

    LazyVerticalStaggeredGrid(
        columns = StaggeredGridCells.Fixed(3),
        modifier = Modifier
            .fillMaxSize()
            .graphicsLayer {
                if (isShaderAvailable() && shader != null && provider != null) {
                    provider.uniformFloat("resolution", size.width, size.height)
                    provider.uniformFloat("time", time)
                    renderEffect = createAppRuntimeShaderRenderEffect(shader, "inputShader")
                }
            }
    ) {
        items(50) { index ->
            Text("Row $index", modifier = Modifier.padding(16.dp))
        }
    }
}

• Apply graphicsLayer directly to the composable whose content you want to filter.
• "inputShader" must exactly match the shader’s uniform shader inputShader;.
• If isShaderAvailable() is false (Android < 13), no renderEffect is applied and the UI renders normally (graceful fallback).

Best Practices

1. isShaderAvailable() everywhere
Always guard every shader code path with this check. On Skiko platforms (iOS, Desktop, Web) it always returns true at zero cost. On Android, it prevents crashes on API < 33.

2. @RequiresApi(TIRAMISU) on every Android actual
Android Lint enforces this. Any call site without a version check will produce a warning. The isShaderAvailable() guard at the call site satisfies Lint.

3. Shader compilation is expensive
createAppRuntimeShader(code) compiles the shader string into GPU bytecode. Never call it outside remember { }. Compile once per composable lifecycle and reuse it.

4. Deferred state reads for performance
Read time inside drawBehind { } or graphicsLayer { }, not in the composable body. This defers the state read to the draw phase. The composable does not recompose every frame—only the draw layer is invalidated. At 60 fps, this avoids 60 full recompositions per second per shader.

5. drawBehind vs graphicsLayer — the rule

6. Keep minSdk = 24
Do not increase minSdk to 33 just for shaders. Use isShaderAvailable() at runtime and provide a fallback for older Android versions.

Summary

You now have a clean, reusable shader abstraction that:

• Works on Android 13+, iOS, Desktop (Windows/macOS/Linux), and Web (WASM/JS) from shared commonMain code
• Uses AGSL on Android and SkSL on other platforms with the same shader code
• Provides null-safe composable helpers with graceful fallback behavior
• Supports both rendering paths: drawBehind (background) and graphicsLayer (post-processing)

Demo & Resources

Explore the full working implementation with 20+ animated shader screens across all platforms:

Web demo:

Shader Animation CMP

Demo Video:
https://github.com/user-attachments/assets/bdee06b1-c11c-41f4-bd18-36069f7d26b1

Full project:

GitHub - Coding-Meet/Shader-Animation-CMP

This project demonstrates real-world shader usage in Compose Multiplatform, including background effects, interactive animations, and post-processing filters — all built using a shared architecture.

If you’re interested in learning more about Kotlin Multiplatform and Compose Multiplatform, check out my playlist on YouTube Channel:
Kotlin Multiplatform & Compose Multiplatform

Thank you for reading! 🙌🙏✌ I hope you found this guide useful.

Don’t forget to clap 👏 to support me and follow for more insightful articles about Android Development, Kotlin, and KMP. If you need any help related to Android, Kotlin, and KMP, I’m always happy to assist.

Explore More Projects

If you’re interested in seeing full applications built with Kotlin Multiplatform and Jetpack Compose, check out these open-source projects:

• DevAnalyzer (Supports Windows, macOS, Linux):
  DevAnalyzer helps developers analyze, understand, and optimize their entire development setup — from project structure to SDK and IDE storage — all in one unified tool.
  GitHub Repository: DevAnalyzer
• Pokemon App — MVI Compose Multiplatform Template (Supports Android, iOS, Windows, macOS, Linux):
  A beautiful, modern Pokemon application built with Compose Multiplatform featuring MVI architecture, type-safe navigation, and dynamic theming. Explore Pokemon, manage favorites, and enjoy a seamless experience across Android, Desktop, and iOS platforms.
  GitHub Repository: CMP-MVI-Template
• News Kotlin Multiplatform App (Supports Android, iOS, Windows, macOS, Linux):
  News KMP App is a Kotlin Compose Multiplatform (KMP) project that aims to provide a consistent news reading experience across multiple platforms, including Android, iOS, Windows, macOS, and Linux. This project leverages Kotlin’s multiplatform capabilities to share code and logic while using Compose for UI, ensuring a seamless and native experience on each platform.
  GitHub Repository: News-KMP-App
• Gemini AI Kotlin Multiplatform App (Supports Android, iOS, Windows, macOS, Linux, and Web):
  Gemini AI KMP App is a Kotlin Compose Multiplatform project designed by Gemini AI where you can retrieve information from text and images in a conversational format. Additionally, it allows storing chats group-wise using SQLDelight and KStore, and facilitates changing the Gemini API key.
  GitHub Repository: Gemini-AI-KMP-App

Follow me on

My Portfolio Website , YouTube , GitHub , Instagram , LinkedIn , Buy Me a Coffee , Twitter , DM Me For Freelancing Project

How to Implement Shaders in Compose Multiplatform (Android, iOS, Desktop & Web) was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years, Android developers treated the system bars like a DMZ — a “no-man’s land” where we didn’t have to worry about our UI. We leaned on fitsSystemWindows="true" like a crutch, letting the OS handle the heavy lifting.

With Android 16, Google has issued an ultimatum: Edge-to-Edge (E2E) is no longer a choice; it’s the enforced reality for apps targeting SDK 35.

If you think adding enableEdgeToEdge() to your onCreate and sprinkling a few Modifier.systemBarsPadding() calls is the end of the story, you’re in for a painful release cycle. In a massive, multi-module codebase where legacy XML fragments live alongside modern Compose screens, this mandate is an architectural breaking change, not just a UI tweak.

💡 The TL’s Take: Platform Mandates are Architectural Debt

When a platform change is “mandatory,” most teams treat it as a ticket to be closed. At scale, this is a trap. If you don’t build a centralized infrastructure to handle insets now, you are effectively scattering “UI-fix debt” across every feature module. In six months, when the next foldable or “island” cutout comes along, you’ll be hunting down 200 individual padding modifiers instead of updating one internal library.

The Real-World Scenario: The “Double-Padding” Disaster

While prepping a core module for the Android 16 rollout at scale, we hit a classic production nightmare. We enabled the E2E flag, and suddenly, our primary navigation hub — a complex hybrid of a Compose Scaffold hosting a legacy View-based Fragment — went haywire.

The result was The Z-Index Collision. In a pre-Android 16 world, these layers were isolated. Now, they occupy the same coordinate space:

Our TopAppBar was fine, but our primary CTA button was floating 100dp from the bottom, creating a massive, amateurish gap — the “Double-Padding” monster.

🚩 My Opinionated Take: Stop Guessing, Start Measuring.

I see too many devs “eye-balling” padding values to make the UI “look right” on their Pixel 8. This is how you break the app for the guy using a 3-button nav on an entry-level Samsung or a landscape foldable. If you find yourself hardcoding Padding(bottom = 48.dp) to "fix" an E2E overlap, you've already lost. Use the Inset API or don't touch it at all.

The Deep Dive: Architecting Inset Consumption

The official documentation provides a “Hello World” solution. We’ve shifted to a “Manual Inset Consumption” pattern. Think of Inset Consumption as a Financial Ledger. Each level of the UI tree “spends” some of the available padding. If you don’t track the balance, you end up with “Double-Padding” debt.

Here is the ProductionGradeScaffold we built to automate this ledger:

/**
 * We use staticCompositionLocalOf because inset architecture 
 * rarely changes mid-composition.
 */

val LocalConsumedInsets = staticCompositionLocalOf { PaddingValues(0.dp) }

@Composable
fun ProductionGradeScaffold(
    modifier: Modifier = Modifier,
    content: @Composable (PaddingValues) -> Unit
) {
    val systemBarInsets = WindowInsets.systemBars
    Scaffold(
        modifier = modifier,
        contentWindowInsets = systemBarInsets 
    ) { innerPadding ->
        // Provide the 'consumed' padding to the tree
        CompositionLocalProvider(LocalConsumedInsets provides innerPadding) {
            content(innerPadding)
        }
    }
}

🛠 The Infrastructure Take: Composables Should Be “Inset-Blind”

Your Feature Composables should not know that a Status Bar exists. They should only know about the PaddingValues passed to them. By using a CompositionLocal to track what has already been "consumed," we ensure that a nested Legacy Fragment doesn't try to double-dip into the padding budget. Centralize the math, decentralize the rendering.

[Visual Architecture Map]

┌──────────────────────────────────────────┐  <-- Screen Edge (y=0)
│ [System Status Bar] (24dp)               │  
├──────────────────────────────────────────┤  
│ [ProductionGradeScaffold]                │  <-- Consumes Top/Bottom
│  │                                       │
│  ├─ [TopAppBar] (Uses innerPadding.top)  │
│  │                                       │
│  └─ [LegacyFragmentContainer]            │  <-- Reads LocalConsumedInsets
│     └─ [ConstraintLayout] (0dp Padding)  │  <-- Subtraction Logic: 
│                                          │      (Required: 24 - Consumed: 24 = 0)
├──────────────────────────────────────────┤
│ [System Gesture Pill] (48dp)             │
└──────────────────────────────────────────┘  <-- Screen Edge (y=max)

The “Gotchas”: What We Learned the Hard Way

1. fitsSystemWindows is a Zombie: If you have legacy XML, android:fitsSystemWindows="true" is now a recipe for unpredictable behavior.
2. Horizontal Insets on Foldables: Almost no one tests for the “hinge” or “side cutout” in landscape. Use displayCutout insets explicitly.
3. Transparent Bars, Dead Touches: E2E often makes the navigation bar transparent, but it still consumes touch events!

⚠️ The UX Reality Check: Your “Transparent” Nav Bar is a Lie

Designers love the look of content bleeding behind the navigation pill. But as engineers, we know the “Gesture Zone” is a touch-event black hole. If your “Buy Now” button is in that bottom 48dp, it’s a dead button. You must advocate for “UI Safety” even when Design wants “Clean Visuals.” E2E is about drawing in the bars, not interacting in them.

My Controversial Stance: Inset Architecture is a Platform Concern

In the pursuit of “Clean Code,” we often map our ViewModels to “UI States” that include padding values. Stop doing this. If your ViewModel is calculating padding based on insets, you’ve introduced a logic round-trip for a UI-layer concern.

Insets should be handled by your Platform Infrastructure (Scaffolds and Modifiers) so that your Feature Developers don’t even have to think about them. Performance is a feature; architectural purity that causes jank is a failure.

Call to Action

Is your team prepared for the Android 16 rollout, or are you planning to just “slap a padding on it” and hope for the best? If you’ve battled the “double-padding” monster in a hybrid app, I want to hear how you killed it. Let’s argue in the comments.

Android 16’s Edge-to-Edge Mandate: Why Your “Simple Fix” Will Break at Scale was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Landscapist provides a composable image loading library for Jetpack Compose and Kotlin Multiplatform. Among its image composables, LandscapistImage stands out as the recommended choice: it uses Landscapist's own standalone loading engine built from scratch for Jetpack Compose and Kotlin Multiplatform, with no dependency on platform-specific loaders like Glide or Coil.

It handles fetching, caching, decoding, and display internally, and it works identically across Android, iOS, Desktop, and Web. On top of that, LandscapistImage exposes a plugin system through the ImagePlugin sealed interface, giving you five distinct hook points into the image loading lifecycle where you can inject custom behavior without modifying the loader itself.

In this article, you’ll explore the ImagePlugin architecture, examining each of the five plugin types and why they exist, how ImagePluginComponent collects and dispatches plugins through a DSL, and how built in plugins like PlaceholderPlugin, ShimmerPlugin, CircularRevealPlugin, PalettePlugin, and ZoomablePlugin implement these interfaces in practice.

Why LandscapistImage for plugins

Before diving into the plugin system, it is worth understanding why LandscapistImage is the best foundation for plugin based image loading.

LandscapistImage uses its own standalone engine (landscapist-core) rather than delegating to Glide, Coil, or Fresco. This means every stage of the image loading pipeline, from network fetching through memory caching to bitmap decoding, is controlled by a single Kotlin Multiplatform implementation. The benefit for plugins is direct: when LandscapistImage transitions from loading to success, it knows the exact moment the bitmap becomes available. It passes that bitmap directly to PainterPlugin and SuccessStatePlugin without any adapter layer or platform specific conversion. The plugin receives a real ImageBitmap, not a wrapped platform object.

This also means LandscapistImage works on every Compose Multiplatform target. A ShimmerPlugin you write for Android runs identically on iOS and Desktop. There is no "this plugin only works with Glide" problem, because there is no Glide in the pipeline.

If you look at the LandscapistImage composable signature, you can see where plugins fit in:

The component parameter is the entry point for the plugin system. When you pass a rememberImageComponent { ... } block, every plugin you add inside that block gets dispatched at the correct lifecycle stage automatically. You can still use loading, success, and failure lambdas for one off customization, but plugins are the reusable, composable alternative.

The fundamental problem: Extending image loading without modifying it

Consider a common scenario: you are loading images with LandscapistImage and want to show a shimmer effect during loading, apply a circular reveal animation on success, and extract the dominant color from the loaded image. Without a plugin system, you would need to manage all of this manually:

This approach has two problems. First, each behavior is tightly coupled to the call site. If you want the same shimmer in ten different screens, you duplicate the logic ten times. If you want to add a new behavior, you touch every call site. Second, behaviors that operate at different conceptual layers (UI rendering, painter transformation, side effects) are mixed together in the same lambda, making it harder to reason about what happens when.

The plugin system solves both problems. It turns each behavior into a self contained, reusable component that declares which lifecycle stage it belongs to. You compose them together declaratively, and the dispatch mechanism handles the rest.

Introducing ImagePlugin

The ImagePlugin system is designed around one principle: adding or removing image loading behavior should be as simple as adding or removing a single line of code. In practice, that means attaching a plugin with the + operator and detaching it by deleting that line:

If the shimmer is no longer needed, you remove the +ShimmerPlugin() line. The rest of the plugins continue to work without any changes. There is no cleanup code, no conditional branches to update, and no shared state to untangle. Each plugin is self contained: it carries its own configuration, renders its own UI or performs its own side effect, and has no dependency on other plugins in the list.

This makes the plugin system useful beyond pre built options. When your team needs custom behavior tied to the image loading lifecycle, whether that is logging analytics when an image loads, showing a domain specific error screen on failure, or applying a brand specific visual transformation, anyone on the team can implement a custom ImagePlugin, attach it with +, and remove it later if the requirement changes. The plugin boundary keeps custom behavior isolated from the image loading pipeline, so adding or removing a plugin never risks breaking the loader itself.

The plugin system supports five types of plugins, each targeting a different moment in the image loading lifecycle. Let’s examine the interface that defines them.

The ImagePlugin sealed interface

The foundation of the plugin system is a sealed interface with five subtypes. Each subtype corresponds to a specific moment in the image loading lifecycle and receives parameters appropriate for that moment. If you examine the ImagePlugin interface:

The remaining three types follow the same pattern:

The reason for five separate types rather than a single onStateChanged callback is that each lifecycle stage has fundamentally different needs.

PainterPlugin receives the loaded ImageBitmap and the current Painter, and returns a new Painter. This is where you transform the visual output itself. The return type is important: because it takes a Painter in and returns a Painter out, multiple painter plugins can be chained. A circular reveal wraps the original painter, then a blur wraps the reveal, forming a decoration chain. This works because LandscapistImage provides the decoded ImageBitmap directly from its internal cache, so painter plugins always have access to the raw bitmap data for their transformations.

LoadingStatePlugin receives the Modifier, ImageOptions, and an executor callback. The executor is a composable lambda that LandscapistImage provides for rendering a low resolution thumbnail while the full image loads. Plugins like ThumbnailPlugin use this executor to request a smaller version of the same image from the loading pipeline. Other loading plugins like ShimmerPlugin ignore the executor entirely and render their own UI instead.

SuccessStatePlugin receives the loaded imageBitmap along with the original imageModel. This runs after a successful load, and its primary purpose is side effects rather than UI rendering. The imageModel parameter is included because some side effects, like palette caching, need to associate their results with the original image URL.

FailureStatePlugin receives the Throwable reason for the failure. A custom failure plugin could use this to display different error images based on the failure type, for example showing a network error icon for IOException and a format error icon for IllegalArgumentException.

ComposablePlugin receives the entire image content as a composable lambda. Unlike the other four types, this plugin does not operate on a specific lifecycle state. Instead, it wraps the rendered image content, regardless of which state produced it. This makes it the right choice for behaviors that apply to the image as a whole, like gesture handling, overlays, or accessibility wrappers.

The key observation: the sealed interface ensures every plugin must declare which lifecycle stage it belongs to at compile time. There is no ambiguity about when a plugin runs, and the compiler enforces that you implement the correct compose signature for your chosen stage.

How plugins are collected: ImagePluginComponent

Plugins need a container that collects them and makes them available to the image composable. The ImagePluginComponent class provides a DSL for collecting plugins into an ordered list:

The unaryPlus operator is what enables the +Plugin() syntax. When you write +ShimmerPlugin(), Kotlin invokes the unaryPlus extension function defined inside ImagePluginComponent, which calls add() internally and appends the plugin to the mutable list. Because this is an operator defined in the scope of the component, it only works inside the ImagePluginComponent receiver block, preventing accidental use outside of plugin configuration.

The rememberImageComponent function creates and remembers this component across recompositions:

The remember call ensures the plugin list is built once and cached. This matters for performance: without it, every recomposition would recreate the plugin list and all plugin instances. You use it like this:

Three plugins, three different lifecycle stages, all composed into a single component with a clean DSL. The order in the block determines the order of execution within each plugin type.

Built in plugins: From simple to advanced

Now let’s examine how the built in plugins implement these interfaces. Each example demonstrates a different pattern for how plugins interact with LandscapistImage's loading pipeline.

PlaceholderPlugin: The simplest LoadingStatePlugin

PlaceholderPlugin is the most straightforward implementation. It displays a static image while loading is in progress, using whatever image source you provide. If you examine the PlaceholderPlugin.Loading class:

The source parameter accepts an ImageBitmap, ImageVector, or Painter. The compose function renders that source using ImageBySource, passing through all the image options from the parent LandscapistImage. This is an important detail: the plugin inherits contentScale, alignment, and other display options automatically, so the placeholder looks consistent with the final image. The apply return pattern means the plugin returns itself, a convention used across all state plugins.

The failure variant follows the same structure but implements FailureStatePlugin instead:

Notice how the reason: Throwable? parameter is available but unused here. The built in PlaceholderPlugin.Failure shows the same static image regardless of the error type. A custom failure plugin could inspect this parameter to display different images: a network icon for connection errors, a broken image icon for decode failures, and so on. This is where building your own plugin adds value over the built in options.

ShimmerPlugin: Adding animated loading state

ShimmerPlugin is another LoadingStatePlugin, but instead of a static image, it displays an animated shimmer effect that signals to the user that content is loading:

The structure is identical to PlaceholderPlugin. The only difference is what gets composed. Instead of ImageBySource, it renders a ShimmerContainer with customizable base and highlight colors. This demonstrates how the plugin interface keeps each implementation focused on a single responsibility: PlaceholderPlugin renders a static image, ShimmerPlugin renders an animation, but both hook into the same loading state lifecycle through the same compose signature.

Also notice that ShimmerPlugin ignores the executor parameter entirely. The executor is there for plugins that want to render a low resolution thumbnail while loading (like ThumbnailPlugin), but ShimmerPlugin has no use for it. This is a benefit of the interface design: plugins receive all the context they might need, but they are free to use only what is relevant to their behavior.

CircularRevealPlugin: Transforming the painter

CircularRevealPlugin demonstrates the PainterPlugin type, which operates on a fundamentally different level than state plugins. Instead of composing UI at a lifecycle stage, it transforms the Painter that renders the image:

The compose function receives the current painter and wraps it with a circular reveal animation painter using rememberCircularRevealPainter. The original painter is passed through as the base, so the animation decorates the existing rendering behavior rather than replacing it. When LandscapistImage first transitions to the success state, the circular reveal painter starts its animation, gradually revealing the image from the center outward.

The BlurTransformationPlugin follows the same pattern:

Both take a painter in and return a new painter out. Because PainterPlugin forms a chain (as shown in the composePainterPlugins dispatch function earlier), you can stack multiple painter transformations. If you add both CircularRevealPlugin and BlurTransformationPlugin, the blur is applied on top of the circular reveal, which wraps the original painter. Reversing the order would produce a different visual result: the reveal would animate over an already blurred image.

PalettePlugin: Reacting to success with side effects

PalettePlugin implements SuccessStatePlugin, running only after the image loads successfully. Unlike the plugins above, PalettePlugin does not render any UI. Its purpose is to extract dominant colors from the loaded bitmap and expose them to the rest of your composable tree:

The compose function triggers the palette generation:

This demonstrates that SuccessStatePlugin is not limited to visual rendering. The compose function performs a side effect: generating a color palette from the loaded bitmap and notifying through the paletteLoadedListener. The LocalInspectionMode check skips palette generation during IDE preview, since there is no real bitmap available in preview mode. The useCache flag avoids redundant palette generation when the same image is recomposed without changing.

Because LandscapistImage provides the imageBitmap directly from its internal decoding pipeline, PalettePlugin does not need to re decode the image or request it from a platform specific API. This is one of the benefits of the standalone engine: the bitmap is already available as a Compose ImageBitmap, ready for analysis.

ZoomablePlugin: Wrapping the entire content

ZoomablePlugin implements ComposablePlugin, which gives it a different scope than the other four plugin types. Instead of operating on a specific loading state or transforming the painter, it wraps the entire rendered image content:

The content lambda contains whatever LandscapistImage has rendered for the current state, including any modifications from painter plugins. ZoomableContent wraps this content with a gesture detector that handles pinch to zoom, pan, and double tap. The user sees the image and can interact with it without any additional code at the call site.

The optional state parameter is what makes this plugin particularly useful. If you pass in a ZoomableState from outside, you can read the current zoom level, pan offset, and rotation from other parts of your composable tree. You could display a zoom percentage indicator, add a "reset zoom" button, or synchronize zoom across multiple images. If you do not pass a state, the plugin creates one internally, keeping the simple case simple.

This is the most flexible plugin type because it has full control over how the image content is presented within the composable hierarchy. You could use ComposablePlugin to add overlays, gesture detectors, context menus, or any other composable wrapper around the image.

Putting it all together

With all five plugin types available, you can compose a complete image loading experience with LandscapistImage in a few lines:

Each plugin handles one concern. The ShimmerPlugin shows an animated placeholder during loading. The CircularRevealPlugin animates the painter when the image arrives. The PalettePlugin extracts colors after loading. The PlaceholderPlugin.Failure displays an error image on failure. The ZoomablePlugin wraps the entire content with zoom gestures. Five plugins, five different lifecycle hooks, zero manual state management.

Because the plugin system operates at the Landscapist layer above any specific image loader, the same component configuration also works with GlideImage, CoilImage, and FrescoImage. But LandscapistImage gives you the added benefit of a standalone, multiplatform engine with no third party loader dependency. Your plugins, your loader, and your UI all run from a single Kotlin Multiplatform codebase.

In this article, you’ve explored the ImagePlugin sealed interface and its five subtypes, how ImagePluginComponent collects plugins through a DSL, and how built in plugins like PlaceholderPlugin, ShimmerPlugin, CircularRevealPlugin, PalettePlugin, and ZoomablePlugin implement each plugin type in practice.

Understanding this plugin architecture opens up a wide range of practical use cases. Because each plugin is self contained and attaches with a single + line, you can freely mix and match behaviors for increasingly complex scenarios, a shimmer placeholder combined with a circular reveal and palette extraction, for example, without the complexity scaling with the number of features. When requirements change, you detach a plugin by removing one line and attach a new one in its place.

As always, happy coding!

— Jaewoong (skydoves)

Build Your Own Landscapist Image Plugin in Jetpack Compose was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Jetpack Compose development, you are probably rebuilding your app tens of times per day to adjust the subtle design specifications. Each rebuild takes anywhere from 1 min to several minutes (~30 mins depending on your project scale), followed by navigating back to the screen you were working on and reconstructing the state you just lost for fair self-testing.

Let’s be honest. That adds up to one to two hours of dead time per day, every day, spent waiting instead of iterating. Well, for some, it’s the perfect coffee break. For others, it’s a frustrating blocker that slows everything down. That’s exactly the problem Compose HotSwan is built to solve.

Compose HotSwan is a JetBrains IDE plugin for Android Studio/IntelliJ and a Gradle compiler plugin that performs Jetpack Compose hot reload on real physical Android devices/emulators, applying code changes to a running app in one to three seconds with full state preservation as possible.

In this article, you will explore what you can do with Compose HotSwan, the engineering constraints that make hot reload on Android difficult, how Compose HotSwan works within those constraints, and its core capabilities.

The build tax: What slow feedback actually costs you

Every Android developer knows the routine. You tweak a modifier, hit run, and wait. The build compiles, dexes, installs, and restarts your app. It launches from the home screen. You tap through multiple screens, scroll to the right position, and recreate the state just to see a one-line change.

This is not just an inconvenience. It changes how you make decisions, and the cost compounds throughout your day.

Picture this. You are working on a screen buried several layers deep. Everything is set up exactly where you need it. You change fontSize = 16.sp to 18.sp. Gradle starts building. On a small project, it takes a minute. On a large codebase, it takes much longer. The app reinstalls and restarts from the “home screen”.

All your state is gone. Now you navigate back again. Load the data again. Scroll to the same spot again. And when you finally get there, you cannot remember what the previous state looked like. The context you built up is gone after a single build cycle.

Now you do it all over again. And by the time you get back, you have already forgotten what you were comparing.

With hot reload, this entire loop collapses. You change a value, save the file, and see the result on your device in ~1 second, with the same screen, the same state, and the same scroll position still in place. The video below shows this in practice: modifying composable code and watching the running app update in real time without a rebuild or restart.

When you save a file, it compiles only the changed code via Gradle’s incremental build, extracts the modified classes from the resulting DEX, transfers them to the device, and swaps them directly in ART’s memory using a native agent. It then triggers a scoped recomposition that invalidates only the affected composable scopes while preserving the slot table structures and all embedded state.

It sounds like a compelling shift in how you build with Compose, right? But on Android, this is fundamentally harder due to ART’s strict runtime constraints, which make class swapping far more restrictive than on other platforms. The engineering behind Compose HotSwan is covered later in this article.

Installation and setup

Getting Compose HotSwan running takes three primary steps: install the IDE plugin, apply the Gradle plugin, and sync.

Requirements

Make sure your environment meets these prerequisites. Your project’s minSdk does not matter for Compose HotSwan. What matters is the API level of the device you are running on. API 30 or higher is recommended because it supports a broader range of reloadable changes, including new functions, enum values, and data class properties.

For the full requirements and Gradle configuration options, see the Requirements and Gradle Configuration documentation.

Step 1: Install the IDE plugin

Open Android Studio (Meerkat 2024.3 or later) and navigate to Settings > Plugins > Marketplace. Search for "Compose HotSwan" and install it. Restart the IDE when prompted.

Step 2: Apply the Gradle plugin

Add the HotSwan compiler plugin to your version catalog. In libs.versions.toml:

For the recent version, check out the official release notes docs.

Step 3: Sync and run

Sync Gradle, build your app in debug mode, and run your app on your physical device or emulator. Once the app is running, hit the “Start HotSwan” button and wait a second. Now, you are ready to hot reload. Make a change to any Compose file, save it, and watch the update appear on your device in seconds.

1 more step: Get the Free License

Compose HotSwan is a freemium plugin, and you can start a 2-week free trial with full access to all features. This gives you plenty of time to try it in your own project and experience the impact firsthand.

You can claim your free trial in under 10 seconds by clicking the button in the Compose HotSwan panel with your JetBrains account. As for pricing, well, it’s not about the price. It’s about your time. Save hours every day writing Compose.

What you can hot reload

The scope of reloadable changes directly determines how much of your daily workflow benefits from hot reload. If a tool only handles color and text changes, it helps with a narrow slice of UI iteration. Compose HotSwan covers a broader range because the compiler plugin and native client SDK operate at the class level, not the composable level.

Composable function bodies
Any change inside a composable function body reloads instantly. Text, colors, font sizes, layout modifiers, padding, animation parameters, conditional logic, and child composable structure all work.

Save the file, and the running app updates in place in ~1 second. No rebuild, no reinstall, no navigation.

Adding a new Composable and reordering

You can add a new composable function and reorder existing composable calls within a function, and the state follows each composable correctly. Compose HotSwan’s compiler plugin preserves state continuity across structural changes in your code.

Non-composable function changes

This is one of the key differences from Live Edit, which only supports changes to composable functions. Because Compose HotSwan swaps classes at the ART level, any method body change is reloadable, not just @Composable ones. Changes to ViewModel methods, repository logic, utility functions, and data mappers all hot reload:

Any composable that calls this function displays the updated result on the next recomposition. In practice, this means business logic iteration, not just UI tweaking, benefits from the fast feedback loop.

Resource value changes

Modify existing values in strings.xml, colors.xml, dimens.xml, and drawable files. HotSwan detects resource file changes and hot reloads all your resource value changes instantly.

Note that adding entirely new resources (new string keys, new color entries) changes the R class field assignments, requiring a full rebuild. Modifying existing values works because the resource IDs remain unchanged.

Data class property additions

You can add new properties to data classes, and the toString(), copy(), equals(), and hashCode() methods regenerate automatically:

Note that removing properties or changing their types requires a full rebuild. For the complete list of what you can and cannot hot reload, including edge cases around inline functions, lambda count changes, and cross-file references, see the Supported Changes documentation.

So, how it works: The five-stage pipeline

At a high level, Compose HotSwan executes a five-stage pipeline when you save a file: Save → Compile → Extract → Swap → Recompose. The IDE detects the changed file, identifies the Gradle module, runs an incremental compilation on just that module, extracts only the modified classes from the resulting DEX, swaps them into the device’s memory via the native ART agent, and triggers a scoped recomposition.

Each of these five stages contains layers of a waaayyyy more complexity that this summary does not begin to cover. The compilation stage alone involves custom IR transformations, each file compilation, and parameter reservation strategies. The extraction stage performs differential class analysis across lambda renumbering boundaries.

The swap stage interacts with the Android runtime under constraints that vary by API level. The recomposition stage integrates with the Compose runtime’s slot table through several invalidation strategies. For a more detailed (but still summarized) breakdown of each stage, see the How It Works documentation.

Compose HotSwan targets ART, so its architecture is fundamentally different from JVM-based hot reload and had to be built from scratch in a completely different environment. If you are curious about how hot reload works on the JVM (Desktop) side, the JetBrains team published The Journey to Compose Hot Reload 1.0.0, which covers their own path to shipping hot reload for Compose Desktop. Even that article, operating in the comparatively forgiving JVM environment, clearly had to compress an enormous amount of internal detail to fit into a single post.

Why hot reload on Android is hard

Hot reload on Flutter (Dart VM) and React Native (JavaScript engine) all exist in mature forms. Android is the outlier, and the reason is the runtime itself.

This is.. just a research-level problem

There is no public API, library, or documented technique for doing this. This is definitely NOT a toy/pet level project. The Kotlin compiler’s internals, ART’s class swapping behavior, the Compose compiler’s code generation patterns, and D8’s DEX output format all intersect in ways that no one has had to reason about jointly before.

The HotSwan compiler plugin operates at the IR (Intermediate Representation) level of the Kotlin compiler, the same layer where the Compose compiler plugin itself runs. It analyzes function bodies, tracks composable identity, and performs independent compilation so that each function can be swapped in isolation without invalidating unrelated code.

On the device side, the problem shifts to DEX bytecode. HotSwan performs structural analysis on compiled DEX files, comparing class schemas between the installed APK baseline and the newly compiled output. But “comparing class schemas” understates the complexity. The Kotlin compiler generates synthetic classes for lambdas, and these classes are assigned sequential numeric identifiers. If you add a single lambda in the middle of a file, every subsequent lambda’s class name shifts. It’s a shit.

The Data class and ViewModel… It's another headache. Data class modifications require a binary-level schema transformation to reconcile the old memory layout with the new definition. And the Compose compiler generates its own layer of synthetic code, group keys and slot table entries, that track composable identity for recomposition. All of these interact. A change to a composable body can simultaneously trigger lambda renumbering, slot table key changes, and group restructuring, and Compose HotSwan has to handle all of it atomically.

The biggest challenge: ART treats class structure as immutable

The Android Runtime (ART) performs aggressive optimizations when it loads your app. It compiles bytecode ahead of time, inlines method calls, and lays out objects in memory based on the class definition at load time. Once a class is loaded, ART treats its structure as mostly immutable. You cannot add or remove fields, change method signatures, or alter the class hierarchy at runtime. Only method bodies can be replaced.

This is a fundamental constraint. A hot reload system for Android must work entirely within these boundaries: detect which changes are safe to swap, and fall back gracefully for everything else.

State preservation is a thing; it’s really a matter

Hot reload without state preservation is just a faster rebuild tool. You still lose navigation stacks, form data, scroll positions, and all the context you spent time constructing. The time savings from skipping the build are negated by the time spent reconstructing state.

The real engineering challenge is making the reload invisible: swapping method bodies in memory while keeping the Compose runtime’s slot table intact, so every remember{} value, every scroll position, every dialog state, and every ViewModel instance survives. This requires a compiler plugin that tracks composable identity across reloads and a bunch of multi-tier recomposition strategy that degrades gracefully when targeted invalidation is not possible.

Other platforms control their own runtime

Flutter runs Dart in the Dart VM. React Native runs JavaScript in Hermes or JSC. Both have full control over class definitions, memory layout, and code loading, which makes hot reload a solvable problem at the VM level. ART is a different kind of runtime. It was designed for production performance: ahead-of-time compilation, aggressive inlining, and fixed memory layouts.

These are the right trade-offs for shipping apps, but they work against developer iteration. Compose HotSwan does not try to replace ART or work around it. It operates within ART’s constraints, which is what makes the engineering difficult and what makes the result reliable.

For a deeper look at the full pipeline and the engineering behind each stage, see the How It Works documentation.

Do the math and save your time

To put concrete numbers on this: say you rebuild 30 times per day during active UI work, and each cycle costs you 2 minutes (build + navigate + reconstruct state). That is 60 minutes per day spent waiting. With hot reload completing in 1 to 3 seconds and preserving your full app state, those same 40 iterations take roughly 2 minutes total. That is over an hour reclaimed per day.

But 2 minutes per build is an optimistic number. It assumes a small to mid-sized project with a warm Gradle daemon. If you work at a large organization where the project has over 1,000 modules, a single incremental build can take 15 to 20 minutes. At that scale, 30 iterations per day is not realistic; developers self-limit to fewer attempts because each one is so expensive.

Even if you only rebuild 15 times at 15 minutes each, that is nearly 4 hours per day lost to the build cycle. With hot reload, those 15 iterations take under a minute. That is most of a working half-day returned to actual development, every day, for every engineer on the team. Multiply that across a team of 20, and you are looking at hundreds of engineering hours per month.

When adopted at the team level, hot reload becomes a productivity multiplier for the entire engineering organization. Fewer build cycles means less context switching, faster code reviews with visual proof of changes, tighter designer-developer iteration loops, and shorter time from prototype to production. It is not just about saving minutes per developer. It is a structural improvement to how a development team ships UI work.

Conclusion

Compose HotSwan isn’t built to showcase the technical complexity of hot reload; it’s designed to meaningfully support the Android developer ecosystem and directly improve developer productivity. Going forward, it will continue to focus on helping developers work more efficiently.

Although not covered in this post, Compose HotSwan also includes several useful features:

• Preview Runner that runs your Preview composable in ~1 second on your real device. Then you can generate full, pretty UI docs by running just a single Gradle task. This is a real gem.
• Screenshot Snapshots that automatically capture screenshots on every hot reload and generate shareable web pages for collaboration with designers
• MCP integration that connects with your AI agent to trigger hot reload and supports 20+ MCP tasks.

Compose HotSwan is available on the JetBrains Marketplace. The full documentation, including detailed guides for each feature covered in this article, is at hotswan.dev/docs. For bug reports and feature requests, file an issue on GitHub or join the Discord.

As always, happy coding!

— Jaewoong (skydoves)

Jetpack Compose Hot Reload on Real Android Devices: Reduce the Build Time to Seconds was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our Android app loads a heavy, interactive SVG inside a WebView — think thousands of path elements, JavaScript interactivity, the works. The problem was that adding the SVG content into the WebView would cause a noticeable lag. Not a crash, not an ANR, just… a stutter. The kind of thing that makes an app feel cheap.

The workaround someone had added before?

delay(300)
// then load SVG into WebView
webView.loadDataWithBaseURL(null, svgHtml, "text/html", "UTF-8", null)
webView.visibility = View.VISIBLE

A 300ms artificial delay before loading the content, just to give the WebView time to “settle in” after inflation. Classic band-aid.

After digging in, the root cause was surprising: a single <WebView> tag in the XML layout.

What was actually happening

Here’s what the layout looked like:

<WebView
    android:id="@+id/web_view"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:visibility="invisible"
    ... />

Looks harmless, right?

The issue is that when Android inflates this XML, it creates the WebView immediately — before the Fragment even hits onViewCreated().

And WebView isn’t just another TextView.

Under the hood it’s spinning up a Chromium renderer, allocating native memory, setting up IPC channels. On a older phone, that’s easily 100–200ms of work.

If you try to load HTML with heavy SVG content into a WebView that’s still initializing internally, the two operations compete for resources — and the result is a visible lag. That’s why the delay(300) “worked”: it was giving the WebView enough breathing room to finish setting up before throwing a complex HTML with SVG at it.

But a hardcoded delay is fragile. Too short on a slow device — lag is still there. Too long on a fast device — the user is staring at a blank screen for no reason.

The fix that actually worked

Replace the <WebView> in XML with an empty <FrameLayout>:

<FrameLayout
    android:id="@+id/web_view_container"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:visibility="gone"
    ... />

Then create the WebView programmatically and load the content right away:

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    
    webView = WebView(requireContext()).apply {
        layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)
    }
    binding.webViewContainer.addView(webView)
    
    webView.apply {
        settings.javaScriptEnabled = true
        webViewClient = MyWebViewClient()
        loadUrl("file:///android_asset/big_svg.html")
    }
}

The key difference is when initialization happens relative to content loading.

When WebView lives in XML, Android inflates it eagerly — during layout inflation, before your Fragment even reaches onViewCreated(). If you immediately throw heavy SVG content at it, you're racing against Chromium's internal setup: renderer threads, native memory allocation, IPC channels. On a slower device, that race produces visible jank.

When you create WebView programmatically inside onViewCreated(), you control the timing explicitly. The WebView initializes, gets added to the hierarchy via addView(), and then you load content — sequentially, not in parallel. No artificial delay needed because there's no race condition to paper over.

And don’t forget to clean up — remove the WebView from the container before destroying it:

override fun onDestroyView() {
    binding.webViewContainer.removeView(webView)
    webView.destroy()
    super.onDestroyView()
}

Why this matters more than you’d think

While working on this, a few other things became obvious about why the XML approach was problematic.

The memory leak thing. When a WebView sits in the XML layout, it’s tied to the Fragment’s context through the view hierarchy. If some JavaScript callback or pending request keeps it alive past onDestroyView(), the whole view tree leaks with it. That removeView → destroy pattern above is specifically to avoid this.

Also — and this one bit us in a different context — XML inflation uses the Activity’s context. So the WebView holds a strong reference to the Activity. We’re building an SDK, so we don’t control the host app’s lifecycle. Using requireContext().applicationContext when creating the WebView programmatically breaks that reference. Probably doesn’t matter if you’re building a regular app, but for SDK work it’s kind of essential.

And then there’s the obvious one: sometimes you don’t even know if you need the WebView yet. Config might not be loaded, user might not have permissions. With XML you pay the full cost upfront no matter what.

So when should you still use XML?

Honestly? For simple stuff.

If the WebView is showing a privacy policy or a help page — something lightweight where 200ms of inflation time doesn’t matter — XML is fine. Less code, easier to read, visible in the layout preview.

But the moment heavy content, complex layouts, SDK work, or that lag on content load comes into play — switch to programmatic.

It’s maybe 5 extra lines of Kotlin, and it solves problems you didn’t even know you had.

A <FrameLayout> replacing a delay(300) isn't the kind of fix you'd put on a resume. But it's the kind that makes you actually understand what WebView is doing underneath — and why timing matters more than most Android developers realize.

If you’re loading anything heavier than a static page, programmatic initialization isn’t a premature optimization. It’s just the right default.

Stop Inflating WebViews in XML: A Performance Fix for Heavy Content was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

The problem

AI agents trigger Gradle builds constantly. If your setup isn’t perfectly consistent across projects — different Gradle wrapper versions, different JDK versions — daemons don’t get reused. They pile up. Kotlin compilation daemons do the same.

No warnings, nothing crashes. Your machine just gets slower throughout the day. You blame Chrome, you blame Android Studio, you restart, and the cycle repeats.

Here’s what my Activity Monitor looks like after a few hours of AI-assisted Android development across different projects:

A bunch of java processes sitting idle, eating over 7 GB of RAM combined. Gradle daemons, Kotlin compilation daemons — just waiting for a build that probably won't come.

What I built

Java Daemon Watcher — a small macOS app that detects idle Gradle and Kotlin daemons and kills them automatically. It uses jps and CPU sampling to find idle daemons, kills them after a configurable timeout. Allowlist-based — never touches your IDE.

Saves me around 100GB of RAM per week.

How it works

The app runs a simple three-step pipeline on a configurable interval:

1. Discovery. It runs jps -lm (bundled with every JDK) to list all running Java processes with their main class names.

2. Filtering. It matches processes against an allowlist of known daemon classes:

• org.gradle.launcher.daemon.bootstrap.GradleDaemon
• org.jetbrains.kotlin.daemon.KotlinCompileDaemon

Everything else — your IDE, app servers, any other Java process — is never touched.

3. Idle detection + cleanup. For each daemon, the app samples CPU usage. If a daemon stays idle longer than the configured threshold, it gets a SIGTERM — the same graceful shutdown signal gradle --stop uses.

App Configuration

You can set the idle timeout, scan interval, and enable auto-start at login:

Open source

MIT licensed: github.com/grishaster80/java-daemon-watcher

If you try it, I’d love to hear feedback — issues, feature requests, or just a star if it helped.

Have you noticed this problem on your machine? If you try the tool — how much RAM did it save you? Would love to hear your numbers!

AI Coding Agents Are Silently Eating Your RAM If You Do Android Development was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

A glowing snake border may sound like a simple UI effect. On the web, there are many examples, variants, and breakdowns of how to build it. But on native Android, I have not really seen solid implementations done properly. Most of them are either simplified to a circle with plain rotation, or they use the same rotation-based progress idea even for rectangle shapes. As a result, the motion stops being uniform and starts to feel uneven and broken.

Let’s fix that properly.

Warning: this solution is primarily a showcase or a learning exercise. Never ever ship a continuously running animation like this in production unless you fully understand its performance implications and can guarantee it stays within the 16 ms frame budget.

You will pay for this twice: first in development and maintenance — including the cost of supporting older and lower-end devices — and then, more importantly, in user experience. Users are extremely sensitive to even minor stutters, freezes, or small FPS drops, especially on budget devices where performance is already constrained.

This article is part of a glowing snake border series:

• Part 1 — Animated Snake Border for CircleShape.

• Part 2 — Animated Snake Border for Rectangle Shapes . — You are here
• Part 3 — Animated Snake Border for any Shape; Path & Sampling trick (coming soon).

Current article full code: link with running snake.

Problem

A common approach is to animate movement by rotating a line and taking its intersection with the path as the current position.
This works perfectly for circles, but for shapes where width and height differ significantly, the speed varies along the path.
Also, joins between vertical and horizontal segments often create visible seams, breaking the illusion of a continuous shape.
Rounded corners are often ignored completely, with no support for inner (inset) or outer (outset) borders that extend beyond the composable bounds.

Solution Requirements

• Smooth motion — the velocity vector changes smoothly while its magnitude remains constant
• Two-layer snake body — a blurred halo and a thin stroke core, fading smoothly from head to tail until fully transparent
• No visible seams — the snake must appear continuous across all segment joins
• Support for circular shapes
• Support for rectangles with sharp corners
• Rounded corner support
• Support for varying corner radii — the ability to define different radii for each corner
• State persistence — the snake should preserve its state when leaving and re-entering composition
• Encapsulation — the entire effect should be implemented within a single modifier, without spreading logic across the composition
• Dynamic geometry updates — runtime changes in size or shape must not cause discontinuities or jumps; motion should remain smooth and continuous during transitions

Implementation

This article focuses only on the snake movement.
Text-related effects and the glowing halo border when pressed are out of scope and are covered in my previous articles.

Also, for anyone looking for some hidden magic here, there really is none. The whole thing is just a perimeter split into 8 segments: 4 quarter-circle arcs, 2 horizontal lines, and 2 vertical lines. From there, it becomes a fairly boring mechanical routine: compute where the snake head and tail are, determine which segments they fall into, and then render the snake piece by piece inside each affected segment separately.

Step 1 Extract animation STATE:

By state here I mean the variable that describes the snake movement itself. If we treat the full perimeter as a closed contour of normalized length 1, then that variable is simply the animation progress. It moves from 0 to 1, then jumps back to 0 and repeats. Once this value is known, everything else can be derived from it: the head position, the tail position, and the currently covered perimeter segments.

This logic could be moved entirely inside the modifier with Modifier.composed, but I also needed the same progress value outside the modifier to keep it synchronized with the drop shadow angle inside GlowingText. That is why I moved it into a separate helper, rememberRectSnakeState.

Lifecycle observation is also encapsulated there, so the state is not animated when it does not need to be. Another common mistake is to tie progress directly to frame ticks. In that case, if FPS drops by X times,
the snake speed also drops by X times. Here the progress is time-based, so its speed does not depend on frame rate.

 @Stable
  class RectSnakeState internal constructor(
      initialProgress: Float = 0f
  ) {
      var progress by mutableFloatStateOf(initialProgress)
          internal set

      internal var isEnabled by mutableStateOf(true)
      internal var isLifecycleRunning by mutableStateOf(true)

      val isRunning: Boolean
          get() = isEnabled && isLifecycleRunning

      companion object {
          // state saver
          ...
      }
  }

 @Composable
  fun rememberRectSnakeState(
      enabled: Boolean = true
  ): RectSnakeState {
      val state = rememberSaveable(saver = RectSnakeState.Saver) {
          RectSnakeState()
      }
      val lifecycleOwner = LocalLifecycleOwner.current

      state.isEnabled = enabled

      DisposableEffect(lifecycleOwner) {
          // lifecycle observation
          ...
      }

      LaunchedEffect(state.isRunning) {
          if (!state.isRunning) return@LaunchedEffect

          val startProgress = state.progress
          val startFrameNanos = withFrameNanos { it }

          while (true) {
              val frameNanos = withFrameNanos { it }
              val elapsedMs = (frameNanos - startFrameNanos) / 1_000_000f
              val loopProgress = elapsedMs / SnakeLoopAnimationDurationMs
              state.progress = normalizeSnakeProgress(startProgress + loopProgress)
          }
      }

      return state
  }

Step 2: Build the perimeter geometry

The first thing we need is an explicit perimeter model, because the snake should move not along an abstract shape, but along a fully defined geometric track.

In this solution, the perimeter geometry is a precomputed description of that track built from the current size, shape, stroke placement, and resolved corner radii.

As part of that, the full border is reduced to 8 ordered segments: 4 straight edges and 4 quarter-circle arcs. For each segment, we compute its geometry, its length, and the offset at which it starts along the full perimeter.

The final geometry object contains the track bounds (left, top, right, bottom), the radius of each corner (topLeftRadius, topRightRadius, bottomRightRadius, bottomLeftRadius), the centers of the four corner arcs (topRightCenter, bottomRightCenter, bottomLeftCenter, topLeftCenter), the length of every segment, the accumulated start offset of every segment, and the total perimeter length.

Based on this geometry, at any moment of the animation we can determine which segments the snake currently spans and the exact positions of its head and tail on the border.

— quarterTurn is the length coefficient for a quarter-circle arc.
 — topLen, rightLen, bottomLen, and leftLen are the lengths of the straight perimeter segments.
 — topRightArcLen, bottomRightArcLen, bottomLeftArcLen, and topLeftArcLen are the lengths of the four corner arcs.
 — segmentLengths stores the real length of each of the 8 perimeter segments.
 — segmentStarts stores the accumulated offset at which each segment begins along the full perimeter. (Pixel points)
 — totalLen is the total length of the entire perimeter track.
 — topRightCenter, bottomRightCenter, bottomLeftCenter, and topLeftCenter are the arc centers used later for rendering and point lookup.

 private fun buildRectSnakeTrackGeometry(...): RectSnakeTrackGeometry? {
      // track bounds, resolved corner radii, and validation
      ...

      val quarterTurn = PI.toFloat() / 2f

      val topLen = (trackWidth - radii.topLeft - radii.topRight).coerceAtLeast(0f)
      val rightLen = (trackHeight - radii.topRight - radii.bottomRight).coerceAtLeast(0f)
      val bottomLen = (trackWidth - radii.bottomRight - radii.bottomLeft).coerceAtLeast(0f)
      val leftLen = (trackHeight - radii.bottomLeft - radii.topLeft).coerceAtLeast(0f)

      val topRightArcLen = (quarterTurn * radii.topRight).coerceAtLeast(0f)
      val bottomRightArcLen = (quarterTurn * radii.bottomRight).coerceAtLeast(0f)
      val bottomLeftArcLen = (quarterTurn * radii.bottomLeft).coerceAtLeast(0f)
      val topLeftArcLen = (quarterTurn * radii.topLeft).coerceAtLeast(0f)

      val segmentLengths = floatArrayOf(
          topLen,
          topRightArcLen,
          rightLen,
          bottomRightArcLen,
          bottomLen,
          bottomLeftArcLen,
          leftLen,
          topLeftArcLen
      )

      val segmentStarts = FloatArray(segmentLengths.size)
      var totalLen = 0f
      for (index in segmentLengths.indices) {
          segmentStarts[index] = totalLen
          totalLen += segmentLengths[index]
      }

      return RectSnakeTrackGeometry(
          left = left,
          top = top,
          right = right,
          bottom = bottom,
          topLeftRadius = radii.topLeft,
          topRightRadius = radii.topRight,
          bottomRightRadius = radii.bottomRight,
          bottomLeftRadius = radii.bottomLeft,
          segmentLengths = segmentLengths,
          segmentStarts = segmentStarts,
          totalLen = totalLen,
          // arc centers
          topRightCenter = Offset(...),
          bottomRightCenter = Offset(...),
          bottomLeftCenter = Offset(...),
          topLeftCenter = Offset(...),
          // rendering-related geometry fields
          ...
      )
  }

Step 3: Convert animation progress into snake head and tail positions

At this step, we stop working with the static perimeter model and derive the current snake span from the animation progress. This is an internal derived state used only for rendering, not the animation state object
from Step 1. The progress value is first converted into headDistance, which represents the current position of the snake head along the full perimeter length. The actual snake length is then computed from
snakeLengthFraction * totalLen, and tailDistanceis obtained by moving backward from the head along the same perimeter. Once both positions are known, they define the full visible snake span that will later be
rendered from tail to head across the affected segments.

— progress is the normalized animation progress.
 — wrappedProgress keeps the progress inside the looping 0..1 range (normalized animation progress).
 — headDistance is the current head position measured along the full perimeter.
 — snakeLengthFraction defines how much of the perimeter the snake should occupy.
 — snakeLength is the real snake length on the current track.
 — tailDistance is the tail position measured backward from the head.
 — alphaAtDistance(distance) gives the fade value for any point inside the current snake span.

 private fun buildRectSnakeProgressState(
      progress: Float,
      snakeLengthFraction: Float,
      totalLen: Float
  ): RectSnakeProgressState {
      // Keep progress inside the stable [0, 1) loop even if the input overflows.
      val wrappedProgress = ((progress % 1f) + 1f) % 1f
      val headDistance = wrappedProgress * totalLen
      val snakeLength = (snakeLengthFraction.coerceIn(0f, 1f) * totalLen)
          .coerceIn(0f, totalLen)
      val tailDistance = headDistance - snakeLength

      fun alphaAtDistance(distance: Float): Float {
          val relative = (distance - tailDistance) / snakeLength
          return relative.coerceIn(0f, 1f)
      }

      return RectSnakeProgressState(
          headDistance = headDistance,
          snakeLength = snakeLength,
          tailDistance = tailDistance,
          alphaAtDistance = ::alphaAtDistance //(Float) -> Float
      )
  }

Step 4: Split the snake span across the affected segments
If the snake is short enough, it may fit entirely inside a single segment.
In other cases, it spans multiple segments at once.
For each affected segment, we determine which part should be drawn.
This gives us the exact intervals that will be rendered on straight edges and corner arcs.

— startDistance and endDistance define the current snake span on the perimeter: startDistance is the current tail position, and endDistance is the current head position, both measured along the full perimeter path.
 — wrapped keeps the current distance inside the 0..totalLen perimeter range, so we can correctly determine which segment it belongs to.
 — findSegmentIndex(...) tells us which segment the current part of the snake belongs to.
 — segmentStart and segmentEnd define the boundaries of that segment.
 — intervalEnd gives the end of the current piece that can be drawn inside this segment before moving to the next one.

private fun drawDistanceIntervalNative(
      canvas: android.graphics.Canvas,
      geometry: RectSnakeTrackGeometry,
      startDistance: Float,
      endDistance: Float,
      colorFrom: Color,
      colorTo: Color,
      alphaAtDistance: (Float) -> Float,
      paint: Paint,
  ) {
      val totalLen = geometry.totalLen
      var current = startDistance

      while (current < endDistance) {
          val wrapped = ((current % totalLen) + totalLen) % totalLen
          val segmentIndex = findSegmentIndex(geometry.segmentStarts, geometry.segmentLengths, wrapped)
          val segmentStart = geometry.segmentStarts[segmentIndex]
          val segmentEnd = segmentStart + geometry.segmentLengths[segmentIndex]
          val intervalEnd = min(endDistance, current + (segmentEnd - wrapped))

          drawSegmentPartNative(
              canvas = canvas,
              geometry = geometry,
              segmentIndex = segmentIndex,
              startDistance = wrapped,
              endDistance = wrapped + (intervalEnd - current),
              colorFrom = colorFrom,
              colorTo = colorTo,
              alphaAtDistance = alphaAtDistance,
              paint = paint
          )

          current = intervalEnd
      }
  }

Step 5. Render the snake inside drawWithCache

At this point, the geometry and the snake intervals are already known, so only rendering remains. I do it inside drawWithCache to prepare geometry and paint objects once and reuse them during drawing. This keeps the
whole effect inside a single modifier.

From there, the logic is simple: draw every segment currently covered by the snake. Depending on the current head and tail positions, that may be one segment or several at once. With a large snake fraction such as
0.75f, the snake can span most of the perimeter and sometimes touch all 8 segments. Each affected segment is rendered only for the interval that belongs to the current snake span.

Straight segments and corner arcs are rendered differently, but both follow the same interval logic. Segment joints have to use cut ends rather than round caps. If a rounded head or tail is needed, it should be
drawn separately as a circle or semicircle.

fun Modifier.rectSnakeBorder(
      state: RectSnakeState,
      ...
  ): Modifier = this.drawWithCache {
      val geometry = buildRectSnakeTrackGeometry(...)
      if (geometry == null) {
          return@drawWithCache onDrawBehind {}
      }

      val snakeState = buildRectSnakeProgressState(
          progress = state.progress,
          snakeLengthFraction = snakeLengthFraction,
          totalLen = geometry.totalLen
      )

      val bodyStrokePaint = createBodyStrokePaint(...)
      val glowStrokePaint = createGlowStrokePaint(...)
      val glowHeadPaint = createGlowHeadPaint(...)

      val head = pointAtDistance(geometry, snakeState.headDistance)

      onDrawBehind {
          if (snakeState.snakeLength > 0f) {
              drawIntoCanvas { canvas ->
                  val nativeCanvas = canvas.nativeCanvas

                  // Draw the large glowing outer snake body.
                  drawSnakeLayerNative(
                      canvas = nativeCanvas,
                      geometry = geometry,
                      snakeState = snakeState,
                      colorFrom = glowColorFrom,
                      colorTo = glowColorTo,
                      paint = glowStrokePaint
                  )

                  // Draw the glowing outer snake head.
                  nativeCanvas.drawCircle(
                      head.x,
                      head.y,
                      glowingStrokeWidthPx / 2f,
                      glowHeadPaint
                  )

                  // Draw the thin inner snake body on top of the glow.
                  drawSnakeLayerNative(
                      canvas = nativeCanvas,
                      geometry = geometry,
                      snakeState = snakeState,
                      colorFrom = bodyColorFrom,
                      colorTo = bodyColorTo,
                      paint = bodyStrokePaint
                  )
              }

              // Draw the sharp inner head point.
              drawCircle(
                  color = bodyColorTo,
                  radius = bodyStrokeWidthPx / 2f,
                  center = head
              )
          }
      }
  }

The nativeCanvas is needed here for the outer halo body and the halo head, because BlurMaskFilter is only available through the native Android paint pipeline. The inner snake body is not blurred, but it is still
rendered through the same native path simply to reuse the same drawSnakeLayerNative(...) logic.

Blur mask seams problem

There are still some small visual seams between blurred line segments and blurred arcs, especially when the halo body width becomes large. This current approach does not fully eliminate them. I will cover that separately in the next article using a sampling-based approach.

Conclusion

This solution supports CircleShape, RectangleShape, and RoundedCornerShape with varying corner radii, which in practice covers most regular UI elements. For any other generic Shape, I fail explicitly with: error(“rectSnakeBorder supports only RoundedCornerShape, RectangleShape, and CircleShape”)

But for custom shapes, is there a more universal solution that works for any closed shape?

Check out my next article for a more universal solution.

Github link: whole article code and only animated snake package.

Jetpack Compose: Animated Snake Border for Rectangle Shapes was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article I am going to show you cool Android feature, introduced in 2012, and I will try to write UI in Compose for it.

While exploring the depths of the Android system, I stumbled upon a feature that stole my attention. The class I discovered not only intrigued me with its name, but also surprised me yet again with the interesting features hidden within Android.

Back in 2012 Android System UI team introduced in Android 4.2 new feature Daydream, that allows to show content for user while phone is sleeping. You can simple draw any UI or animation for user while they phone is charging. UI elements may also have buttons so in general, it is possible to create a production-ready feature screen. Unfortunately, this feature can’t be enabled automatically. Users must enable it in the Display Settings.

The architecture of this feature similar to adding regular Service. First need to declare new component in the Manifest:

<service
 android:name=".MyDreamService"
 android:exported="true"
 android:description="@string/dream_service_description"
 android:icon="@drawable/dream_service_icon"
 android:label="@string/dream_service_label"
 android:permission="android.permission.BIND_DREAM_SERVICE">

 <intent-filter>
    <action android:name="android.service.dreams.DreamService" />
    <category android:name="android.intent.category.DEFAULT" />
 </intent-filter>
</service>

The official documentation shows simple example of implementing UI for DreamService:

class MyDreamService : DreamService() {

    override fun onAttachedToWindow() {
        super.onAttachedToWindow()

        isInteractive = false;
        isFullscreen = true;
        setContentView(R.layout.dream_service_layout);
    }
}

After that you can see you daydreamer in action

Then question that came to mind — can I create UI in Compose? So, lets try to implement it

As long as setContentView requires only View , we have to make ComposeView

val composeView = ComposeView(this).apply {
    setContent {
        DreamServiceTheme {
            DreamScreen(
                onOpenSettings = { openSettingsAndExitDream() }
            )
        }
    }
}

setContentView(composeView)

Heres the tricky part. Android Service doesn’t really work with View and for this reason Service misses some important for us API. DreamService doesn’t implement

• ViewTreeLifecycleOwner
• SavedStateRegistryOwner

To solve this issue we can extend out DreamService with SavedStateRegistryOwner

class MyDreamService : DreamService(), SavedStateRegistryOwner

That requires us to implement lifecycle and savedStateRegistry

class MyDreamService : DreamService(), SavedStateRegistryOwner {

    private val lifecycleRegistry = LifecycleRegistry(this)
    private val savedStateRegistryController = SavedStateRegistryController.create(this)

    override val lifecycle: Lifecycle
        get() = lifecycleRegistry
    override val savedStateRegistry: SavedStateRegistry
        get() = savedStateRegistryController.savedStateRegistry
        
    // ...  
}

This two property you can call in each DreamService callback so the lifecycle will be in sync with the Compose View. Then we can simple set owner and registry to you ComposeView:

val composeView = ComposeView(this).apply {
    setViewTreeLifecycleOwner(this@MyDreamService)
    setViewTreeSavedStateRegistryOwner(this@MyDreamService)
    // ... 
}

Hope this feature enrich you answer during technical interview since now you know that Activity is not the only component that can represent UI.

Finally find the Android Service of your dreams after 13 years was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.