Jetpack Compose

Jetpack Compose Animations

Jetpack Compose Animations Made Simple: A Complete Beginner-to-Pro Guide

Let’s be real — animations can feel intimidating at first. But once you understand how Jetpack Compose thinks about them, everything clicks into place.

Unlike the old View-based animation system (which involved XML files, ObjectAnimator, and a lot of boilerplate), Jetpack Compose animations are built right into the UI framework — they’re reactive, composable, and surprisingly intuitive.

Whether you’re building a simple button press effect or a complex multi-step transition, Compose gives you the right tool for every situation. This guide walks through every layer of the animation API — from the simplest one-liners to advanced choreography — with real, working code and honest explanations of why things work the way they do.

Prerequisites: Basic Kotlin knowledge and familiarity with Compose fundamentals (composables, state) is helpful but not mandatory. Every concept is explained from the ground up.

Why Jetpack Compose Animations Are a Game-Changer

Before Compose, adding animations to Android apps meant wrestling with AnimatorSet, writing XML animation resources, dealing with lifecycle issues, and hoping nothing crashed on API 21. It was doable, but painful.

Jetpack Compose animations completely rethink this. Because Compose is a declarative UI framework, animations are just another form of state change. You describe what the UI should look like, and Compose figures out how to smoothly get there. That mental model shift makes everything easier.

Here’s a quick side-by-side comparison:

How Compose Thinks About Animation

Think of it like this:

When state changes → Compose automatically animates the UI between old and new values.

Example:

Button size = small → user clicks → state changes → button grows smoothly

You don’t manually trigger animation frames. Compose does it for you.

Understanding this mental model will make everything else click. In Compose, your UI is a function of state:

UI = f(state) — When state changes, Compose re-renders the UI. Animations are just a smooth interpolation between two states over time. You don’t “run” an animation — you change state and tell Compose how to animate the transition.

The animation system in Compose has three layers, and it’s worth knowing which layer you’re working at:

Layer 1 — High-level APIs: AnimatedVisibility, AnimatedContent, Crossfade. These handle the most common cases with zero configuration needed.

Layer 2 — Value-based APIs: animate*AsState, updateTransition, InfiniteTransition. These animate specific values (Float, Dp, Color, etc.) that you then apply in your composables.

Layer 3 — Low-level APIs: Animatable, coroutine-based. Full manual control for complex sequencing, interruptions, or physics-based motion.

The golden rule: start at the highest level that solves your problem. Only go deeper when you genuinely need more control. Most production animations live happily in layers 1 and 2.

The Core Building Blocks

Before writing any animations, it helps to understand the main APIs you’ll actually use:

1. animate*AsState

For simple, one-off animations tied to a single value.

2. updateTransition

For animating multiple values based on the same state.

3. AnimatedVisibility

For showing and hiding composables with animation.

4. AnimatedContent

For switching between UI states.

5. rememberInfiniteTransition

For looping animations.

You don’t need all of them at once. Most real screens use 1–2 of these consistently.

animate*AsState — Your First Animation

This is the most common animation API you’ll use in everyday Jetpack Compose development. The idea is beautifully simple: instead of setting a value directly, you animate towards that value. Compose smoothly interpolates between the old value and the new one whenever the target changes.

There are ready-made variants for the most common types: animateDpAsState, animateFloatAsState, animateColorAsState, animateSizeAsState, animateIntAsState, animateOffsetAsState, and more.

1. animateDpAsState — Smooth Size & Spacing Changes

Let’s say you have a card that expands when selected. Here’s how that looks with a Jetpack Compose animation:

Kotlin
@Composable
fun ExpandableCard() {
    // Track whether the card is selected
    var isExpanded by remember { mutableStateOf(false) }

    // Animate the height based on expanded state
    val cardHeight by animateDpAsState(
        targetValue = if (isExpanded) 200.dp else 80.dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness = Spring.StiffnessMedium
        ),
        label = "cardHeight"   // helps the debugger identify this animation
    )
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .height(cardHeight)    // use the animated value here
            .clickable { isExpanded = !isExpanded },
        elevation = CardDefaults.cardElevation(8.dp)
    ) {
        Box(
            modifier = Modifier.padding(16.dp)
        ) {
            Text("Tap me to expand!")
        }
    }
}

Here, animateDpAsState watches isExpanded. Every time you tap the card, isExpanded flips, which gives animateDpAsState a new targetValue. Compose then smoothly interpolates the height from its current value to the new target. You didn’t write a single frame of the animation — Compose handled it all.

2. animateColorAsState — Smooth Color Transitions

Color animations are incredibly satisfying. Here’s a toggle button that shifts between two colours smoothly:

Kotlin
@Composable
fun ToggleButton() {
    var isActive by remember { mutableStateOf(false) }

    // Colour interpolates between green and grey
    val buttonColor by animateColorAsState(
        targetValue = if (isActive) Color(0xFF4ADE80) else Color(0xFF334155),
        animationSpec = tween(durationMillis = 400),
        label = "buttonColor"
    )

    // Text colour also animates
    val textColor by animateColorAsState(
        targetValue = if (isActive) Color.Black else Color.White,
        animationSpec = tween(durationMillis = 400),
        label = "textColor"
    )

    Button(
        onClick = { isActive = !isActive },
        colors = ButtonDefaults.buttonColors(containerColor = buttonColor)
    ) {
        Text(
            text = if (isActive) "Active ✓" else "Inactive",
            color = textColor,
            fontWeight = FontWeight.Bold
        )
    }
}

3. animateFloatAsState — Alpha, Rotation, Scale

animateFloatAsState is incredibly versatile because so many visual properties are floats — opacity, rotation, scale, and more. Here’s a smooth fade-and-scale animation for an icon:

Kotlin
@Composable
fun FadeScaleIcon(isVisible: Boolean) {
    val alpha by animateFloatAsState(
        targetValue = if (isVisible) 1f else 0f,
        animationSpec = tween(durationMillis = 300),
        label = "alpha"
    )

    val scale by animateFloatAsState(
        targetValue = if (isVisible) 1f else 0.5f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioLowBouncy,
            stiffness = Spring.StiffnessLow
        ),
        label = "scale"
    )
   
    Icon(
        imageVector = Icons.Default.Notifications,
        contentDescription = "Notification",
        modifier = Modifier
            .graphicsLayer {
                this.alpha = alpha        // apply animated alpha
                this.scaleX = scale       // apply animated scale
                this.scaleY = scale
            },
        tint = Color(0xFF4ADE80)
    )
}

Always prefer graphicsLayer { } over Modifier.alpha() or Modifier.scale() for animated properties. graphicsLayer runs on the RenderThread and doesn’t trigger recomposition for each frame, making it significantly more performant.

AnimatedVisibility — Show & Hide with Style

AnimatedVisibility is probably the most commonly used high-level Jetpack Compose animation API. It wraps a composable and animates its entrance and exit automatically. You just toggle a boolean.

Kotlin
@Composable
fun ErrorBanner(
    hasError: Boolean,
    message: String,
    onDismiss: (() -> Unit)? = null
) {
    AnimatedVisibility(
        visible = hasError,
        enter = slideInVertically(initialOffsetY = { -it }) + fadeIn(),
        exit = slideOutVertically(targetOffsetY = { -it }) + fadeOut()
    ) {
        Card(
            modifier = Modifier
                .fillMaxWidth()
                .padding(16.dp)
                .clickable(enabled = onDismiss != null) {
                    onDismiss?.invoke()
                },
            colors = CardDefaults.cardColors(
                containerColor = Color(0xFFEF4444)
            )
        ) {
            Text(
                text = message,
                color = Color.White,
                modifier = Modifier.padding(16.dp)
            )
        }
    }
}

@Preview(showBackground = true)
@Composable
fun ErrorBannerPreview() {
    var hasError by remember { mutableStateOf(false) }

    MaterialTheme {
        Box(
            modifier = Modifier.fillMaxSize(),
            contentAlignment = Alignment.Center
        ) {
            Column(horizontalAlignment = Alignment.CenterHorizontally) {

                Button(onClick = { hasError = !hasError }) {
                    Text("Show Error")
                }

                Spacer(modifier = Modifier.height(12.dp))

                ErrorBanner(
                    hasError = hasError,
                    message = "Something went wrong!",
                    onDismiss = { hasError = false }
                )
            }
        }
    }
}

The real power of AnimatedVisibility is how you can combine enter/exit transitions using the + operator. Here are all the available transitions you can mix and match:

  • fadeIn / fadeOut
  • slideInHorizontally / slideOutHorizontally
  • slideInVertically / slideOutVertically
  • expandIn / shrinkOut
  • expandHorizontally / shrinkHorizontally
  • expandVertically / shrinkVertically
  • scaleIn / scaleOut

Using AnimatedVisibility Inside a List

One important nuance: when using AnimatedVisibility inside a LazyColumn, always provide stable key values so Compose can track item identity across recompositions:

Kotlin
@Composable
fun AnimatedListInteractive() {
    // Original list (source of truth)
    val allItems = remember {
        listOf("Apple", "Banana", "Cherry", "Date", "Elderberry")
    }

    // Track removed items
    val removedItems = remember { mutableStateListOf<String>() }

    LazyColumn {
        items(
            items = allItems,
            key = { it }
        ) { item ->

            val isRemoved = item in removedItems

            AnimatedVisibility(
                visible = !isRemoved,
                enter = expandVertically() + fadeIn(),
                exit = shrinkVertically() + fadeOut(),
                modifier = Modifier.animateItem()
            ) {
                ListItem(
                    headlineContent = { Text(item) },
                    modifier = Modifier
                        .fillMaxWidth()
                        .clickable {
                            removedItems.add(item) // trigger animation
                        }
                )
            }
        }
    }
}

@Preview(showBackground = true)
@Composable
fun AnimatedListPreview() {
    CenteredPreview {
        AnimatedListInteractive()
    }
}

Important: Without stable keys, Compose can’t track item identity across recompositions, and your exit animations will be silently skipped.

AnimatedContent — Swapping Composables Smoothly

AnimatedContent is like a supercharged version of AnimatedVisibility. Instead of showing or hiding content, it animates between different pieces of content as its target state changes. Think of it as an animated when expression.

A great example: a loading/content/error state machine where you want each state to visually transition into the next.

Kotlin
sealed class UiState {
    object Loading : UiState()
    data class Success(val data: String) : UiState()
    object Error : UiState()
}

@Composable
fun StatefulScreen(uiState: UiState) {
    AnimatedContent(
        targetState = uiState,
        transitionSpec = {
            // New content fades in + slides up
            // while old content fades out + slides down
            (fadeIn(animationSpec = tween(300)) +
             slideInVertically { it / 2 })
                .togetherWith(
                    fadeOut(animationSpec = tween(200)) +
                    slideOutVertically { -it / 2 }
                )
        },
        label = "stateTransition"
    ) { state ->
        when (state) {
            is UiState.Loading -> LoadingSpinner()
            is UiState.Success -> SuccessContent(state.data)
            is UiState.Error  -> ErrorMessage()
        }
    }
}

Key insight: Inside AnimatedContent‘s lambda, the state parameter is the target state being transitioned to. Both the entering and exiting composables exist simultaneously during the transition — that’s how the cross-fade and slide works.

Animating a Counter

A really satisfying use of AnimatedContent is an animated number counter. The number slides up when increasing and slides down when decreasing:

Kotlin
@Composable
fun AnimatedCounter(count: Int) {
    AnimatedContent(
        targetState = count,
        transitionSpec = {
            if (targetState > initialState) {
                // Counting up: slide in from bottom, slide out to top
                slideInVertically { it } + fadeIn() togetherWith
                slideOutVertically { -it } + fadeOut()
            } else {
                // Counting down: slide in from top, slide out to bottom
                slideInVertically { -it } + fadeIn() togetherWith
                slideOutVertically { it } + fadeOut()
            }
        },
        label = "counter"
    ) { targetCount ->
        Text(
            text = "$targetCount",
            style = MaterialTheme.typography.displayMedium,
            fontWeight = FontWeight.Bold
        )
    }
}

Crossfade — The Simplest Content Switch

When you just need to fade between two pieces of content (no sliding, no scaling), Crossfade is the right tool. It’s essentially a simplified AnimatedContent with a hardcoded fade transition — perfect for tab content swaps.

Kotlin
@Composable
fun TabScreen() {
    var selectedTab by remember { mutableStateOf(0) }

    Column {
        TabRow(selectedTabIndex = selectedTab) {
            Tab(selected = selectedTab == 0, onClick = { selectedTab = 0 }) {
                Text("Home", modifier = Modifier.padding(16.dp))
            }
            Tab(selected = selectedTab == 1, onClick = { selectedTab = 1 }) {
                Text("Profile", modifier = Modifier.padding(16.dp))
            }
        }
        Crossfade(
            targetState = selectedTab,
            animationSpec = tween(durationMillis = 350),
            label = "tabContent"
        ) { tab ->
            when (tab) {
                0 -> HomeContent()
                1 -> ProfileContent()
            }
        }
    }
}

updateTransition — Coordinating Multiple Animations

When you have multiple animated values that all change together based on the same state, updateTransition is the right tool. It creates a single transition object that you can attach multiple animated properties to — all synchronized, all driven by the same state.

Think of it as a conductor for your animation orchestra.

Kotlin
enum class FabState { Collapsed, Expanded }

@Composable
fun AnimatedFAB() {
    var fabState by remember { mutableStateOf(FabState.Collapsed) }
    // One transition drives all the properties below
    val transition = updateTransition(
        targetState = fabState,
        label = "fabTransition"
    )
    val fabSize by transition.animateDp(
        label = "fabSize",
        transitionSpec = { spring(stiffness = Spring.StiffnessMediumLow) }
    ) { state ->
        if (state == FabState.Expanded) 180.dp else 56.dp
    }

    val cornerRadius by transition.animateDp(
        label = "cornerRadius"
    ) { state ->
        if (state == FabState.Expanded) 16.dp else 28.dp
    }

    val backgroundColor by transition.animateColor(
        label = "backgroundColor"
    ) { state ->
        if (state == FabState.Expanded)
            Color(0xFF4ADE80)
        else
            Color(0xFF6366F1)
    }

    val textAlpha by transition.animateFloat(
        label = "textAlpha",
        transitionSpec = { tween(durationMillis = 200) }
    ) { state ->
        if (state == FabState.Expanded) 1f else 0f
    }

    Surface(
        modifier = Modifier
            .width(fabSize)
            .height(56.dp)
            .clickable {
                fabState = if (fabState == FabState.Collapsed)
                    FabState.Expanded else FabState.Collapsed
            },
        shape = RoundedCornerShape(cornerRadius),
        color = backgroundColor,
        shadowElevation = 6.dp
    ) {
        Row(
            modifier = Modifier.padding(horizontal = 16.dp),
            verticalAlignment = Alignment.CenterVertically,
            horizontalArrangement = Arrangement.Center
        ) {
            Icon(Icons.Default.Add, contentDescription = "Add")
            Text(
                text = "  Create New",
                modifier = Modifier.alpha(textAlpha)
            )
        }
    }
}

Why updateTransition over multiple animate*AsState? Because all child animations share the same progress. They all start and finish together, which means your animations are inherently synchronized. With separate animate*AsState calls, timing can drift if the state changes rapidly.

InfiniteTransition — Looping Animations Forever

InfiniteTransition is for animations that run continuously — loading spinners, pulsing indicators, shimmer effects, breathing animations. Once started, they loop until the composable leaves the composition.

Kotlin
@Composable
fun PulsingDot() {
    val infiniteTransition = rememberInfiniteTransition(label = "pulse")

    val scale by infiniteTransition.animateFloat(
        initialValue = 0.85f,
        targetValue = 1.15f,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 700, easing = FastOutSlowInEasing),
            repeatMode = RepeatMode.Reverse   // ping-pong back and forth
        ),
        label = "dotScale"
    )

    val alpha by infiniteTransition.animateFloat(
        initialValue = 0.4f,
        targetValue = 1f,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 700),
            repeatMode = RepeatMode.Reverse
        ),
        label = "dotAlpha"
    )

    Box(
        modifier = Modifier
            .size(20.dp)
            .graphicsLayer {
                scaleX = scale
                scaleY = scale
                this.alpha = alpha
            }
            .background(Color(0xFF4ADE80), shape = CircleShape)
    )
}

Building a Shimmer Loading Effect

Shimmer placeholders are a staple of modern app design. Here’s how to build one from scratch using InfiniteTransition and a gradient — as a reusable Modifier extension:

Kotlin
@Composable
fun Modifier.shimmerEffect(): Modifier {
    val transition = rememberInfiniteTransition(label = "shimmer")

    val offset by transition.animateFloat(
        initialValue = -300f,
        targetValue = 1000f,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 1200, easing = LinearEasing)
        ),
        label = "shimmerOffset"
    )

    return background(
        brush = Brush.linearGradient(
            colors = listOf(
                Color(0xFF1E293B),
                Color(0xFF334155),
                Color(0xFF1E293B)
            ),
            start = Offset(offset, 0f),
            end = Offset(offset + 300f, 0f)
        )
    )
}

// Usage: apply to any placeholder composable
@Composable
fun ShimmerCard() {
    Column(modifier = Modifier.padding(16.dp)) {

        Box(modifier = Modifier
            .fillMaxWidth().height(160.dp).clip(RoundedCornerShape(12.dp))
            .shimmerEffect())

        Spacer(Modifier.height(12.dp))

        Box(modifier = Modifier
            .fillMaxWidth(0.7f).height(16.dp).clip(RoundedCornerShape(4.dp))
            .shimmerEffect())

        Spacer(Modifier.height(8.dp))

        Box(modifier = Modifier
            .fillMaxWidth(0.5f).height(16.dp).clip(RoundedCornerShape(4.dp))
            .shimmerEffect())
    }
}

Animatable — Full Manual Control

Animatable is the lowest-level animation primitive in Compose. It’s coroutine-based, which means you control exactly when animations start, stop, or get interrupted. Use it when the high-level APIs don’t give you enough control — for example, when you need animations triggered by gestures, sequenced one after another, or interrupted mid-flight.

Kotlin
@Composable
fun ShakeOnErrorField(hasError: Boolean) {
    // Animatable holds the current value and lets us animate it imperatively
    val offsetX = remember { Animatable(0f) }

    // LaunchedEffect runs in a coroutine - perfect for Animatable
    LaunchedEffect(hasError) {
        if (hasError) {
            // Sequence of animations: shake left, right, left, right, settle
            repeat(4) {
                offsetX.animateTo(
                    targetValue = if (it % 2 == 0) 10f else -10f,
                    animationSpec = tween(durationMillis = 50)
                )
            }
            offsetX.animateTo(0f) // settle back to centre
        }
    }

    TextField(
        value = "",
        onValueChange = {},
        isError = hasError,
        modifier = Modifier
            .offset(x = offsetX.value.dp)
            .fillMaxWidth()
    )
}

Animatable for Gesture-Driven Motion

One of Animatable‘s superpowers is handling interruptions gracefully. If a new gesture starts while an animation is running, you can snapTo the current gesture position without a jarring jump:

Kotlin
@Composable
fun DraggableCard() {
    val offsetX = remember { Animatable(0f) }
    val scope = rememberCoroutineScope()

    Card(
        modifier = Modifier
            .offset { IntOffset(offsetX.value.roundToInt(), 0) }
            .pointerInput(Unit) {
                detectHorizontalDragGestures(
                    onDragStart = {
                        // Stop any running animation when user grabs the card
                        scope.launch { offsetX.stop() }
                    },
                    onDragEnd = {
                        scope.launch {
                            // Spring back to centre when finger lifts
                            offsetX.animateTo(
                                targetValue = 0f,
                                animationSpec = spring(
                                    dampingRatio = Spring.DampingRatioMediumBouncy
                                )
                            )
                        }
                    },
                    onHorizontalDrag = { _, dragAmount ->
                        scope.launch {
                            offsetX.snapTo(offsetX.value + dragAmount)
                        }
                    }
                )
            }
    ) {
        Text("Drag me!", modifier = Modifier.padding(24.dp))
    }
}

Springs, Tweens & Easing Curves Explained

Every Jetpack Compose animation needs an animationSpec — it defines how the animation moves from A to B. There are several types, and picking the right one makes a huge difference in how your UI feels.

spring() — Physics-Based & Interruptible

Springs are the default for most interactive animations because they feel natural and handle interruptions gracefully. A spring has two key parameters:

dampingRatio — Controls bounciness. 

1f = no bounce (critically damped). 

0.5f = bouncy. 

Compose provides presets: Spring.DampingRatioNoBouncy, Spring.DampingRatioLowBouncy, Spring.DampingRatioMediumBouncy, Spring.DampingRatioHighBouncy.

stiffness — Controls speed. 

High stiffness = snappy and fast. 

Low stiffness = slow and floaty. 

Presets: Spring.StiffnessHigh, Spring.StiffnessMedium, Spring.StiffnessLow, Spring.StiffnessVeryLow.

Kotlin
// Snappy, no bounce — good for UI chrome (drawers, panels)
spring(
    dampingRatio = Spring.DampingRatioNoBouncy,
    stiffness = Spring.StiffnessMedium
)

// Playful bounce - good for FABs, chips, selection indicators
spring(
    dampingRatio = Spring.DampingRatioMediumBouncy,
    stiffness = Spring.StiffnessMedium
)

// Slow, floaty - good for hero transitions, large-format elements
spring(
    dampingRatio = Spring.DampingRatioLowBouncy,
    stiffness = Spring.StiffnessVeryLow
)

tween() — Duration-Based with Easing

Use tween when you need precise control over timing — particularly for coordinated multi-step animations where things need to arrive at specific moments.

Kotlin
// Standard eased animation — most general-purpose use
tween(durationMillis = 300, easing = FastOutSlowInEasing)

// Linear - good for progress bars, shimmer effects
tween(durationMillis = 1200, easing = LinearEasing)

// Delayed start - for staggered entrance animations
tween(durationMillis = 400, delayMillis = 150, easing = EaseOutBack)

// Custom cubic bezier easing curve
tween(
    durationMillis = 500,
    easing = CubicBezierEasing(0.25f, 0.1f, 0.25f, 1f)
)

keyframes() — Frame-Precise Control

keyframes lets you define exactly what value the animation should hit at specific points in time. It’s like an animator’s timeline — perfect when you need a bouncy overshoot or a stutter effect.

Kotlin
val size by animateDpAsState(
    targetValue = targetSize,
    animationSpec = keyframes {
        durationMillis = 600
        40.dp at 0            // start at 40dp
        80.dp at 100          // shoot up to 80dp at 100ms
        60.dp at 300          // bounce back to 60dp at 300ms
        70.dp at 500          // settle towards 70dp
    },
    label = "bounceSize"
)

Quick Reference Table

Gesture-Driven Animations

The best mobile animations respond directly to touch. Gesture-driven Jetpack Compose animations feel alive because they track the user’s finger position — they don’t just trigger on events, they continuously follow input.

Here’s a swipe-to-dismiss card commonly seen in notification screens and task managers:

Kotlin
@Composable
fun SwipeToDeleteCard(onDismiss: () -> Unit) {
    val offsetX = remember { Animatable(0f) }
    val scope = rememberCoroutineScope()
    val density = LocalDensity.current

    // Threshold: 40% of screen width triggers dismiss
    val screenWidth = with(density) { LocalConfiguration.current.screenWidthDp.dp.toPx() }
    val threshold = screenWidth * 0.4f

    // Derive alpha from position for a natural fade-out as you swipe
    val alpha = (1f - (abs(offsetX.value) / threshold)).coerceIn(0f, 1f)

    Box(
        modifier = Modifier
            .offset { IntOffset(offsetX.value.roundToInt(), 0) }
            .alpha(alpha)
            .pointerInput(Unit) {
                detectHorizontalDragGestures(
                    onDragEnd = {
                        scope.launch {
                            if (abs(offsetX.value) > threshold) {
                                // Fly off screen, then call onDismiss
                                offsetX.animateTo(
                                    targetValue = if (offsetX.value > 0) screenWidth else -screenWidth,
                                    animationSpec = tween(200)
                                )
                                onDismiss()
                            } else {
                                // Snap back if under threshold
                                offsetX.animateTo(0f, spring(Spring.DampingRatioMediumBouncy))
                            }
                        }
                    },
                    onHorizontalDrag = { _, dragAmount ->
                        scope.launch { offsetX.snapTo(offsetX.value + dragAmount) }
                    }
                )
            }
    ) {
        Card(modifier = Modifier.fillMaxWidth()) {
            Text("Swipe me to dismiss →", modifier = Modifier.padding(24.dp))
        }
    }
}

Shared Element Transitions (Compose 1.7+)

Shared element transitions are one of the most visually impressive patterns in mobile UI — a card expands into a detail screen, or an image flies from a list into a full-screen view. In the old View system, this was notoriously painful. In Compose 1.7+, it’s finally approachable.

Requires: androidx.compose.animation:animation:1.7.0+ and using SharedTransitionLayout with Navigation Compose or manual visibility management.

Kotlin
@Composable
fun SharedElementDemo() {
    var showDetail by remember { mutableStateOf(false) }

    SharedTransitionLayout {
        AnimatedContent(
            targetState = showDetail,
            label = "sharedElement"
        ) { isDetail ->
            if (!isDetail) {
                // List item card
                Card(
                    modifier = Modifier
                        .size(120.dp)
                        .clickable { showDetail = true },
                ) {
                    Image(
                        painter = painterResource(R.drawable.hero_image),
                        contentDescription = null,
                        modifier = Modifier
                            .sharedElement(
                                state = rememberSharedContentState(key = "hero_image"),
                                animatedVisibilityScope = this@AnimatedContent
                            )
                            .fillMaxSize(),
                        contentScale = ContentScale.Crop
                    )
                }
            } else {
                // Full-screen detail view
                Column(modifier = Modifier
                    .fillMaxSize()
                    .clickable { showDetail = false }
                ) {
                    Image(
                        painter = painterResource(R.drawable.hero_image),
                        contentDescription = null,
                        modifier = Modifier
                            .sharedElement(
                                state = rememberSharedContentState(key = "hero_image"),
                                animatedVisibilityScope = this@AnimatedContent
                            )
                            .fillMaxWidth()
                            .height(300.dp),
                        contentScale = ContentScale.Crop
                    )
                    Text("Detail content here", modifier = Modifier.padding(16.dp))
                }
            }
        }
    }
}

The key concept: Both composables reference the same key in rememberSharedContentState. Compose automatically detects this and morphs the element from its position/size in the source to its position/size in the destination. The element literally flies across the screen.

Performance Tips & Best Practices

Smooth animations are 60fps animations. Here’s how to make sure your Jetpack Compose animations never drop a frame.

Use graphicsLayer for Transform Animations

Always animate transforms (scale, rotation, alpha, translation) using graphicsLayer rather than layout modifiers. graphicsLayer runs on the RenderThread and doesn’t cause recomposition.

Kotlin
// Causes recomposition every frame — avoid for animated values
Modifier.scale(animatedScale)  // triggers layout pass

// Runs on RenderThread - no recomposition needed
Modifier.graphicsLayer {
    scaleX = animatedScale
    scaleY = animatedScale
}

Always Provide the label Parameter

The label parameter on every animation API might seem optional, but it makes the Animation Inspector in Android Studio actually usable. Always provide it — it takes two seconds and saves minutes of debugging.

Use animateItem() for LazyList Reordering (Compose 1.7+)

Kotlin
LazyColumn {
    items(items, key = { it.id }) { item ->
        ListItem(
            headlineContent = { Text(item.title) },
            modifier = Modifier.animateItem() // handles add/remove/reorder
        )
    }
}

Avoid Animating Layout Properties in Lists

Animating height or width inside a LazyColumn item forces a full list measurement pass each frame. Use graphicsLayer { scaleY = ... } as an approximation, or use AnimatedVisibility‘s built-in expandVertically/shrinkVertically which is optimised for this.

Respect Reduce Motion

Check LocalAccessibilityManager.current.isAnimationEnabled and respect the system’s “Reduce Motion” setting. Some users have vestibular disorders that make motion sickness a real issue.

Test on Real Devices

Emulators lie about performance. Always test animations on a mid-range physical device — if it’s smooth there, you’re good everywhere.

Real-World Animation Patterns You Can Steal

Bottom Sheet Peek Animation

Kotlin
@Composable
fun PeekBottomSheet(isExpanded: Boolean) {
    val sheetHeight by animateDpAsState(
        targetValue = if (isExpanded) 400.dp else 80.dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioNoBouncy,
            stiffness = Spring.StiffnessMediumLow
        ),
        label = "sheetHeight"
    )

    val handleAlpha by animateFloatAsState(
        targetValue = if (isExpanded) 0f else 1f,
        label = "handleAlpha"
    )

    Surface(
        modifier = Modifier
            .fillMaxWidth()
            .height(sheetHeight),
        shape = RoundedCornerShape(topStart = 20.dp, topEnd = 20.dp),
        shadowElevation = 8.dp
    ) {
        Column(horizontalAlignment = Alignment.CenterHorizontally) {
            Box(
                modifier = Modifier
                    .padding(top = 12.dp)
                    .size(width = 40.dp, height = 4.dp)
                    .background(Color.Gray.copy(alpha = handleAlpha), RoundedCornerShape(2.dp))
            )
        }
    }
}

Staggered List Entrance

A staggered entrance is when list items animate in one after another with a slight delay between each. It’s the difference between an “okay” app and a polished one:

Kotlin
@Composable
fun StaggeredItem(index: Int, content: @Composable () -> Unit) {
    var visible by remember { mutableStateOf(false) }

    LaunchedEffect(Unit) {
        // Each item starts its animation 60ms after the previous
        delay(index * 60L)
        visible = true
    }

    AnimatedVisibility(
        visible = visible,
        enter = fadeIn(animationSpec = tween(300)) +
                slideInVertically(
                    animationSpec = spring(Spring.DampingRatioLowBouncy),
                    initialOffsetY = { it / 2 }
                )
    ) {
        content()
    }
}

// Usage
@Composable
fun AnimatedFeed(items: List<FeedItem>) {
    LazyColumn {
        itemsIndexed(items) { index, item ->
            StaggeredItem(index = index) {
                FeedCard(item)
            }
        }
    }
}

Animated Progress Button

A button that transforms into a loading indicator on click — combining multiple animations under one updateTransition:

Kotlin
enum class ButtonState { Idle, Loading, Success }

@Composable
fun AnimatedProgressButton(
    state: ButtonState,
    onClick: () -> Unit
) {
    val transition = updateTransition(state, label = "btnTransition")
    val width by transition.animateDp(label = "btnWidth") {
        when (it) {
            ButtonState.Idle    -> 200.dp
            ButtonState.Loading -> 56.dp   // collapses to a circle
            ButtonState.Success -> 200.dp
        }
    }

    val color by transition.animateColor(label = "btnColor") {
        when (it) {
            ButtonState.Idle    -> Color(0xFF6366F1)  // indigo
            ButtonState.Loading -> Color(0xFF475569)  // grey
            ButtonState.Success -> Color(0xFF4ADE80)  // green
        }
    }

    Surface(
        modifier = Modifier
            .width(width)
            .height(56.dp)
            .clickable(enabled = state == ButtonState.Idle) { onClick() },
        shape = RoundedCornerShape(28.dp),
        color = color
    ) {
        Box(contentAlignment = Alignment.Center) {
            when (state) {
                ButtonState.Idle    -> Text("Submit", color = Color.White)
                ButtonState.Loading -> CircularProgressIndicator(
                    modifier = Modifier.size(24.dp),
                    color = Color.White, strokeWidth = 2.dp
                )
                ButtonState.Success -> Icon(Icons.Default.Check, null, tint = Color.White)
            }
        }
    }
}

Conclusion

From simple one-liner animate*AsState calls to choreographed multi-step transitions and gesture-driven physics — you now have the full picture of how Jetpack Compose animations work and when to use each API.

The biggest takeaway? Start at the highest API level that solves your problem, and only go deeper when you genuinely need more control. Most apps live happily in the AnimatedVisibility and animate*AsState layer, and that’s completely fine.

Now the best thing to do is open Android Studio and start experimenting. Animations are one of those things that click much faster in practice than in theory. Build something, ship it, and enjoy watching your users smile. 

Jetpack Animation Spring

Jetpack Animation Spring: The Secret to Natural UI Motion in Android

Good UI motion doesn’t call attention to itself. It just feels right.

If your animations feel stiff or robotic, chances are you’re using fixed-duration transitions. Real-world motion doesn’t work like that. Things accelerate, slow down, and sometimes bounce a little. That’s where Jetpack Animation Spring comes in.

Let’s walk through what it is, why it matters, and how to use it in compose projects without overcomplicating things.

Why UI Motion Matters More Than You Think

There’s a specific feeling you get from a well-made app — a card that snaps into place just right, or a button that bounces back a little when you tap it. It’s hard to pin down, but you know it when you feel it. That feeling almost always comes from physics-based animation.

Most of us start with tween animations: move from point A to point B in 300 milliseconds. Simple, predictable, and completely fine. But tweens move in straight lines. Nothing in the physical world actually does that.

That’s the gap Jetpack Animation Spring fills. It gives your UI a sense of mass and momentum — things overshoot slightly, then settle. It’s a small change that makes a noticeable difference.

Tween Animation

Moves from A to B in a fixed time. Feels robotic. Can’t react to mid-gesture interruptions naturally. Ignores real-world physics entirely.

Spring Animation

Moves based on force and resistance. Overshoots slightly, then settles. Can be interrupted mid-flight and still feels smooth. Mimics how real objects move.

Google’s Material Design guidelines call for spring-based animations on interactive elements because they respond more naturally to user input. It’s worth understanding how they work.

What Exactly Is Jetpack Animation Spring?

Jetpack Animation Spring is part of the Jetpack Compose animation APIs. It lets you drive animations with physics instead of timers — no manual easing curves, no hardcoded durations.

A spring animation behaves like a real spring. Pull one end and let go — it doesn’t stop dead at the resting point. It overshoots, oscillates back, and gradually settles. The exact behavior is controlled by two values:

  • How stiff the spring is (does it snap back quickly or slowly?)
  • How much damping there is (does it bounce a lot or settle immediately?)

In Compose, all of this is exposed through the spring() function. You pass a spring config to any animation call and Compose takes care of the rest.

Key insight: Unlike tween animations, spring animations are duration-independent. They don’t have a fixed end time — they run until the value reaches its target and the velocity drops to near zero. This makes them perfect for interruption-friendly interactions.

The Physics Behind Spring Animation

Under the hood, every spring in Compose is a damped harmonic oscillator. Which sounds more intimidating than it is. The model has two moving parts:

A spring pulls the object toward the target. A damper slows the object down. The interplay between these two forces creates the characteristic spring motion.

Damping Ratio — How Bouncy Is It?

The damping ratio controls how fast the oscillation dies out — think of it as friction:

Stiffness — How Fast Does It Get There?

Stiffness controls how aggressively the spring pulls the value toward the target. A high stiffness means fast, snappy motion. A low stiffness means a slow, gentle glide.

Setting Up Spring Animation in Jetpack Compose

Make sure you have the Compose animation dependency in your build.gradle.kts. If you’re using the Compose BOM you probably already have it, but here it is explicitly:

Kotlin
// In your app-level build.gradle.kts
dependencies {
    // Core Compose Animation
    implementation("androidx.compose.animation:animation:1.6.0")

    // Compose UI (already included with most BOM setups)
    implementation("androidx.compose.ui:ui:1.6.0")
}

Here’s a simple example — a box that slides horizontally when a button is clicked:

Kotlin
@Composable
fun SimpleSpringExample() {

    // Step 1: Track whether the box is in its "moved" state
    var moved by remember { mutableStateOf(false) }

    // Step 2: Create an animated float value
    val offsetX by animateFloatAsState(
        targetValue = if (moved) 200f else 0f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness    = Spring.StiffnessLow
        ),
        label = "boxOffset"
    )

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {

        // Step 3: Apply the offset to the Box
        Box(
            modifier = Modifier
                .size(80.dp)
                .offset(x = offsetX.dp)
                .background(
                    color = Color(0xFF5B8DEE),
                    shape = RoundedCornerShape(16.dp)
                )
        )

        Spacer(modifier = Modifier.height(32.dp))

        Button(onClick = { moved = !moved }) {
            Text(if (moved) "Spring Back!" else "Move with Spring!")
        }
    }
}

1. mutableStateOf(false) — This is a simple boolean that tells Compose whether the box should be at position 0 or position 200. When it changes, Compose re-composes and the animation kicks off automatically.

2. animateFloatAsState() — This is the magic function. It watches the targetValue and whenever it changes, it smoothly animates the float from its current value to the new target using the provided animationSpec.

3. spring(dampingRatio, stiffness) — This is the Jetpack Animation Spring config. Medium bouncy damping with low stiffness means the box moves slowly but overshoots its target before settling back.

4. offset(x = offsetX.dp) — We apply the animated value as the X offset of the Box. Every frame, Compose recalculates this value based on the spring physics and redraws the UI. No manual frame handling needed!

Understanding SpringSpec Parameters in Depth

The spring() function takes three parameters. Most people only use the first two, but the third one is worth knowing:

Kotlin
fun <T> spring(
    dampingRatio: Float = Spring.DampingRatioNoBouncy,
    stiffness:    Float = Spring.StiffnessMedium,
    visibilityThreshold: T? = null
): SpringSpec<T>

The visibilityThreshold Parameter

This one often gets overlooked! The visibilityThreshold tells Compose: “Stop animating when the value is this close to the target.” 

Means, it defines “when the animation is close enough to stop”

Because spring animations mathematically never fully stop (they asymptotically approach the target), Compose needs a cutoff.

Kotlin
// For a Dp value — stop when within 0.5dp of target
spring(
    dampingRatio = Spring.DampingRatioLowBouncy,
    stiffness    = Spring.StiffnessMedium,
    visibilityThreshold = 0.5.dp
)

// For a Float - stop when within 0.01f of target
spring<Float>(
    dampingRatio = Spring.DampingRatioNoBouncy,
    stiffness    = Spring.StiffnessMediumLow,
    visibilityThreshold = 0.01f
)

// For an Offset - stop when within 1px in both X and Y
spring(
    dampingRatio = Spring.DampingRatioMediumBouncy,
    stiffness    = Spring.StiffnessHigh,
    visibilityThreshold = Offset(1f, 1f)
)

Meaning per type:

  • Dp → 0.5.dp
     → Stop when difference < 0.5dp (visually indistinguishable)
  • Float → 0.01f
     → Stop when difference < 0.01
  • Offset → Offset(1f, 1f)
     → Stop when X and Y are within 1 pixel

It’s a performance optimization that prevents the animation from running indefinitely due to tiny floating-point movements.

Tip: For pixel-level animations, always set a sensible visibilityThreshold. Without it, your spring might technically run for dozens of extra frames on tiny sub-pixel oscillations — wasting battery for no visible benefit.

Built-in Spring Presets You Should Know

Compose ships a set of named constants in the Spring object. These are good defaults — you can always tweak from there, but they cover most use cases out of the box.

Damping Ratio Constants

1. NoBouncy

1.0f — Critically damped. Reaches target smoothly without overshooting. Great for practical, functional UI.

2. LowBouncy

0.75f — Slight overshoot. Very subtle and tasteful. Works for most interactive elements.

3. MediumBouncy

0.5f — Noticeable overshoot. Feels playful and lively. Perfect for FABs, pop-ups, and cards.

4. HighBouncy

0.2f — Very bouncy! Eye-catching but use sparingly. Great for celebrations or onboarding animations.

Stiffness Constants

Kotlin
// Compose's named stiffness constants:

Spring.StiffnessVeryLow    // ≈  50f  — very slow, dreamy
Spring.StiffnessLow        // ≈ 200f  — slow and smooth
Spring.StiffnessMediumLow  // ≈ 400f  — default-ish, general use
Spring.StiffnessMedium     // ≈ 500f  — standard interactive
Spring.StiffnessHigh       // ≈1500f  — snappy and sharp

Watch out: Combining a very high stiffness with a high bouncy damping ratio can make your UI feel chaotic. A high-stiffness spring that also bounces a lot will snap back and forth very quickly — which is rarely the intended effect. Aim for balance.

Real-World Use Cases with Code

Here are the three patterns I reach for most often in real projects.

Use Case 1: Bouncy FAB Appearance

A FAB that just fades in feels flat. Scale it in with a bouncy spring and it feels like it’s jumping out at you. Two lines to change:

Kotlin
@Composable
fun BouncyFAB() {

    var isVisible by remember { mutableStateOf(true) }

    // Animate scale from 0 to 1 with a high-bouncy spring
    val scale by animateFloatAsState(
        targetValue = if (isVisible) 1f else 0f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioHighBouncy,
            stiffness = Spring.StiffnessMedium
        ),
        label = "fabScale"
    )

    FloatingActionButton(
        onClick = { isVisible = !isVisible },
        modifier = Modifier.scale(scale)
    ) {
        Icon(
            imageVector = Icons.Default.Add,
            contentDescription = "Add"
        )
    }
}

@Preview(showBackground = true)
@Composable
fun BouncyFABPreview() {
    CenteredPreview {
        BouncyFAB()
    }
}

When isVisible flips to true, the scale springs from 0f to 1f. With HighBouncy damping, the FAB overshoots past 1.0 before bouncing back to its final size. Modifier.scale() applies the current value every frame — no extra work needed.

Use Case 2: Drag-and-Release with Spring Snap

Drag something sideways, release it, and it springs back to center. This is one of those interactions that feels obvious once you’ve seen it — and it’s straightforward to build:

Kotlin
@Composable
fun SpringSnapCard() {

    // Animatable gives us full control - we can "snap" or animate to values
    val offsetX = remember { Animatable(0f) }
    val scope = rememberCoroutineScope()

    Box(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        contentAlignment = Alignment.Center
    ) {
        Card(
            modifier = Modifier
                .size(width = 300.dp, height = 180.dp)
                .offset(x = offsetX.value.dp)
                .pointerInput(Unit) {
                    detectHorizontalDragGestures(

                        // While dragging: follow the finger directly
                        onHorizontalDrag = { _, dragAmount ->
                            scope.launch {
                                offsetX.snapTo(offsetX.value + dragAmount)
                            }
                        },

                        // On release: spring back to center!
                        onDragEnd = {
                            scope.launch {
                                offsetX.animateTo(
                                    targetValue = 0f,
                                    animationSpec = spring(
                                        dampingRatio = Spring.DampingRatioMediumBouncy,
                                        stiffness    = Spring.StiffnessMedium
                                    )
                                )
                            }
                        }
                    )
                }
        ) {
            Box(
                modifier = Modifier.fillMaxSize(),
                contentAlignment = Alignment.Center
            ) {
                Text(
                    text  = "Drag me sideways! <---->",
                    style = MaterialTheme.typography.bodyLarge
                )
            }
        }
    }
}

@Preview(showBackground = true)
@Composable
fun SpringSnapCardPreview() {
    CenteredPreview {
        SpringSnapCard()
    }
}

The key pattern: snapTo() during the drag (no animation, just follow the finger), then animateTo() with a spring on release. The spring picks up from whatever velocity the drag left behind, so fast flicks feel different from slow drags.

Use Case 3: Animated Color with Spring

Spring works on colors too. Here’s a button that animates both color and scale on press — layering two springs gives it a more tactile feel:

Kotlin
@Composable
fun SpringColorButton() {

    var isPressed by remember { mutableStateOf(false) }

    // Animate between two colors using spring
    val bgColor by animateColorAsState(
        targetValue = if (isPressed)
            Color(0xFF34D399)   // green when pressed
        else
            Color(0xFF5B8DEE),  // blue when idle
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioLowBouncy,
            stiffness    = Spring.StiffnessMedium
        ),
        label = "buttonColor"
    )

    val scale by animateFloatAsState(
        targetValue = if (isPressed) 0.94f else 1f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness    = Spring.StiffnessHigh
        ),
        label = "buttonScale"
    )

    Box(
        modifier = Modifier
            .scale(scale)
            .clip(RoundedCornerShape(14.dp))
            .background(bgColor)
            .pointerInput(Unit) {
                detectTapGestures(
                    onPress = {
                        isPressed = true
                        tryAwaitRelease()
                        isPressed = false
                    }
                )
            }
            .padding(horizontal = 32.dp, vertical = 16.dp),
        contentAlignment = Alignment.Center
    ) {
        Text(
            text  = "Press & Hold Me",
            color = Color.White,
            fontWeight = FontWeight.SemiBold
        )
    }
}

The scale spring uses high stiffness so it reacts instantly. The color spring uses medium stiffness so it transitions a little more slowly. That difference in timing is subtle, but it’s what stops the button from feeling like one flat animation.

Using Animatable with Spring for Full Control

For most UI state changes, animateFloatAsState() is all you need. But sometimes you want to trigger an animation imperatively — not in response to a state flip, but from a coroutine, a gesture callback, or a side effect. That’s what Animatable is for.

You hold a reference to it, then call animateTo(), snapTo(), or updateBounds() directly. Spring specs work the same way:

Kotlin
@Composable
fun AnimatableSpringExample() {

    // Create an Animatable — this is our "controllable" value
    val rotation = remember { Animatable(0f) }
    val scope = rememberCoroutineScope()

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Icon(
            imageVector = Icons.Default.Favorite,
            contentDescription = null,
            tint = Color.Red,
            modifier = Modifier
                .size(72.dp)
                .graphicsLayer {
                    rotationZ = rotation.value
                }
        )

        Spacer(Modifier.height(24.dp))

        Button(
            onClick = {
                scope.launch {
                    // Snap to 20° instantly (no animation) — simulate a "flick"
                    rotation.snapTo(20f)

                    // Then spring back to 0° with a bouncy spring
                    rotation.animateTo(
                        targetValue = 0f,
                        animationSpec = spring(
                            dampingRatio = Spring.DampingRatioHighBouncy,
                            stiffness    = Spring.StiffnessMediumLow
                        )
                    )
                }
            }
        ) {
            Text("Wobble the Heart! ❤️")
        }
    }
}

The snapTo() → animateTo() pattern is useful any time you want a “jolt” effect. Instantly displace the value, then spring it back. The icon appears to recoil from the tap rather than just changing state.

animateXAsState vs Animatable: If the animation is tied to a state variable, use animateXAsState(). If you need to fire it manually from a coroutine, gesture handler, or event callback, use Animatable.

Pro Tips & Common Mistakes

Do: Always Provide a Label

Since Compose 1.4, animated state APIs have a label parameter. Always fill it in. Android Studio’s Animation Inspector (also known as Animation Preview) uses these labels to identify animations during debugging — it makes your life significantly easier when inspecting overlapping animations.

Kotlin
// Good — label helps the Animation Inspector identify this
val scale by animateFloatAsState(
    targetValue = targetScale,
    animationSpec = spring(...),
    label = "cardScale"   // ← always add this!
)

// Bad — anonymous, hard to debug
val scale by animateFloatAsState(targetValue = targetScale)

Do: Use Spring for Gestures and Interruptions

If the user can reverse or redirect a motion mid-way — swipe back, lift a finger early, change direction — spring is the right tool. It reads the current velocity at the moment of interruption and continues from there. A tween would just reset and start over, which looks broken.

Don’t: Use Spring Where Duration Matters

Springs have no fixed end time. That’s a feature when you’re animating interactions, but a problem for things like progress bars or choreographed transitions where you need precise timing. Use tween() there.

Kotlin
// Use tween for progress bars (duration matters)
val progress by animateFloatAsState(
    targetValue    = loadingProgress,
    animationSpec  = tween(durationMillis = 2000, easing = LinearEasing),
    label = "loadingProgress"
)

// Use spring for interactive gestures (feel matters)
val cardOffset by animateFloatAsState(
    targetValue    = dragOffset,
    animationSpec  = spring(Spring.DampingRatioMediumBouncy),
    label = "cardDrag"
)

Don’t: Assume a Spring Will Finish in N Milliseconds

This one bites people. A developer adds a 300ms delay() after kicking off a spring animation, expecting it to be done. It’s not — a slow spring can run for 800ms or more. Use finishedListener to know when it actually settles.

Kotlin
// React to animation end correctly using finishedListener
val offsetX by animateFloatAsState(
    targetValue    = if (moved) 200f else 0f,
    animationSpec  = spring(Spring.DampingRatioLowBouncy),
    label          = "cardOffset",
    finishedListener = { finalValue ->
        // This fires when the spring fully settles
        Log.d("Spring", "Settled at: $finalValue")
        // Trigger your next action here, not after a hardcoded delay
    }
)

// Wrong — delay doesn't know when spring settles
scope.launch {
    moved = true
    delay(300)         // spring might still be running!
    doNextThing()
}

Frequently Asked Questions

Q. Can I use Jetpack Animation Spring with the old View-based Android system?

Yes. The SpringAnimation class in androidx.dynamicanimation brings the same physics model to View-based UIs. The API looks different from Compose’s spring(), but the underlying math is identical. For new projects, stick with the Compose API — it’s cleaner and integrates with state automatically.

Q. Is Jetpack Animation Spring bad for performance?

Not in practice. Compose batches and optimizes recompositions, so the overhead is minimal for typical UI. If you’re animating something heavy — large composables, complex layouts — wrap it in graphicsLayer. Transformations inside graphicsLayer (scale, rotation, translation, alpha) run on the RenderThread and skip recomposition entirely.

Q. Can I animate multiple properties with spring at the same time?

Yes — each animateXAsState() call is independent, so you can stack as many as you need in one composable. If multiple properties need to stay in sync (start at the same time, driven by the same state change), use updateTransition() instead. It groups them under a single transition so they move together.

Q. What is the difference between spring() and tween() in Compose?

Physics vs time. tween() moves from A to B over a fixed duration. spring() is duration-free — it runs until the value settles, driven by stiffness and damping. Use springs for anything the user can touch or interrupt. Use tweens where timing needs to be exact.

Conclusion

Jetpack Animation Spring is one of those tools that quietly improves your app. It doesn’t add features, but it makes everything feel better.

You don’t need complex setups. Just adjust damping and stiffness until it feels right.

Once you start using it in the right places, it’s hard to go back.

AnimatedContent

How to Master AnimatedContent in Jetpack Compose: Build Smooth UI Transitions

Good UI doesn’t just look nice, it moves well. Small, thoughtful animations help users understand what changed and why. In Jetpack Compose, AnimatedContent makes this surprisingly easy.

This guide walks you through how it works, when to use it, and how to keep things clean and performant.

What is AnimatedContent?

AnimatedContent is a composable in Jetpack Compose that automatically animates between different UI states.

Instead of abruptly switching content, it smoothly transitions from one state to another.

Think of it like this:

  • Without AnimatedContent → content just changes
  • With AnimatedContent → content transforms into the next state

When Should You Use AnimatedContent?

Use AnimatedContent when:

  • You switch between UI states (loading → success → error)
  • You update text, numbers, or layouts dynamically
  • You want smooth transitions without managing animations manually

Basic Example of AnimatedContent

Kotlin
@Composable
fun SimpleAnimatedContentExample(count: Int) {
    AnimatedContent(targetState = count) { targetCount ->
        Text(
            text = "Count: $targetCount",
            fontSize = 24.sp
        )
    }
}
  • targetState = count → tells Compose what state to watch
  • When count changes → animation is triggered
  • targetCount → the new value inside the animation block

This is the core idea of AnimatedContent.

Let’s build a simple counter with animation.

Kotlin
@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }

    Column(
        horizontalAlignment =
            Alignment.CenterHorizontally
    ) {
        AnimatedContent(targetState = count) { value ->
            Text(
                text = "$value",
                fontSize = 40.sp
            )
        }
        Spacer(modifier = Modifier.height(16.dp))

        Button(onClick = { count++ }) {
            Text("Increase")
        }
    }
}

@Preview(showBackground = true)
@Composable
fun CounterScreenPreview() {
    CenteredPreview {
        CounterScreen()
    }
}

Here,

Every time count changes:

  • Old text fades/slides out
  • New text animates in

No extra animation code needed.

Customizing Animation in AnimatedContent

By default, animations are nice but basic. You can customize them using transitionSpec.

Example with Slide + Fade

Kotlin
@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }

    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.spacedBy(12.dp),
        modifier = Modifier.padding(16.dp)
    ) {

        // Increment
        CounterButton(
            text = "+",
            onClick = { count++ }
        )

        // Animated Counter
        RollingCounter(count = count)

        // Decrement
        CounterButton(
            text = "-",
            onClick = { if (count > 0) count-- },
            enabled = count > 0
        )
    }
}

@Composable
fun CounterButton(
    text: String,
    onClick: () -> Unit,
    enabled: Boolean = true
) {
    Button(
        onClick = onClick,
        enabled = enabled,
        shape = CircleShape,
        modifier = Modifier.size(48.dp),
        contentPadding = PaddingValues(0.dp)
    ) {
        Text(
            text = text,
            fontSize = 22.sp
        )
    }
}

@Composable
fun RollingCounter(
    count: Int,
    fontSize: TextUnit = 40.sp
) {
    val digits = count.toString().map { it.toString() }

    Row {
        digits.forEachIndexed { index, digit ->
            key(index) {
                RollingDigit(
                    digit = digit,
                    fontSize = fontSize
                )
            }
        }
    }
}

@Composable
fun RollingDigit(
    digit: String,
    fontSize: TextUnit
) {
    Box(
        modifier = Modifier
            .height(48.dp)
            .width(28.dp),
        contentAlignment = Alignment.Center
    ) {
        AnimatedContent(
            targetState = digit,
            transitionSpec = {
                if (targetState > initialState) {
                    // Increment → roll up
                    slideInVertically { it } + fadeIn() togetherWith
                            slideOutVertically { -it } + fadeOut()
                } else {
                    // Decrement → roll down
                    slideInVertically { -it } + fadeIn() togetherWith
                            slideOutVertically { it } + fadeOut()
                }
            }
        ) { targetDigit ->
            Text(
                text = targetDigit,
                fontSize = fontSize,
                fontFamily = FontFamily.Monospace
            )
        }
    }
}

@Composable
fun CenteredPreview(content: @Composable () -> Unit) {
    Box(
        modifier = Modifier.fillMaxSize(),
        contentAlignment = Alignment.Center
    ) {
        content()
    }
}

@Preview(showBackground = true)
@Composable
fun CounterPreview() {
    CenteredPreview {
        CounterScreen()
    }
}
  • Digit-by-digit rolling animation
  • Direction-aware transitions (up/down)
  • Creates a smooth vertical transition

Understanding transitionSpec (Simple Explanation)

Inside transitionSpec, you define:

  • Enter animation → how new content appears
  • Exit animation → how old content disappears

You combine them using:

Kotlin
enterAnimation togetherWith exitAnimation

Add Direction-Based Animation

You can change animation depending on state.

Kotlin
AnimatedContent(
    targetState = count,
    transitionSpec = {
        if (targetState > initialState) {
            slideInHorizontally { it } togetherWith
            slideOutHorizontally { -it }
        } else {
            slideInHorizontally { -it } togetherWith
            slideOutHorizontally { it }
        }
    }
) { value ->
    Text(text = "$value", fontSize = 40.sp)
}

What’s happening?

  • Increasing number → slides from right
  • Decreasing number → slides from left

This small detail makes your UI feel intelligent.

Example 2: Switch Between Screens

You can use AnimatedContent to switch UI states like this:

Kotlin
enum class ScreenState {
    LOADING, SUCCESS, ERROR
}

@Composable
fun ScreenExample(state: ScreenState) {
    Box(
        modifier = Modifier
            .fillMaxWidth()
            .height(120.dp),
        contentAlignment = Alignment.Center
    ) {
        AnimatedContent(
            targetState = state,
            label = "screen_state",
            transitionSpec = {
                when {
                    // Loading → Success
                    initialState == ScreenState.LOADING &&
                            targetState == ScreenState.SUCCESS -> {
                        slideInVertically { it } + fadeIn() togetherWith
                                slideOutVertically { -it } + fadeOut()
                    }

                    // Loading → Error
                    initialState == ScreenState.LOADING &&
                            targetState == ScreenState.ERROR -> {
                        slideInVertically { -it } + fadeIn() togetherWith
                                slideOutVertically { it } + fadeOut()
                    }

                    // Error → Loading (retry)
                    initialState == ScreenState.ERROR &&
                            targetState == ScreenState.LOADING -> {
                        fadeIn() togetherWith fadeOut()
                    }

                    // Default
                    else -> {
                        fadeIn() togetherWith fadeOut()
                    }
                }
            }
        ) { targetState ->
            when (targetState) {

                ScreenState.LOADING -> {
                    CircularProgressIndicator()
                }

                ScreenState.SUCCESS -> {
                    Text(
                        text = "Data Loaded!",
                        fontSize = 20.sp
                    )
                }

                ScreenState.ERROR -> {
                    Column(
                        horizontalAlignment = Alignment.CenterHorizontally
                    ) {
                        Text(
                            text = "Something went wrong",
                            fontSize = 20.sp
                        )
                        Spacer(modifier = Modifier.height(8.dp))
                        Button(onClick = { /* retry action */ }) {
                            Text("Retry")
                        }
                    }
                }
            }
        }
    }
}

@Composable
fun ScreenContainer() {
    var state by remember { mutableStateOf(ScreenState.LOADING) }

    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.spacedBy(16.dp),
        modifier = Modifier.padding(16.dp)
    ) {

        ScreenExample(state = state)

        Row(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
            Button(onClick = { state = ScreenState.LOADING }) {
                Text("Loading")
            }
            Button(onClick = { state = ScreenState.SUCCESS }) {
                Text("Success")
            }
            Button(onClick = { state = ScreenState.ERROR }) {
                Text("Error")
            }
        }
    }
}

@Preview(showBackground = true)
@Composable
fun ScreenPreview() {
    CenteredPreview {
        ScreenContainer()
    }
}

Why this is powerful

Instead of hard switching screens:

  • Each state transition feels natural
  • Improves UX instantly

Common Mistakes to Avoid

1. Forgetting stable state

If your targetState changes too frequently or unpredictably, animations may feel glitchy.

Tip: Use proper state management (remember, ViewModel).

2. Overusing animations

Too many animations can overwhelm users.

Keep it simple:

  • Use animation where it adds clarity
  • Avoid unnecessary motion

3. Heavy UI inside AnimatedContent

If your composable is too complex, animation may lag.

Solution:

  • Keep UI lightweight
  • Break into smaller composables

Performance Tips for AnimatedContent

  • Prefer simple transitions (fade + slide)
  • Avoid recomposing large layouts
  • Use remember wisely
  • Test on low-end devices

Real-World Use Cases

You can use AnimatedContent for:

  • Cart updates in e-commerce apps
  • Switching tabs or filters
  • Form step transitions
  • Notifications or alerts
  • Dashboard value updates

Why AnimatedContent Improves UX

Good animation:

  • Guides attention
  • Explains change
  • Reduces confusion

AnimatedContent does this automatically, which saves time and improves quality.

Conclusion

Mastering AnimatedContent is less about memorizing APIs and more about understanding when and why to animate.

Start small:

  • Animate text
  • Animate numbers
  • Then move to full UI transitions

Over time, you’ll naturally build smoother, more polished apps.

animatedvisibility

How to Use AnimatedVisibility in Jetpack Compose for Stunning UI Transitions

Adding smooth motion to your Android app doesn’t just make it look “cool” — it guides the user’s eye and makes the interface feel responsive and alive. If you’ve ever felt overwhelmed by complex animation frameworks, I have great news: AnimatedVisibility in Jetpack Compose is here to do the heavy lifting for you.

In this guide, I’ll walk you through how to use AnimatedVisibility step by step. We’ll keep things simple, practical, and easy to follow. By the end, you’ll know how to create clean, engaging UI transitions without overcomplicating your code.

What is AnimatedVisibility?

AnimatedVisibility is a composable in Jetpack Compose that lets you show or hide UI elements with animation.

Instead of instantly appearing or disappearing, your UI components can:

  • Fade in or out
  • Slide in or out
  • Expand or shrink

This creates a smoother and more natural user experience.

Why Use AnimatedVisibility?

Here’s why developers love using AnimatedVisibility:

  • Makes UI feel modern and responsive
  • Improves user experience with smooth transitions
  • Easy to implement with minimal code
  • Highly customizable animations

If you’re building dropdowns, alerts, expandable cards, or onboarding flows, AnimatedVisibility is incredibly useful.

Basic Example of AnimatedVisibility

Let’s start with a simple example.

Step 1: Add a Toggle State

Kotlin
var isVisible by remember { mutableStateOf(false) }

This state controls whether the UI is visible or not.

Step 2: Use AnimatedVisibility

Kotlin
Column {
    Button(onClick = { isVisible = !isVisible }) {
        Text("Toggle Visibility")
    }

    AnimatedVisibility(visible = isVisible) {
        Text("Hello! I appear with animation.")
    }
}

Here,

  • When the button is clicked, isVisible changes
  • AnimatedVisibility reacts to that change
  • The text appears or disappears with a default animation

By default, it uses a combination of fade and expand animations.

Adding Custom Animations

The real power of AnimatedVisibility comes from customization.

You can define how elements enter and exit.

Example: Fade + Slide Animation

Kotlin
AnimatedVisibility(
    visible = isVisible,
    enter = fadeIn() + slideInVertically(),
    exit = fadeOut() + slideOutVertically()
) {
    Text("Smooth animated text!")
}
  • fadeIn() → gradually appears
  • slideInVertically() → slides from top or bottom
  • fadeOut() → fades away
  • slideOutVertically() → slides out

You can combine animations using the + operator.

Kotlin
@Composable
fun FadePlusSlideExample() {
    var isVisible by remember { mutableStateOf(false) }

    Column {
        Button(onClick = { isVisible = !isVisible }) {
            Text("Toggle Visibility")
        }

        AnimatedVisibility(
            visible = isVisible,
            enter = fadeIn() + slideInVertically(),
            exit = fadeOut() + slideOutVertically()
        ) {
            Text("Smooth animated text!")
        }
    }
}

@Preview(showBackground = true)
@Composable
fun FadePlusSlideExamplePreview() {
    CenteredPreview {
        FadePlusSlideExample()
    }
}

Controlling Animation Direction

You can customize how elements slide in.

Kotlin
slideInVertically { fullHeight -> -fullHeight }

What This Means,

  • The element enters from the top
  • -fullHeight moves it above the screen before sliding down

Similarly, you can control exit direction:

Kotlin
slideOutVertically { fullHeight -> fullHeight }

This makes it slide downward when disappearing.

Kotlin
@Composable
fun SlideDirectionExample() {
    var isVisible by remember { mutableStateOf(false) }

    Column {
        Button(onClick = { isVisible = !isVisible }) {
            Text("Toggle Visibility")
        }

        AnimatedVisibility(
            visible = isVisible,
            enter = fadeIn() + slideInVertically { fullHeight -> -fullHeight },
            exit = fadeOut() + slideOutVertically { fullHeight -> fullHeight }
        ) {
            Text("Slide Direction text!")
        }
    }
}

@Preview(showBackground = true)
@Composable
fun SlideDirectionExamplePreview() {
    CenteredPreview {
        SlideDirectionExample()
    }
}

Using AnimatedVisibility with Expand and Shrink

This is great for dropdowns or expandable content.

Kotlin
@Composable
fun ExpandShrinkExample() {
    var isExpandable by remember { mutableStateOf(false) }

    Column {
        Button(onClick = { isExpandable = !isExpandable }) {
            Text(if (isExpandable) "Shrink Content" else "Expand Content")
        }

        Spacer(modifier = Modifier.height(16.dp))

        AnimatedVisibility(
            visible = isExpandable,
            enter = expandVertically() + fadeIn(),
            exit = shrinkVertically() + fadeOut(),
        ) {
            Box(
                modifier = Modifier
                    .fillMaxWidth()
                    .background(Color.LightGray)
                    .padding(16.dp)
            ) {
                Text("Expandable content goes here")
            }
        }
    }
}

@Preview(showBackground = true)
@Composable
fun ExpandShrinkExamplePreview() {
    CenteredPreview {
        ExpandShrinkExample()
    }
}

Why Use This?

  • Feels natural for lists and cards
  • Mimics real-world expansion behavior
  • Works great for FAQs or settings screens

Real-World Use Case

Let’s combine everything into a practical example.

Expandable Card

Kotlin
@Composable
fun ExpandableCard() {
    var expanded by remember { mutableStateOf(false) }

    Column(modifier = Modifier.padding(16.dp)) {
        Button(onClick = { expanded = !expanded }) {
            Text("Show Details")
        }

        AnimatedVisibility(
            visible = expanded,
            enter = fadeIn() + expandVertically(),
            exit = fadeOut() + shrinkVertically()
        ) {
            Text(
                text = "Here are more details about this item. This section expands smoothly.",
                modifier = Modifier.padding(top = 8.dp)
            )
        }
    }
}

@Preview(showBackground = true)
@Composable
fun ExpandableCardPreview() {
    CenteredPreview {
        ExpandableCard()
    }
}
  • Clean separation of state and UI
  • Smooth transition enhances usability
  • Easy to reuse in different parts of your app

AnimatedVisibility with LazyColumn

Using AnimatedVisibility inside a LazyColumn is a great way to create smooth, modern list interactions. Think expandable list items, animated insert/remove, or showing extra details per row.

You’d typically combine AnimatedVisibility with LazyColumn when:

  • Expanding/collapsing list items
  • Showing extra details on click
  • Animating conditional content inside rows

Here’s a simple example where each item expands when clicked.

Data Model

Kotlin
data class ListItem(
    val id: Int,
    val title: String,
    val description: String
)

Sample Data

Kotlin
val items = listOf(
    ListItem(1, "Item 1", "This is item 1 details"),
    ListItem(2, "Item 2", "This is item 2 details"),
    ListItem(3, "Item 3", "This is item 3 details")
)

LazyColumn with AnimatedVisibility

Kotlin
@Composable
fun ExpandableList() {
    val expandedItems = remember { mutableStateListOf<Int>() }

    LazyColumn {
        items(items) { item ->

            val isExpanded = expandedItems.contains(item.id)

            Column(
                modifier = Modifier
                    .fillMaxWidth()
                    .clickable {
                        if (isExpanded) {
                            expandedItems.remove(item.id)
                        } else {
                            expandedItems.add(item.id)
                        }
                    }
                    .padding(16.dp)
            ) {

                Text(text = item.title)

                AnimatedVisibility(
                    visible = isExpanded,
                    enter = fadeIn() + expandVertically(),
                    exit = fadeOut() + shrinkVertically()
                ) {
                    Text(
                        text = item.description,
                        modifier = Modifier.padding(top = 8.dp)
                    )
                }
            }
        }
    }
}

@Preview(showBackground = true)
@Composable
fun ExpandableListPreview() {
    CenteredPreview {
        ExpandableList()
    }
}

Best Practices for Using AnimatedVisibility

To get the most out of AnimatedVisibility, keep these tips in mind:

1. Keep Animations Subtle

Avoid overly complex animations. Simple transitions feel more professional.

2. Use Meaningful Motion

Animations should guide the user, not distract them.

3. Manage State Properly

Use remember and mutableStateOf correctly to avoid unexpected behavior.

4. Combine Animations Carefully

Too many combined effects can feel heavy. Stick to 1–2 transitions.

5. Test on Real Devices

Animations may feel different on slower devices. Always test performance.

Common Mistakes to Avoid

Here are a few pitfalls when working with AnimatedVisibility:

  • Forgetting to control state properly
  • Overusing animations in every component
  • Using heavy animations inside large lists
  • Not handling re-composition efficiently

Keep things simple and intentional.

When Should You Use AnimatedVisibility?

Use AnimatedVisibility when you need to:

  • Show/hide UI elements dynamically
  • Create expandable layouts
  • Improve onboarding screens
  • Add feedback to user actions
  • Build interactive components

If visibility changes are part of your UI, this composable is the right tool.

Conclusion

AnimatedVisibility is one of the easiest ways to bring life into your Jetpack Compose UI.

You don’t need complex animation frameworks or tons of code. With just a few lines, you can create smooth, engaging transitions that feel natural and polished.

Start small. Try a simple fade or slide. Then experiment with combinations as you get comfortable.

visibilityThreshold

visibilityThreshold in Spring Animations: How It Works in Jetpack Compose

When you start working with animations in Jetpack Compose, the spring() API feels intuitive at first—until you notice something odd: animations don’t seem to fully stop. They get very, very close to the target value… but technically never reach it.

That’s where visibilityThreshold quietly does some of the most important work.

This article walks you through what it is, why it matters, and how to use it correctly across different data types like Dp, Float, and Offset. Along the way, we’ll build real composable examples you can run and experiment with.

Why Spring Animations Need a Stopping Condition

Spring animations simulate real physics, Instead of moving linearly from point A to point B, they behave like a spring:

  • They move toward the target
  • Overshoot (depending on damping)
  • Oscillate
  • Gradually settle

From a math perspective, they never fully stop — they just get closer over time.

In UI, that’s not useful. We need a clear stopping point. Compose handles this using a threshold.

What is visibilityThreshold?

visibilityThreshold defines the minimum difference between the current animated value and the target value at which the animation is considered finished.

In simple terms:

  • If the remaining distance is smaller than the threshold → animation stops
  • If not → animation continues

How It Works for Different Types

Different types need different thresholds because “closeness” depends on the unit.

1. Dp (Density-independent pixels)

Kotlin
spring(
    dampingRatio = Spring.DampingRatioLowBouncy,
    stiffness = Spring.StiffnessMedium,
    visibilityThreshold = 0.5.dp
)

The animation stops when it’s within 0.5dp of the target.

Why this works:

  • Human eyes can’t distinguish sub-pixel differences at that scale
  • Prevents unnecessary micro-adjustments

2. Float (e.g., Alpha, Progress)

Kotlin
spring<Float>(
    dampingRatio = Spring.DampingRatioNoBouncy,
    stiffness = Spring.StiffnessMediumLow,
    visibilityThreshold = 0.01f
)

Stops when difference < 0.01

Why this matters:

  • Floats are continuous values
  • Without a threshold, fade animations might keep updating unnecessarily

3. Offset (Position)

Kotlin
spring(
    dampingRatio = Spring.DampingRatioMediumBouncy,
    stiffness = Spring.StiffnessHigh,
    visibilityThreshold = Offset(1f, 1f)
)

Stops when both X and Y are within 1 pixel

Why:

  • Movement smaller than 1px is visually irrelevant
  • Prevents jitter at the end of motion

Quick Refresher on Spring Parameters

Real Examples with Composables

Example 1: Animating Size (Dp)

Kotlin
@Composable
fun SpringDpExample() {
    var expanded by remember { mutableStateOf(false) }

    val size by animateDpAsState(
        targetValue = if (expanded) 200.dp else 100.dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioLowBouncy,
            stiffness = Spring.StiffnessMedium,
            visibilityThreshold = 0.5.dp
        )
    )

    Box(
        modifier = Modifier
            .size(size)
            .background(Color.Blue)
            .clickable { expanded = !expanded }
    )
}

@Preview(showBackground = true)
@Composable
fun SpringDpExamplePreview() {
    CenteredPreview {
        SpringDpExample()
    }
}

What to notice:

  • Smooth expansion and contraction
  • A slight bounce effect
  • Clean stop without jitter

Example 2: Animating Alpha (Float)

Kotlin
@Composable
fun SpringFloatExample() {
    var visible by remember { mutableStateOf(true) }

    val alpha by animateFloatAsState(
        targetValue = if (visible) 1f else 0f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioNoBouncy,
            stiffness = Spring.StiffnessMediumLow,
            visibilityThreshold = 0.01f
        )
    )

    Box(
        modifier = Modifier
            .size(150.dp)
            .background(Color.Red.copy(alpha = alpha))
            .clickable { visible = !visible }
    )
}

@Preview(showBackground = true)
@Composable
fun SpringFloatExamplePreview() {
    CenteredPreview {
        SpringFloatExample()
    }
}

Observation:

  • Clean fade without bounce
  • No flickering at the end
  • Efficient termination

Example 3: Animating Position (Offset)

Kotlin
@Composable
fun SpringOffsetExample() {
    var moved by remember { mutableStateOf(false) }

    val offset by animateOffsetAsState(
        targetValue = if (moved) Offset(300f, 300f) else Offset.Zero,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness = Spring.StiffnessHigh,
            visibilityThreshold = Offset(1f, 1f)
        )
    )

    Box(
        modifier = Modifier
            .offset { IntOffset(offset.x.toInt(), offset.y.toInt()) }
            .size(80.dp)
            .background(Color.Green)
            .clickable { moved = !moved }
    )
}

@Preview(showBackground = true)
@Composable
fun SpringOffsetExamplePreview() {
    CenteredPreview {
        SpringOffsetExample()
    }
}

What to watch:

  • Movement feels natural
  • Slight bounce at destination
  • Stops cleanly without micro-shakes

Why visibilityThreshold is Important 

1. Performance Optimization

Without it:

  • The animation engine keeps recalculating tiny differences
  • Wastes CPU cycles
  • Impacts battery (especially on low-end devices)

With it:

  • Animation ends decisively
  • Reduces recompositions

2. Visual Stability

Tiny sub-pixel movements can cause:

  • Flickering
  • Jitter
  • Unstable UI feel

Threshold eliminates those artifacts.

3. Better UX

Users don’t perceive microscopic differences.

Ending animations early:

  • Feels faster
  • Feels smoother
  • Improves perceived performance

Choosing the Right Threshold

Here’s a practical guideline:

Avoid:

  • Too small → wasted computation
  • Too large → noticeable snapping

Common Mistakes

Ignoring it completely
→ Animations run longer than needed

Using the same value everywhere
→ Different types need different precision

Setting it too high
→ Animation ends too early and looks abrupt

Conclusion

visibilityThreshold is easy to overlook, but it has a noticeable impact on how polished your animations feel.

A small tweak here can:

  • Reduce unnecessary work
  • Improve smoothness
  • Make animations feel more intentional

It’s one of those details that separates a working UI from a well-crafted one.

animateAsState

Master animate*AsState in Jetpack Compose: Effortless UI Animations Explained

Animations in the old View system were a lot of ceremony. You’d set up an ObjectAnimator, attach a listener, call start(), remember to cancel on detach, and hope nothing leaked. For something as simple as fading a view, it felt disproportionate.

Compose takes a different approach. Instead of imperative animation commands, you describe what you want the UI to look like for a given state — and the animate*AsState family handles the transition automatically. No start/cancel lifecycle. No listeners unless you need them.

What Is animate*AsState?

animate*AsState is a group of composable functions that smoothly animate a value whenever its target changes. Feed it a target, and it produces a frame-by-frame animated value you can plug directly into your UI.

The * is a wildcard — there’s a variant for each value type you’re likely to animate:

They all follow the same pattern, so once you’ve used one, the others are trivial.

The Mental Model

The key shift from the View system: you don’t start animations. You change state.

State changes → animate*AsState detects the new target → interpolates toward it each frame

When isExpanded flips from false to true, you don’t tell anything to animate. You just update state, and the animated value catches up on its own. If the state changes again mid-flight, the animation redirects smoothly from wherever it currently is.

This is different from ValueAnimator, which needs explicit start/cancel calls and doesn’t know about your UI state at all.

animateFloatAsState: Fading a Box

Start here — it’s the simplest case.

Kotlin
@Composable
fun FadeExample() {
    var isVisible by remember { mutableStateOf(true) }

    val alpha by animateFloatAsState(
        targetValue = if (isVisible) 1f else 0f,
        label = "alpha animation"
    )

    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        modifier = Modifier.padding(24.dp)
    ) {
        Box(
            modifier = Modifier
                .size(100.dp)
                .graphicsLayer { this.alpha = alpha }
                .background(Color(0xFF6650A4))
        )
        Spacer(modifier = Modifier.height(16.dp))
        Button(onClick = { isVisible = !isVisible }) {
            Text(if (isVisible) "Hide" else "Show")
        }
    }
}


@Preview(showBackground = true)
@Composable
fun FadeExamplePreview() {
    FadeExample()
}

isVisible is boolean. When it toggles, animateFloatAsState picks up the new target and eases alpha toward it over several frames. Each frame triggers a recomposition, which re-reads the updated alpha — that’s the full animation loop.

The label parameter is optional, but set it anyway. It appears in the Android Studio Animation Inspector and makes debugging significantly less painful.

animateColorAsState: Transitioning Colors

Color is one of the more visually rewarding things to animate because even a 300ms cross-fade reads as deliberate and polished.

Kotlin
@Composable
fun ColorToggleExample() {
    var isActive by remember { mutableStateOf(false) }

    val backgroundColor by animateColorAsState(
        targetValue = if (isActive) Color(0xFF6650A4) else Color(0xFFECECEC),
        animationSpec = tween(durationMillis = 500),
        label = "background color"
    )

    val textColor by animateColorAsState(
        targetValue = if (isActive) Color.White else Color.Black,
        animationSpec = tween(durationMillis = 500),
        label = "text color"
    )

    Box(
        contentAlignment = Alignment.Center,
        modifier = Modifier
            .fillMaxWidth()
            .height(120.dp)
            .background(backgroundColor, shape = RoundedCornerShape(16.dp))
            .clickable { isActive = !isActive }
    ) {
        Text(
            text = if (isActive) "Active" else "Inactive",
            color = textColor,
            fontSize = 20.sp,
            fontWeight = FontWeight.SemiBold
        )
    }
}


@Preview(showBackground = true)
@Composable
fun ColorToggleExamplePreview() {
    CenteredPreview {
        ColorToggleExample()
    }
}

Both the background and text colors animate in sync. You don’t coordinate them — they just share the same state source (isActive), so they naturally stay in step.

The animationSpec = tween(durationMillis = 500) is where you control how the animation plays out. More on that below.

animateDpAsState: Expandable Cards

animateDpAsState works on any Dp value — height, width, padding, corner radius. A common use case is an expandable card:

Kotlin
@Composable
fun ExpandableCardExample() {
    var isExpanded by remember { mutableStateOf(false) }

    val cardHeight by animateDpAsState(
        targetValue = if (isExpanded) 200.dp else 80.dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness = Spring.StiffnessLow
        ),
        label = "card height"
    )
    
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .height(cardHeight)
            .clickable { isExpanded = !isExpanded },
        elevation = CardDefaults.cardElevation(defaultElevation = 4.dp)
    ) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(
                text = "Tap to ${if (isExpanded) "collapse" else "expand"}",
                fontWeight = FontWeight.Bold,
                fontSize = 16.sp
            )
            if (isExpanded) {
                Spacer(modifier = Modifier.height(12.dp))
                Text(
                    text = "The card height is driven by animateDpAsState. " +
                           "The spring spec adds a slight overshoot on open.",
                    fontSize = 14.sp,
                    color = Color.Gray
                )
            }
        }
    }
}

Using spring instead of tween here adds a small overshoot when the card opens — the physics-based easing makes it feel more physical than a plain duration curve.

Animation Specs

animationSpec controls the character of the animation. There are three you’ll reach for regularly.

tween — Fixed Duration

Kotlin
val size by animateDpAsState(
    targetValue = targetSize,
    animationSpec = tween(
        durationMillis = 400,
        delayMillis = 100,
        easing = FastOutSlowInEasing
    ),
    label = "size"
)

Pick tween when you need precise timing — UI tests, coordinated sequences, or matching a transition to an audio cue.

Common easing options:

  • FastOutSlowInEasing — decelerates into the final position (good for elements entering the screen)
  • LinearOutSlowInEasing — starts at constant speed, slows at the end (good for exits)
  • FastOutLinearInEasing — accelerates throughout (for emphasis)
  • EaseInOut — smooth on both ends, feels the most natural
  • LinearEasing — constant speed; fine for loaders, rarely right for UI transitions

spring — Physics-Based

Kotlin
val offsetX by animateFloatAsState(
    targetValue = targetPosition,
    animationSpec = spring(
        dampingRatio = Spring.DampingRatioMediumBouncy,  // How much it overshoots
        stiffness = Spring.StiffnessLow                  // How fast it moves
    ),
    label = "offset"
)

spring doesn’t have a fixed duration — it settles based on physics. The two parameters to tune:

Damping ratio (controls overshoot):

  • NoBouncy (1f) — glides in cleanly, no overshoot
  • LowBouncy (0.75f) — barely noticeable bounce
  • MediumBouncy (0.5f) — clear bounce, works well for cards and buttons
  • HighBouncy (0.2f) — exaggerated overshoot, use it deliberately

Stiffness (controls speed):

  • VeryLow — slow, floaty
  • Low — relaxed
  • Medium — balanced default
  • High — snappy
  • VeryHigh — nearly instant

keyframes — Custom Intermediate Values

Kotlin
val scale by animateFloatAsState(
    targetValue = if (isPressed) 0.9f else 1f,
    animationSpec = keyframes {
        durationMillis = 300
        1f at 0       // frame 0ms
        1.1f at 100   // slightly overshoots at 100ms
        0.95f at 200  // settles low
        1f at 300     // lands at resting scale
    },
    label = "press scale"
)

Use keyframes for custom press effects or anything where you need control over intermediate values. It’s more verbose, but it gives you exact control over the curve at each timestamp.

Combining Multiple Animations: Like Button

Each animate*AsState call handles exactly one value. When you need several properties to animate at once, you just stack them. They all read from the same state and run concurrently without any coordination code.

Kotlin
@Composable
fun AnimatedLikeButton() {
    var isLiked by remember { mutableStateOf(false) }

    val scale by animateFloatAsState(
        targetValue = if (isLiked) 1f else 0.85f,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioHighBouncy,
            stiffness = Spring.StiffnessMedium
        ),
        label = "like scale"
    )

    val heartColor by animateColorAsState(
        targetValue = if (isLiked) Color(0xFFE91E63) else Color.Gray,
        animationSpec = tween(durationMillis = 200),
        label = "heart color"
    )

    val iconSize by animateDpAsState(
        targetValue = if (isLiked) 36.dp else 28.dp,
        animationSpec = spring(dampingRatio = Spring.DampingRatioMediumBouncy),
        label = "icon size"
    )

    IconButton(
        onClick = { isLiked = !isLiked },
        modifier = Modifier.graphicsLayer { scaleX = scale; scaleY = scale }
    ) {
        Icon(
            imageVector = if (isLiked) Icons.Filled.Favorite else Icons.Outlined.FavoriteBorder,
            contentDescription = if (isLiked) "Unlike" else "Like",
            tint = heartColor,
            modifier = Modifier.size(iconSize)
        )
    }
}

On tap:

  1. The icon swaps (state change, instant)
  2. Color fades from gray to pink over 200ms (tween)
  3. Scale bounces with a spring (HighBouncy)
  4. Icon size bumps up with a softer spring (MediumBouncy)

Three independent animations, one state variable, no coordinator.

Rotation

The .rotate() modifier accepts a Float, so animateFloatAsState drops right in. Useful for expand/collapse arrows and spinners.

Kotlin
@Composable
fun RotatingArrow() {
    var isExpanded by remember { mutableStateOf(false) }

    val rotation by animateFloatAsState(
        targetValue = if (isExpanded) 180f else 0f,
        animationSpec = tween(durationMillis = 300, easing = EaseInOut),
        label = "arrow rotation"
    )

    Row(
        modifier = Modifier
            .fillMaxWidth()
            .clickable { isExpanded = !isExpanded }
            .padding(16.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically
    ) {
        Text("Show details", fontWeight = FontWeight.Medium)
        Icon(
            imageVector = Icons.Default.KeyboardArrowDown,
            contentDescription = "Expand",
            modifier = Modifier.rotate(rotation)
        )
    }
}

Slide-In with Offset

Banner notifications, bottom bars, toast-style messages — offset animation handles all of these. Start the composable off-screen and animate it into position.

Kotlin
@Composable
fun SlideInNotification(
    message: String,
    isVisible: Boolean
) {
    val offsetY by animateDpAsState(
        targetValue = if (isVisible) 0.dp else (-80).dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioLowBouncy,
            stiffness = Spring.StiffnessMedium
        ),
        label = "notification offset"
    )

    Surface(
        modifier = Modifier
            .fillMaxWidth()
            .offset(y = offsetY),
        color = Color(0xFF4CAF50),
        shadowElevation = 6.dp,
        shape = RoundedCornerShape(bottomStart = 12.dp, bottomEnd = 12.dp)
    ) {
        Text(
            text = message,
            modifier = Modifier.padding(16.dp),
            color = Color.White,
            fontWeight = FontWeight.Medium
        )
    }
}

@Preview(showBackground = true)
@Composable
fun SlideInNotificationInteractivePreview() {
    CenteredPreview {
        var isVisible by remember { mutableStateOf(false) }

        Column(horizontalAlignment = Alignment.CenterHorizontally) {
            SlideInNotification(
                message = "This is a notification. Hello from animation",
                isVisible = isVisible
            )

            Spacer(modifier = Modifier.height(16.dp))

            Button(onClick = { isVisible = !isVisible }) {
                Text("Toggle")
            }
        }
    }
}

When isVisible becomes true, the banner animates from its current offset to 0.dp, sliding down into view with a slight bounce. When set to false, it animates back to -80.dp, sliding out upward.

Reacting When an Animation Finishes

If you need to trigger something after the animation settles — navigate, update a flag, kick off the next step — use finishedListener:

Kotlin
@Composable
fun AnimationWithCallback() {
    var isMoved by remember { mutableStateOf(false) }
    var statusText by remember { mutableStateOf("Ready") }

    val offsetX by animateDpAsState(
        targetValue = if (isMoved) 200.dp else 0.dp,
        animationSpec = tween(durationMillis = 600),
        label = "move animation",
        finishedListener = { finalValue ->
            // Called once - when the animation fully settles
            statusText = if (finalValue == 200.dp) "Moved!" else "Back home!"
        }
    )

    Column(horizontalAlignment = Alignment.CenterHorizontally) {
        Box(
            modifier = Modifier
                .size(60.dp)
                .offset(x = offsetX)
                .background(Color(0xFF6650A4), shape = CircleShape)
        )
        Spacer(modifier = Modifier.height(16.dp))
        Text(text = statusText)
        Spacer(modifier = Modifier.height(8.dp))
        Button(onClick = { isMoved = !isMoved }) {
            Text(if (isMoved) "Move back" else "Move right")
        }
    }
}

finishedListener fires once, with the final settled value. It does not fire on every frame — that’s what makes it safe to use for side effects.

Performance: Use graphicsLayer for Visual Transforms

For scale, alpha, and rotation, avoid stacking individual modifiers. Batch them in a single graphicsLayer block:

Kotlin
// Prefer this — all transforms applied in one pass on the render thread
Modifier.graphicsLayer {
    scaleX = scale
    scaleY = scale
    alpha = alpha
    rotationZ = rotation
}

// Avoid this for pure visual properties
Modifier
    .scale(scale)
    .alpha(alpha)
    .rotate(rotation)

graphicsLayer applies visual transformations during the draw phase, avoiding layout changes and reducing the cost of recomposition for purely visual updates. This makes it especially efficient for animations like alpha, translation, and scale—particularly in lists or frequently updated UI.

Keep targetValue Simple

If the logic for computing your target value is complex, extract it before passing it in:

Kotlin
// Fine
val scale by animateFloatAsState(
    targetValue = if (isExpanded) 1.2f else 1f,
    label = "scale"
)

// Better to extract first than inline a big when block
val targetScale = when {
    isExpanded && isSelected -> 1.3f
    isExpanded -> 1.15f
    isSelected -> 1.05f
    else -> 1f
}

val scale by animateFloatAsState(targetValue = targetScale, label = "scale")

When Not to Use animate*AsState

animate*AsState is the right tool when you’re animating a single value in response to a state flip. Reach for something else when:

  • You’re animating multiple values that need to stay in sync as a unit → updateTransition
  • You need an infinitely repeating animation → rememberInfiniteTransition
  • You’re tracking a pointer/drag gesture and need manual control → Animatable
  • The composable is entering or leaving the composition → AnimatedVisibility

The last one trips people up most often. animate*AsState can only animate a composable that’s already in the tree. If you’re using if (condition) { MyComposable() } and condition becomes false, MyComposable is gone — there’s nothing left to animate. Wrap it in AnimatedVisibility instead.

Full Example: Custom Animated Toggle

Here’s everything from this article working together in a single component — a toggle row with animated track color, thumb position, and a subtle press scale:

Kotlin
@Composable
fun AnimatedSettingsToggle(
    label: String,
    description: String,
    isEnabled: Boolean,
    onToggle: (Boolean) -> Unit
) {
    var isPressed by remember { mutableStateOf(false) }

    val trackColor by animateColorAsState(
        targetValue = if (isEnabled) Color(0xFF6650A4) else Color(0xFFCAC4D0),
        animationSpec = tween(durationMillis = 250),
        label = "track color"
    )

    val thumbOffset by animateDpAsState(
        targetValue = if (isEnabled) 20.dp else 2.dp,
        animationSpec = spring(
            dampingRatio = Spring.DampingRatioMediumBouncy,
            stiffness = Spring.StiffnessMedium
        ),
        label = "thumb offset"
    )

    val rowScale by animateFloatAsState(
        targetValue = if (isPressed) 0.98f else 1f,
        animationSpec = tween(durationMillis = 100),
        label = "row press scale"
    )

    Row(
        modifier = Modifier
            .fillMaxWidth()
            .graphicsLayer {
                scaleX = rowScale
                scaleY = rowScale
            }
            .clickable(
                indication = null,
                interactionSource = remember { MutableInteractionSource() }
            ) {
                isPressed = true
                onToggle(!isEnabled) // toggle value
                isPressed = false
            }
            .padding(horizontal = 16.dp, vertical = 12.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically
    ) {
        Column(modifier = Modifier.weight(1f)) {
            Text(
                text = label,
                fontWeight = FontWeight.SemiBold,
                fontSize = 16.sp
            )
            Text(
                text = description,
                fontSize = 13.sp,
                color = Color.Gray
            )
        }

        Spacer(modifier = Modifier.width(16.dp))

        Box(
            modifier = Modifier
                .width(48.dp)
                .height(28.dp)
                .background(trackColor, shape = RoundedCornerShape(50))
                .padding(horizontal = 2.dp),
            contentAlignment = Alignment.CenterStart
        ) {
            Box(
                modifier = Modifier
                    .size(24.dp)
                    .offset(x = thumbOffset)
                    .background(Color.White, shape = CircleShape)
            )
        }
    }
}

@Preview(showBackground = true)
@Composable
fun AnimatedSettingsTogglePreview() {
    var isEnabled by remember { mutableStateOf(false) }

    CenteredPreview {
        AnimatedSettingsToggle(
            label = "Wi-Fi",
            description = "Enable wireless connectivity",
            isEnabled = isEnabled,
            onToggle = { }
        )
    }
}

Three animate*AsState calls, no third-party library, no animation framework — just state and a handful of composable functions.

Common Mistakes

Animating inside a LazyColumn without stable keys. Each item gets its own animation instance, which is correct — but if your remember isn’t keyed to the item’s identity, Compose may reuse the state for a different item when the list scrolls. Always key your remember calls to something stable and unique per item.

Expecting finishedListener to fire on every frame. It fires once, when the animation settles. If you want per-frame callbacks, you need Animatable with a custom coroutine loop.

Using animate*AsState for enter/exit animations. When a composable leaves the composition, it’s gone — animate*AsState has nothing to animate. Use AnimatedVisibility for any case where the composable needs to animate out before being removed.

Conclusion

animate*AsState in Jetpack Compose is one of those APIs you end up using all the time.

It keeps animation logic simple and close to your UI state, which is exactly how Compose is meant to work.

Start with small interactions. Once you get comfortable, you’ll naturally move to more advanced animation APIs when needed.

Jetpack Compose Animation System

Jetpack Compose Animation System Explained: A Beginner Guide

Animations are one of those things that feel easy until you actually try to wire them into a real screen. You start with a simple fade or size change, and suddenly you’re juggling state, re-composition, and timing issues that don’t behave the way you expected.

I ran into this while building a product listing screen. Small interactions like expanding cards, animating filters, and handling loading states quickly became messy. That’s when the Jetpack Compose Animation System started to make sense — not as a set of APIs, but as a model tied directly to state.

This post breaks that down in a practical way.

What the Jetpack Compose Animation System Actually Is

The core idea is straightforward:

Your UI depends on state, and animations happen when that state changes.

You don’t trigger animations manually. You describe what the UI should look like for a given state, and Compose handles the transition.

Instead of writing something like “start animation on click”, you write:

  • if expanded → height = 200dp
  • if collapsed → height = 100dp

When the state changes, Compose animates between those values.

Understanding this mental model will make everything else click. In Compose, your UI is a function of state:

UI = f(state) — When state changes, Compose re-renders the UI. Animations are just a smooth interpolation between two states over time. You don’t “run” an animation — you change state and tell Compose how to animate the transition.

The animation system in Compose has three layers, and it’s worth knowing which layer you’re working at:

Layer 1 — High-level APIs: AnimatedVisibility, AnimatedContent, Crossfade. These handle the most common cases with zero configuration needed.

Layer 2 — Value-based APIs: animate*AsState, updateTransition, InfiniteTransition. These animate specific values (Float, Dp, Color, etc.) that you then apply in your composables.

Layer 3 — Low-level APIs: Animatable, coroutine-based. Full manual control for complex sequencing, interruptions, or physics-based motion.

The golden rule: start at the highest level that solves your problem. Only go deeper when you genuinely need more control. Most production animations live happily in layers 1 and 2.

The Core Building Blocks

Before writing any animations, it helps to understand the main APIs you’ll actually use:

1. animate*AsState

For simple, one-off animations tied to a single value.

2. updateTransition

For animating multiple values based on the same state.

3. AnimatedVisibility

For showing and hiding composables with animation.

4. AnimatedContent

For switching between UI states.

5. rememberInfiniteTransition

For looping animations.

You don’t need all of them at once. Most real screens use 1–2 of these consistently.

Why This Model Works Well

Once you lean into this approach, a few things improve right away:

  • No need to manage animation lifecycle
  • No manual cancellation logic
  • UI stays consistent with state
  • Less glue code

This becomes especially useful when multiple properties change together. You don’t coordinate them manually. You just describe the end result.

Your First Real Animation

Let’s build something practical: a card that expands when clicked.

Step 1: Define State

Kotlin
@Composable
fun ExpandableCard() {
    var expanded by remember { mutableStateOf(false) }

This is the trigger. Everything depends on this boolean.

Step 2: Animate a Value

Kotlin
val height by animateDpAsState(
        targetValue = if (expanded) 200.dp else 100.dp,
        label = "cardHeight"
    )

What’s happening here:

  • targetValue changes when expanded changes
  • Compose animates between old and new values
  • The result (height) updates continuously during animation

You don’t write animation logic. You describe the end state.

Step 3: Apply It to UI

Kotlin
Card(
        modifier = Modifier
            .fillMaxWidth()
            .height(height)
            .clickable { expanded = !expanded }
    ) {
        Text(
            text = if (expanded) "Expanded content" else "Collapsed",
            modifier = Modifier.padding(16.dp)
        )
    }
}

That’s it. No animator objects, no listeners.

Full Code with Working Preview

Kotlin
@Composable
fun ExpandableCard() {
    var expanded by remember { mutableStateOf(false) }

    val height by animateDpAsState(
        targetValue = if (expanded) 200.dp else 100.dp,
        label = "cardHeight"
    )
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .height(height)
            .clickable { expanded = !expanded }
    ) {
        Text(
            text = if (expanded) "Expanded content" else "Collapsed",
            modifier = Modifier.padding(16.dp)
        )
    }
}

@Preview(showBackground = true)
@Composable
private fun ExpandableCardPreview() {
    MaterialTheme {
        ExpandableCard1()
    }
}

Controlling Animation Behavior

The default animation works, but real apps need control.

Custom Animation Spec

Kotlin
val height by animateDpAsState(
    targetValue = if (expanded) 200.dp else 100.dp,
    animationSpec = tween(
        durationMillis = 500,
        easing = FastOutSlowInEasing
    ),
    label = "cardHeight"
)

Now you control:

  • Duration
  • Easing curve

Spring Animation

Kotlin
animationSpec = spring(
    dampingRatio = Spring.DampingRatioMediumBouncy,
    stiffness = Spring.StiffnessLow
)

Spring animations feel more natural for things like cards or draggable UI.

Animating Multiple Properties Together

This is where updateTransition becomes useful.

Let’s animate both height and color based on the same state.

Kotlin
val transition = updateTransition(
    targetState = expanded,
    label = "cardTransition"
)

Animate Height

Kotlin
val height by transition.animateDp(
    label = "height"
) { state ->
    if (state) 200.dp else 100.dp
}

Animate Color

Kotlin
val backgroundColor by transition.animateColor(
    label = "color"
) { state ->
    if (state) Color.Blue else Color.Gray
}

Apply to UI

Kotlin
Card(
    modifier = Modifier
        .fillMaxWidth()
        .height(height)
        .clickable { expanded = !expanded },
    colors = CardDefaults.cardColors(containerColor = backgroundColor)
) {
    Text(
        text = "Tap to expand",
        modifier = Modifier.padding(16.dp)
    )
}

Now both properties animate in sync, driven by the same state.

Showing and Hiding Content

For visibility changes, don’t animate alpha manually. Use AnimatedVisibility.

Kotlin
AnimatedVisibility(visible = expanded) {
    Text(
        text = "Extra details shown here",
        modifier = Modifier.padding(16.dp)
    )
}

By default, it fades and expands. You can customize it:

Kotlin
AnimatedVisibility(
    visible = expanded,
    enter = fadeIn() + expandVertically(),
    exit = fadeOut() + shrinkVertically()
) {
    Text("Details")
}

This keeps your intent clear: you’re not animating alpha, you’re controlling visibility.

Switching Between UI States

For replacing content, use AnimatedContent.

Kotlin
AnimatedContent(targetState = expanded, label = "content") { state ->
    if (state) {
        Text("Expanded View")
    } else {
        Text("Collapsed View")
    }
}

This automatically animates between the two layouts.

Infinite Animations

For loaders or subtle UI effects:

Kotlin
val infiniteTransition = rememberInfiniteTransition(label = "pulse")val scale by infiniteTransition.animateFloat(
    initialValue = 1f,
    targetValue = 1.1f,
    animationSpec = infiniteRepeatable(
        animation = tween(800),
        repeatMode = RepeatMode.Reverse
    ),
    label = "scale"
)

Apply it:

Kotlin
Box(
    modifier = Modifier
        .size(100.dp)
        .scale(scale)
        .background(Color.Blue)
)

Good for:

  • Loading indicators
  • Attention hints
  • Micro-interactions

Conclusion

The Jetpack Compose Animation System feels strange at first because it flips the mental model. You’re not telling the UI how to animate. You’re describing how it should look in different states.

Once that clicks, animations become predictable.

Start small:

  • Animate size
  • Then color
  • Then combine them

After a few screens, you’ll stop thinking about “animations” entirely and just think in terms of state transitions.

That’s when Compose starts to feel natural.

new ripple api in jetpack compose

New Ripple API in Jetpack Compose: What Changed and How to Use It (Complete Guide)

Jetpack Compose continues to evolve, and one of the most interesting updates is the new Ripple API. If you’ve been building modern Android UIs, you’ve probably used ripple effects to give users visual feedback when they tap on buttons, cards, or other interactive elements. That subtle wave animation plays a big role in making interactions feel responsive and intuitive.

With the latest updates, Google has refined how ripple indications work in Compose. The new approach makes ripple effects more efficient, more customizable, and better aligned with Material Design 3.

In this article, we’ll explore what changed, why these updates matter, and how you can start using the new Ripple API in Jetpack Compose in your apps.

What’s Covered in This Guide

We’ll walk through:

  • What ripple effects are in Jetpack Compose
  • Why the ripple API was updated
  • How the new Ripple API works
  • How to implement it using Kotlin
  • Best practices for customizing ripple behavior

By the end, you’ll have a clear understanding of how the new ripple system works and how to apply it effectively in your Compose UI.

What Is Ripple in Jetpack Compose?

Ripple is the touch feedback animation shown when a user taps or presses a UI component.

For example:

  • Buttons
  • Cards
  • List items
  • Icons
  • Navigation items

When the user taps an element, a circular wave spreads from the touch point.

This animation improves:

  • User experience
  • Accessibility
  • Visual feedback
  • Interaction clarity

In Material Design, ripple is the default interaction effect.

In Jetpack Compose, ripple is typically used with clickable modifiers.

Kotlin
Modifier.clickable { }

By default, this modifier automatically adds ripple feedback.

Why the Ripple API Changed

For a long time, ripple effects in Jetpack Compose were implemented through the Indication system, typically using rememberRipple(). While this approach worked well, it came with a few limitations.

Composition overhead:
 Since rememberRipple() was a composable function, it participated in the recomposition cycle. In some cases, this introduced unnecessary overhead for something that should ideally remain lightweight.

Memory usage:
 Each usage created new state objects, which could increase memory usage when ripple effects were applied across many UI components.

Tight coupling with Material themes:
 The implementation was closely tied to Material 2 and Material 3. This made it less flexible for developers building custom design systems or UI frameworks.

To address these issues, the ripple implementation has been redesigned using the Modifier.Node architecture. This moves ripple handling closer to the rendering layer, allowing it to be drawn more efficiently without triggering unnecessary recompositions.

As a result, the updated API makes ripple behavior:

  • More performant
  • More consistent with Material 3
  • Easier to customize
  • Better aligned with the modern Indication system

Overall, this change simplifies how ripple effects are handled while improving performance and flexibility for Compose developers.

Old Ripple Implementation (Before the Update)

Before the New Ripple API in Jetpack Compose, developers often used rememberRipple().

Kotlin
Modifier.clickable(
    indication = rememberRipple(),
    interactionSource = remember { MutableInteractionSource() }
) {
    // Handle click
}
  • indication → defines the visual feedback
  • rememberRipple() → creates ripple animation
  • interactionSource → tracks user interactions (press, hover, focus)

Although this worked well, it required extra setup for customization.

The New Ripple API in Jetpack Compose

The New Ripple API in Jetpack Compose simplifies ripple creation and aligns it with Material3 design system updates.

The ripple effect is now managed through Material ripple APIs and better indication handling.

In most cases, developers no longer need to manually specify ripple.

Default Material components automatically apply ripple.

Kotlin
Button(onClick = { }) {
    Text("Click Me")
}

This button already includes ripple.

However, when working with custom layouts, you may still need to configure ripple manually.

Key Changes from Old to New

Key changes in Compose Ripple APIs (1.7+)

  • rememberRipple() is deprecated. Use ripple() instead.
     The old API relied on the legacy Indication system, while ripple() works with the new node-based indication architecture.
  • RippleTheme and LocalRippleTheme are deprecated.
     Material components no longer read LocalRippleTheme. For customization use RippleConfiguration / LocalRippleConfiguration or implement a custom ripple.
  • Many components now default interactionSource to null, allowing lazy creation of MutableInteractionSource to reduce unnecessary allocations.
  • The indication system moved to the Modifier.Node architecture.
     Indication#rememberUpdatedInstance was replaced by IndicationNodeFactory for more efficient rendering.

Key Differences at a Glance:

Basic Example Using the New Ripple API

Let’s start with a simple example by creating a clickable Box with a ripple effect. This demonstrates how touch feedback appears when a user interacts with a UI element.

Before looking at the new approach, here’s how ripple was typically implemented in earlier versions of Compose.

Old implementation (Deprecated):

Kotlin
Box(
    modifier = Modifier.clickable(
        onClick = { /* action */ },
        interactionSource = remember { MutableInteractionSource() },
        indication = rememberRipple()
    )
) {
    Text("Tap me!")
}

The previous implementation relied on rememberRipple(), which has now been replaced by the updated ripple API.

Using the New Ripple API:

Here’s how you can implement the same behavior using the updated ripple system.

Kotlin
@Composable
fun RippleBox() {
    val interactionSource = remember { MutableInteractionSource() }  // Or pass null to lazy-init   
    
    Box(
        modifier = Modifier
            .size(120.dp)
            .background(Color.LightGray)
            .clickable(
                interactionSource = interactionSource,
                indication = ripple(), // From material3 or material
                onClick = {}
            )
    ){
      Text("Tap me!")
    }
}

In many cases you can simply pass interactionSource = null, which allows Compose to lazily create it only when needed.

Understanding the Key Components

MutableInteractionSource

Kotlin
val interactionSource = remember { MutableInteractionSource() }

MutableInteractionSource emits interaction events such as:

  • Press
  • Focus
  • Hover
  • Drag

Indications like ripple observe these events to trigger animations.

clickable modifier

Kotlin
Modifier.clickable()

This makes the composable interactive and triggers ripple on tap.

ripple()

Kotlin
indication = ripple()

ripple() is the new ripple API in Jetpack Compose and replaces the deprecated rememberRipple() implementation.

By default:

  • The ripple color is derived from MaterialTheme
  • The ripple originates from the touch point
  • The ripple is bounded within the component by default

Unlike the previous API, ripple() is not a composable function and works with the newer Modifier.Node-based indication system, which reduces allocations and improves performance.

Benefits of the New Ripple API

The updated API offers several improvements:

  • Simpler API — fewer concepts to manage
  • Better performance — avoids unnecessary recompositions
  • Cleaner syntax — easier to read and maintain
  • More flexibility for modern Compose UI architectures

Customizing Ripple in Jetpack Compose

One advantage of the New Ripple API in Jetpack Compose is easier customization.

You can modify:

  • color
  • radius
  • bounded/unbounded ripple

Example: Changing Ripple Color

Kotlin
.clickable(
    interactionSource = interactionSource,
    indication = ripple(
        color = Color.Red
    ),
    onClick = {}
)

Here we customize the ripple color.

When the user taps the component, the ripple will appear red instead of the default theme color.

Example: Unbounded Ripple

By default, ripple is bounded, meaning it stays inside the component.

If you want ripple to spread outside the element:

Kotlin
indication = ripple(
    bounded = false
)

Use Cases

Unbounded ripple works well for:

  • floating action buttons
  • icon buttons
  • circular elements

Example: Setting Ripple Radius

You can also control ripple size.

Kotlin
indication = ripple(
    radius = 60.dp
)

The radius defines how far the ripple spreads from the touch point.

This can help match custom UI designs.

Advanced Customization: RippleConfiguration

If you want to change the color or the alpha (transparency) of your ripples globally or for a specific part of your app, the old LocalRippleTheme is out (deprecated). Instead, we use LocalRippleConfiguration.

The modern approach uses RippleConfiguration and LocalRippleConfiguration. This allows you to customize ripple appearance for a specific component or subtree of your UI.

Example: Custom Ripple

Kotlin
val myCustomRippleConfig = RippleConfiguration(
    color = Color.Magenta,
    rippleAlpha = RippleAlpha(
        pressedAlpha = 0.2f,
        focusedAlpha = 0.2f,
        draggedAlpha = 0.1f,
        hoveredAlpha = 0.4f
    )
)

CompositionLocalProvider(
    LocalRippleConfiguration provides myCustomRippleConfig
) {
    Button(onClick = { }) {
        Text("I have a Magenta Ripple!")
    }
}

RippleConfiguration

A configuration object that defines the visual appearance of ripple effects.

RippleAlpha

Controls the ripple opacity for different interaction states:

  • pressedAlpha
  • focusedAlpha
  • draggedAlpha
  • hoveredAlpha

CompositionLocalProvider

Wraps a section of UI and provides a custom ripple configuration to all child components that read LocalRippleConfiguration.

Disabling Ripple

You can disable ripple effects completely:

Kotlin
CompositionLocalProvider(LocalRippleConfiguration provides null) {
    Button(onClick = {}) {
        Text("No ripple")
    }
}

When You Do NOT Need to Use Ripple Manually

With the new ripple API in Jetpack Compose, many Material components already include ripple feedback by default. This means you usually don’t need to manually specify indication = ripple().

Examples include:

  • Button
  • Card (clickable version in Material3)
  • ListItem
  • IconButton
  • NavigationBarItem

These components internally handle interaction feedback using the ripple system.

Kotlin
Card(
    onClick = { }
) {
    Text("Hello")
}

In Material3, providing onClick automatically makes the Card clickable and displays the ripple effect.

No manual ripple indication is required.

Best Practices for Using the New Ripple API in Jetpack Compose

1. Prefer Default Material Components

Material components already include ripple behavior.

This keeps UI consistent with Material Design.

2. Avoid Over-Customizing Ripple

Too much customization can create inconsistent UX.

Stick with theme defaults unless necessary.

3. Use interactionSource = null Unless You Need It

In modern Compose versions, you usually do not need to create a MutableInteractionSource manually.

Kotlin
Modifier.clickable(
    interactionSource = null,
    indication = ripple(),
    onClick = { }
)

Passing null allows Compose to lazily create the interaction source only when required.

Create your own MutableInteractionSource only if you need to observe interaction events.

4. Keep Ripple Bounded for Most UI

Bounded ripples keep the animation inside the component bounds and generally look cleaner.

This is the default behavior for most Material components.

Use unbounded ripple only when the design specifically requires it.

Performance Improvements in the New Ripple API

The new ripple implementation in Jetpack Compose introduces several internal improvements.

Reduced allocations

Ripple now uses the Modifier.Node architecture, which reduces object allocations compared to the older implementation.

Improved rendering efficiency

Ripple drawing is handled through node-based modifiers, making the rendering lifecycle more efficient.

Updated Indication system

Ripple is now implemented using IndicationNodeFactory, which replaces the older Indication implementation that relied on rememberUpdatedInstance.

Common Mistakes Developers Make

Using old rememberRipple()

Many developers still use:

Kotlin
rememberRipple()

This API is now deprecated.

Use the modern API instead:

Kotlin
ripple()

Manually creating InteractionSource unnecessarily

Older examples often include:

Kotlin
interactionSource = remember { MutableInteractionSource() }

In modern Compose versions, you can usually pass:

Kotlin
interactionSource = null

This allows Compose to lazily create the interaction source only when needed.

Create your own MutableInteractionSource only when you need to observe interaction events.

Adding Ripple to Non-clickable UI

Ripple should be used only on interactive components such as buttons, cards, or clickable surfaces.

Using ripple on static UI elements can create confusing user experiences.

Migration Guide: Old API to New Ripple API

Old implementation:

Kotlin
Modifier.clickable(
    interactionSource = remember { MutableInteractionSource() },
    indication = rememberRipple(),
    onClick = {}
)

New implementation:

Kotlin
Modifier.clickable(
    interactionSource = null,
    indication = ripple(),
    onClick = {}
)

Key changes:

  • rememberRipple() → replaced with ripple()
  • interactionSource can now be null, allowing Compose to lazily create it when needed

This simplifies the code and avoids unnecessary allocations.

If you need to observe interaction events, you can still provide your own MutableInteractionSource.

Conclusion

The New Ripple API in Jetpack Compose simplifies how developers implement touch feedback while improving performance and consistency.

Key takeaways:

  • Ripple provides visual feedback for user interactions
  • The new API replaces rememberRipple() with ripple()
  • Material components already include ripple by default
  • Custom components can easily add ripple using Modifier.clickable
  • The updated system improves performance and flexibility

If you build modern Android apps with Jetpack Compose, understanding the New Ripple API in Jetpack Compose is essential for creating responsive and user-friendly interfaces.

Compose Multiplatform

Compose Multiplatform (CMP) in Production: The Complete Technical Guide for Android, iOS & Web

If you’ve been in the mobile and cross-platform world lately, you’ve probably heard a lot about Compose Multiplatform (CMP). It’s one of the fastest-growing ways to build apps that run on Android, iOS and the Web using a single shared UI approach.

But what exactly is CMP? And why are developers increasingly choosing it over other frameworks? In this post, we’ll break it down, with examples, comparisons and real reasons developers love it.

What Is Compose Multiplatform — Precisely 

Compose Multiplatform (CMP) is a UI framework developed and maintained by JetBrains, built on top of Google’s Jetpack Compose runtime. It extends the Compose programming model — declarative, reactive, composable UI functions — beyond Android to iOS, Desktop (JVM), and Web (Kotlin/Wasm).

CMP is layered on top of Kotlin Multiplatform (KMP), which is the underlying technology for compiling Kotlin code to multiple targets: JVM (Android/Desktop), Kotlin/Native (iOS/macOS), and Kotlin/Wasm (Web). Understanding this layering matters architecturally:

Kotlin
┌─────────────────────────────────────────────────────────┐
│                Compose Multiplatform (CMP)              │
│              (Shared declarative UI layer)              │
├─────────────────────────────────────────────────────────┤
│               Kotlin Multiplatform (KMP)                │
│         (Shared business logic, data, domain)           │
├───────────┬──────────────┬──────────────┬───────────────┤
│  Kotlin/  │ Kotlin/      │ Kotlin/      │ Kotlin/       │
│  JVM      │ Native       │ Wasm         │ JVM           │
│ (Android) │ (iOS/macOS)  │ (Web)        │ (Desktop)     │
└───────────┴──────────────┴──────────────┴───────────────┘

What CMP is not:

  • Not a WebView wrapper
  • Not a JavaScript runtime or bridge
  • Not a pixel-for-pixel clone of native UI widgets on every platform
  • Not a guarantee that code runs identically on all platforms — it compiles and runs on all platforms, with deliberate platform-specific divergences in rendering, gestures, and system behaviors

Current Platform Support: Honest Status

What “iOS API Stable” means precisely: JetBrains has declared the CMP public API surface stable, meaning they will not make breaking changes without a deprecation cycle. It does not mean:

  • Pixel-perfect parity with SwiftUI or UIKit
  • Complete VoiceOver/accessibility support (this is a known gap as of 2026)
  • Identical scroll physics to UIScrollView
  • Equivalent Xcode debugging experience to native Swift development

Teams shipping CMP-based iOS apps in production report success, but they do so with deliberate investment in iOS-specific testing, accessibility audits, and gesture tuning — not by assuming parity.

CMP vs Flutter vs React Native — Engineering Comparison

Compose Multiplatform vs Flutter

Both use a custom rendering engine (not native OS widgets) to draw UI. Key engineering differences:

Honest verdict: Flutter has a more mature cross-platform tooling story and stronger iOS accessibility today. CMP wins decisively if your team is already invested in Kotlin, Jetpack libraries, and Android-first development.

Compose Multiplatform vs React Native

React Native’s new architecture (JSI + Fabric renderer) significantly closes the performance gap that historically plagued the JavaScript bridge. The architectural difference from CMP:

  • CMP compiles Kotlin to native binaries — no runtime JS, no bridge
  • React Native (New Architecture) uses JSI for synchronous JS-to-native calls — faster than the old bridge, but still a JS runtime overhead
  • React Native renders actual native widgets on each platform; CMP renders via Skia
  • React Native is the right choice for web-first teams; CMP is the right choice for Kotlin-first teams

How CMP Works Under the Hood

Rendering Pipeline

CMP uses different rendering approaches per platform, which explains both its strengths and its platform-specific behavioral differences:

Kotlin
commonMain Compose Code
         │
         ├── Android
         │     └── Jetpack Compose Runtime
         │           └── Android RenderNode / Canvas API
         │                 └── Skia (via Android's internal pipeline)
         │
         ├── iOS
         │     └── Skiko (Kotlin/Native bindings to Skia)
         │           └── Metal GPU API
         │                 └── CAMetalLayer embedded in UIView
         │
         ├── Desktop (JVM)
         │     └── Skiko
         │           └── OpenGL / DirectX / Metal (OS-dependent)
         │
         └── Web
               └── Kotlin/Wasm + Skia compiled to WebAssembly
                     └── HTML <canvas> element

Critical implication of this architecture: Because CMP on iOS renders through a CAMetalLayer-backed UIView (not through SwiftUI’s layout engine), layout behaviors, font metrics, shadow rendering, and scroll momentum physics are produced by Skia — not by iOS’s native compositor. This is why experienced iOS users may notice subtle differences. It is also why full SwiftUI NavigationStack integration with CMP-managed screens is architecturally complicated.

The KMP Foundation: expect/actual

The expect/actual mechanism is the primary tool for platform branching. It operates at compile time, not runtime:

Kotlin
// commonMain — declares the contract
expect fun currentTimeMillis(): Long

// androidMain - Android implementation
actual fun currentTimeMillis(): Long = System.currentTimeMillis()

// iosMain - iOS implementation (using Kotlin/Native platform APIs)
actual fun currentTimeMillis(): Long = 
    NSDate().timeIntervalSince1970.toLong() * 1000

expect/actual works for:

  • Top-level functions
  • Classes (with matching constructors)
  • Objects
  • Interfaces (less common; prefer interfaces in commonMain with actual implementations)
  • Typealiases (useful for mapping platform types)

expect class constructor limitation: When you declare expect class Foo(), every actual implementation must match the constructor signature. This creates a real problem for Android classes that require Context. The correct pattern uses dependency injection or a platform-provided factory, not a bare constructor — covered in detail in the DI section.

Project Structure and Modularization 

The single-module structure shown in most tutorials works for demos. Production apps require modularization from the start — it affects build times, team ownership, and testability fundamentally.

Recommended Multi-Module Architecture

Kotlin
root/
├── gradle/
│   └── libs.versions.toml          ← Centralized version catalog
│
├── build-logic/                    ← Convention plugins
│   └── src/main/kotlin/
│       ├── CmpLibraryPlugin.kt     ← Shared Gradle config for library modules
│       └── CmpAppPlugin.kt         ← Shared Gradle config for app modules
│
├── core/
│   ├── domain/                     ← Pure Kotlin: entities, use cases, repository interfaces
│   │   └── src/commonMain/
│   ├── data/                       ← Repository implementations, network, cache
│   │   └── src/commonMain/
│   ├── ui-components/              ← Shared design system, reusable composables
│   │   └── src/commonMain/
│   ├── navigation/                 ← Route definitions, navigation contracts
│   │   └── src/commonMain/
│   └── testing/                    ← Shared test utilities and fakes
│       └── src/commonTest/
│
├── features/
│   ├── product-list/
│   │   └── src/commonMain/
│   ├── product-detail/
│   │   └── src/commonMain/
│   └── cart/
│       └── src/commonMain/
│
├── composeApp/                     ← Platform entry points + DI wiring
│   └── src/
│       ├── commonMain/             ← App-level navigation graph, DI setup
│       ├── androidMain/            ← Android Activity, platform DI modules
│       ├── iosMain/                ← iOS entry point called from Swift
│       └── wasmJsMain/             ← Web entry point
│
└── iosApp/                         ← Xcode project
    └── iosApp/
        ├── ContentView.swift       ← Hosts CMP root composable
        └── iOSApp.swift            ← App lifecycle; calls into Kotlin layer

Why this structure matters:

  • :core:domain depends on nothing — it’s pure Kotlin, testable anywhere
  • :core:data depends on :core:domain interfaces only
  • Feature modules depend on :core:domain and :core:ui-components; never on each other
  • Platform entry points wire everything together via DI — they’re the only place with platform-specific imports

Gradle Configuration — The Real Picture

Here is a production-realistic Gradle configuration with current APIs (Kotlin 2.1.x):

Kotlin
// build-logic/src/main/kotlin/CmpLibraryPlugin.kt
// Convention plugin applied to all shared library modules

import org.jetbrains.kotlin.gradle.dsl.JvmTarget

plugins {
    id("com.android.library")
    kotlin("multiplatform")
    id("org.jetbrains.compose")
    id("org.jetbrains.kotlin.plugin.compose")
}

kotlin {
    androidTarget {
        compilerOptions {                    // Note: kotlinOptions {} is deprecated
            jvmTarget.set(JvmTarget.JVM_11)
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "SharedModule"
            isStatic = true
            // Static frameworks are required for proper Kotlin/Native
            // memory management with Swift ARC interop
        }
    }

    @OptIn(ExperimentalWasmDsl::class)
    wasmJs {
        browser()
        binaries.executable()
    }

    sourceSets {
        commonMain.dependencies {
            implementation(compose.runtime)
            implementation(compose.foundation)
            implementation(compose.material3)
            implementation(compose.ui)
            implementation(compose.components.resources)
            implementation(libs.lifecycle.viewmodel.compose)      // Multiplatform ViewModel
            implementation(libs.lifecycle.runtime.compose)        // collectAsStateWithLifecycle
            implementation(libs.navigation.compose)               // Multiplatform nav
            implementation(libs.kotlinx.coroutines.core)
            implementation(libs.koin.compose)                     // DI
        }

        androidMain.dependencies {
            implementation(libs.androidx.activity.compose)
            implementation(libs.kotlinx.coroutines.android)       // Provides Dispatchers.Main on Android
        }

        iosMain.dependencies {
            implementation(libs.kotlinx.coroutines.core)
            // Note: kotlinx-coroutines-core for Native provides
            // Dispatchers.Main via Darwin integration - requires explicit dependency
        }
        commonTest.dependencies {
            implementation(libs.kotlin.test)
            implementation(libs.kotlinx.coroutines.test)
        }
    }
}

Known Gradle pain points in production:

  • Kotlin/Native compilation is 3–5× slower than JVM compilation. Enable the Kotlin build cache (kotlin.native.cacheKind=static in gradle.properties) and Gradle build cache
  • XCFramework generation for App Store distribution requires a separate XCFramework task — not included in the default template
  • The linkDebugFrameworkIosArm64 Gradle task must be connected to Xcode’s build phase; misconfiguration here is the #1 cause of “works on simulator, fails on device” issues
  • Keep isStatic = true on iOS framework targets. Dynamic frameworks are supported but add complexity to iOS app startup and Xcode integration

Correct Architectural Patterns

The Layered Architecture for CMP

Kotlin
┌─────────────────────────────────────────┐
│              UI Layer (CMP)             │
│  Composables receive UiState, emit      │
│  events/callbacks. No business logic.   │
├─────────────────────────────────────────┤
│           ViewModel Layer               │
│  Holds UiState (single StateFlow).      │
│  Orchestrates use cases. Maps domain    │
│  models to UI models.                   │
├─────────────────────────────────────────┤
│            Domain Layer                 │
│  Use cases (interactors). Pure Kotlin.  │
│  No framework dependencies.             │
├─────────────────────────────────────────┤
│             Data Layer                  │
│  Repository implementations.            │
│  Ktor for network. SQLDelight for DB.   │
│  Platform-specific data sources.        │
└─────────────────────────────────────────┘

MVI with Single UiState (Preferred for CMP)

Multiple independent StateFlow properties in a ViewModel create impossible UI states and double recompositions. Use a single sealed UiState:

Kotlin
// Correct: Single state object prevents impossible states
// and triggers exactly one recomposition per state change

sealed class ProductListUiState {
    object Loading : ProductListUiState()
    
    data class Success(
        val products: List<ProductUiModel>,
        val searchQuery: String = ""
    ) : ProductListUiState()
    
    data class Error(
        val message: String,
        val isRetryable: Boolean
    ) : ProductListUiState()
}

// UiModel - separate from domain model
// Only contains what the UI needs; formatted strings, not raw data
@Immutable  // Tells Compose compiler this is stable - critical for LazyColumn performance
data class ProductUiModel(
    val id: String,
    val name: String,
    val formattedPrice: String,    // "$12.99" not 12.99 - formatting in ViewModel, not Composable
    val description: String,
    val imageUrl: String
)
Kotlin
class ProductListViewModel(
    private val getProductsUseCase: GetProductsUseCase
) : ViewModel() {

private val _uiState = MutableStateFlow<ProductListUiState>(ProductListUiState.Loading)
    val uiState: StateFlow<ProductListUiState> = _uiState.asStateFlow()
    init {
        loadProducts()
    }

    fun loadProducts() {
        viewModelScope.launch {
            _uiState.value = ProductListUiState.Loading
            getProductsUseCase()
                .onSuccess { products ->
                    _uiState.value = ProductListUiState.Success(
                        products = products.map { it.toUiModel() }
                    )
                }
                .onFailure { error ->
                    _uiState.value = ProductListUiState.Error(
                        message = error.toUserFacingMessage(),
                        isRetryable = error is NetworkException
                    )
                }
        }
    }

    fun onSearchQueryChanged(query: String) {
        val currentState = _uiState.value as? ProductListUiState.Success ?: return
        _uiState.value = currentState.copy(searchQuery = query)
    }
}

// Extension to convert domain model to UI model
private fun Product.toUiModel() = ProductUiModel(
    id = id,
    name = name,
    formattedPrice = "$${"%.2f".format(price)}",
    description = description,
    imageUrl = imageUrl
)

Why error.toUserFacingMessage() matters: On Kotlin/Native (iOS), exception.message can be null. Always map exceptions to typed error representations before exposing them to the UI layer.

State Management Done Right 

State Hoisting — The Correct Pattern

The most common architectural mistake in Compose (multiplatform or not) is passing a ViewModel into a composable. This breaks testability, violates unidirectional data flow, and causes incorrect recomposition scoping.

The rule: Composables receive state (immutable data) and emit events (callbacks). They never hold or reference a ViewModel directly.

Kotlin
// Anti-pattern — breaks testability and state hoisting
@Composable
fun ProductListScreen(viewModel: ProductListViewModel) {
    val uiState by viewModel.uiState.collectAsState()
    // ...
}

// Correct - state in, events out
@Composable
fun ProductListScreen(
    uiState: ProductListUiState,
    onRetry: () -> Unit,
    onSearchQueryChanged: (String) -> Unit,
    onProductClick: (String) -> Unit,   // Pass ID, not the whole object
    modifier: Modifier = Modifier        // Always accept a Modifier parameter
) {
    when (uiState) {
        is ProductListUiState.Loading -> LoadingContent(modifier)
        is ProductListUiState.Error -> ErrorContent(
            message = uiState.message,
            isRetryable = uiState.isRetryable,
            onRetry = onRetry,
            modifier = modifier
        )
        is ProductListUiState.Success -> ProductListContent(
            products = uiState.products,
            searchQuery = uiState.searchQuery,
            onSearchQueryChanged = onSearchQueryChanged,
            onProductClick = onProductClick,
            modifier = modifier
        )
    }
}

The ViewModel sits at the navigation/screen level, never inside a composable:

Kotlin
// In your navigation graph 
composable<ProductList> {
    val viewModel: ProductListViewModel = koinViewModel()
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    // collectAsStateWithLifecycle is preferred over collectAsState —
    // it respects platform lifecycle and pauses collection when the app is backgrounded

    ProductListScreen(
        uiState = uiState,
        onRetry = viewModel::loadProducts,
        onSearchQueryChanged = viewModel::onSearchQueryChanged,
        onProductClick = { productId ->
            navController.navigate(ProductDetail(productId))
        }
    )
}

remember vs rememberSaveable

Kotlin
@Composable
fun SearchBar(
    query: String,                        // Lifted state — parent owns it
    onQueryChange: (String) -> Unit,
    onSearch: (String) -> Unit,
    modifier: Modifier = Modifier
) {
    // No local mutableStateOf needed — state is owned by caller
    // Only use remember for objects that are expensive to create
    val focusRequester = remember { FocusRequester() }

    OutlinedTextField(
        value = query,
        onValueChange = onQueryChange,
        modifier = modifier.focusRequester(focusRequester),
        // ...
    )
}

// For state that must survive configuration changes AND process death,
// use rememberSaveable with a Saver if the type is not primitive:
val scrollState = rememberSaveable(saver = ScrollState.Saver) { ScrollState(0) }

Lifecycle-Aware Collection

collectAsState() does not pause collection when the app is backgrounded on iOS. Use collectAsStateWithLifecycle() from lifecycle-runtime-compose:

Kotlin
// Lifecycle-aware — pauses when app is in background on all platforms
val uiState by viewModel.uiState.collectAsStateWithLifecycle()

// Always-on - continues collecting even when app is backgrounded
val uiState by viewModel.uiState.collectAsState()

Type-Safe Navigation Across Platforms

String Routes Are Deprecated — Use Type-Safe Navigation

As of navigation-compose 2.8.x, type-safe navigation using @Serializable route objects is stable and the recommended approach. String-based routes are error-prone, refactoring-unsafe, and lack compile-time guarantees.

Kotlin
// core/navigation/src/commonMain/RouteDefinitions.kt

import kotlinx.serialization.Serializable

@Serializable
object ProductList                          // No-argument destination

@Serializable
data class ProductDetail(val productId: String)  // Typed argument

@Serializable
object Cart

@Serializable
data class Checkout(
    val cartId: String,
    val promoCode: String? = null           // Optional parameters supported
)
Kotlin
// composeApp/src/commonMain/AppNavigation.kt

@Composable
fun AppNavigation(
    navController: NavHostController = rememberNavController()
) {
    NavHost(
        navController = navController,
        startDestination = ProductList
    ) {
        composable<ProductList> {
            val viewModel: ProductListViewModel = koinViewModel()
            val uiState by viewModel.uiState.collectAsStateWithLifecycle()
            ProductListScreen(
                uiState = uiState,
                onRetry = viewModel::loadProducts,
                onSearchQueryChanged = viewModel::onSearchQueryChanged,
                onProductClick = { productId ->
                    navController.navigate(ProductDetail(productId))
                }
            )
        }

        composable<ProductDetail> { backStackEntry ->
            val route: ProductDetail = backStackEntry.toRoute()  // Type-safe extraction
            val viewModel: ProductDetailViewModel = koinViewModel(
                parameters = { parametersOf(route.productId) }
            )
            val uiState by viewModel.uiState.collectAsStateWithLifecycle()
            ProductDetailScreen(
                uiState = uiState,
                onBack = { navController.navigateUp() },
                onAddToCart = viewModel::addToCart
            )
        }

        composable<Cart> {
            val viewModel: CartViewModel = koinViewModel()
            val uiState by viewModel.uiState.collectAsStateWithLifecycle()
            CartScreen(
                uiState = uiState,
                onCheckout = { cartId ->
                    navController.navigate(Checkout(cartId))
                },
                onBack = { navController.navigateUp() }
            )
        }
    }
}

Platform Navigation Caveats

iOS back-swipe gesture: The multiplatform navigation-compose supports interactive back-swipe on iOS, but the animation curve and gesture threshold are Skia-rendered approximations of the native UINavigationController push/pop animation. They are close but distinguishable to trained iOS users. For apps where native-feel is paramount, consider using Decompose (a community navigation library) which supports fully native iOS transitions via UIKit integration.

Android back handling: The hardware back button and predictive back gesture (Android 14+) require explicit handling. Register a BackHandler composable where needed:

Kotlin
BackHandler(enabled = uiState is CheckoutUiState.InProgress) {
    // Prompt user before losing checkout progress
    showExitConfirmationDialog = true
}

Web browser history: Navigation-compose on Wasm integrates with browser history via the History API, but deep link handling (initial URL → correct screen) requires setup in your Wasm entry point that the default template does not provide.

Platform-Specific Features via expect/actual

The Context Problem on Android — Solved Correctly

A common mistake is defining expect class with a no-arg constructor when the Android implementation needs Context. The correct approach uses dependency injection, not constructor parameters in the expect declaration:

Kotlin
// core/domain/src/commonMain/ — Define a pure interface
interface FileStorage {
    suspend fun saveFile(fileName: String, data: ByteArray): Result<Unit>
    suspend fun readFile(fileName: String): Result<ByteArray>
    suspend fun deleteFile(fileName: String): Result<Unit>
}

// core/data/src/androidMain/ - Android implementation with Context via DI
class AndroidFileStorage(
    private val context: Context    // Injected by DI framework
) : FileStorage {
    override suspend fun saveFile(fileName: String, data: ByteArray): Result<Unit> =
        runCatching {
            val file = File(context.filesDir, fileName)
            file.writeBytes(data)
        }
    override suspend fun readFile(fileName: String): Result<ByteArray> =
        runCatching {
            File(context.filesDir, fileName).readBytes()
        }
    override suspend fun deleteFile(fileName: String): Result<Unit> =
        runCatching {
            File(context.filesDir, fileName).delete()
        }
}

// core/data/src/iosMain/ - iOS implementation
class IosFileStorage : FileStorage {
    private val fileManager = NSFileManager.defaultManager
    override suspend fun saveFile(fileName: String, data: ByteArray): Result<Unit> =
        runCatching {
            val documentsDir = fileManager
                .URLsForDirectory(NSDocumentDirectory, NSUserDomainMask)
                .firstOrNull()?.path ?: error("No documents directory")
            val filePath = "$documentsDir/$fileName"
            data.toNSData().writeToFile(filePath, atomically = true)
        }
    // ... other implementations
}

The DI framework (Koin shown below) provides the platform-correct implementation to commonMain code — no expect/actual needed when the interface lives in commonMain.

Embedding Native Views

For platform-native components that cannot be reproduced in Compose (maps, WebViews, camera previews):

Kotlin
// features/map/src/iosMain/ — iOS-specific file
@Composable
fun NativeMapView(
    latitude: Double,
    longitude: Double,
    modifier: Modifier = Modifier
) {
    UIKitView(
        factory = {
            MKMapView().apply {
                // Configure once on creation
                showsUserLocation = true
            }
        },
        update = { mapView ->
            // Called on recomposition when inputs change
            val region = MKCoordinateRegionMake(
                CLLocationCoordinate2DMake(latitude, longitude),
                MKCoordinateSpanMake(0.01, 0.01)
            )
            mapView.setRegion(region, animated = true)
        },
        modifier = modifier
    )
}

Important:UIKitView must be in iosMain, not commonMain. Expose it via an expect/actual composable or via conditional compilation if you need a platform-specific fallback in the shared screen.

iOS-Specific: Lifecycle, Interop, and Debugging 

This section covers the most under-addressed topic in CMP guides. iOS lifecycle management is where most production incidents originate.

The iOS Lifecycle vs Android Lifecycle

On Android, ViewModel.viewModelScope is tied to Lifecycle.State.CREATED — coroutines are automatically cancelled when the ViewModel is cleared. On iOS, the mapping is:

iOS App States          →   CMP/Compose Lifecycle
─────────────────────────────────────────────────
Active (foreground)     →   Lifecycle.State.RESUMED
Inactive (transitioning)→   Lifecycle.State.STARTED
Background (suspended)  →   Lifecycle.State.CREATED
Terminated (clean exit) →   Lifecycle.State.DESTROYED
Killed by OS (OOM/force)→   DESTROYED not guaranteed

The critical issue: When an iOS app is backgrounded, the OS may suspend it entirely with no further CPU time. Coroutines in viewModelScope do not automatically pause on iOS the way Android’s lifecycle-aware components do. This means:

Kotlin
// Dangerous on iOS — will attempt network calls even when app is suspended
class ProductListViewModel : ViewModel() {
    init {
        viewModelScope.launch {
            // This may run after iOS has suspended your app,
            // causing unexpected behavior or battery drain
            productRepository.startPolling()
        }
    }
}

// Correct - use lifecycle-aware collection
class ProductListViewModel : ViewModel() {
    val uiState: StateFlow<ProductListUiState> = productRepository
        .productsFlow
        .map { it.toUiState() }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            // WhileSubscribed stops the upstream flow when there are no collectors
            // (i.e., when the screen is not visible)
            initialValue = ProductListUiState.Loading
        )
}

SharingStarted.WhileSubscribed(5_000) is the correct production pattern — it stops upstream flows 5 seconds after the last subscriber disappears (the screen leaves composition), which handles both backgrounding and navigation.

iOS App Lifecycle Events in Kotlin

To respond to iOS lifecycle events from Kotlin:

Kotlin
// iosMain — observe iOS lifecycle notifications
class IosLifecycleObserver {
    private var observers: List<NSObjectProtocol> = emptyList()

    fun start(
        onBackground: () -> Unit,
        onForeground: () -> Unit
    ) {
        val center = NSNotificationCenter.defaultCenter
        observers = listOf(
            center.addObserverForName(
                name = UIApplicationDidEnterBackgroundNotification,
                `object` = null,
                queue = NSOperationQueue.mainQueue
            ) { _ -> onBackground() },
            center.addObserverForName(
                name = UIApplicationWillEnterForegroundNotification,
                `object` = null,
                queue = NSOperationQueue.mainQueue
            ) { _ -> onForeground() }
        )
    }

    fun stop() {
        observers.forEach { NSNotificationCenter.defaultCenter.removeObserver(it) }
        observers = emptyList()
    }
}

Swift ↔ Kotlin Interop Boundary

The iOS entry point bridges Swift and Kotlin:

Kotlin
// iosApp/ContentView.swift
import SwiftUI
import ComposeApp  // The generated Kotlin framework

struct ContentView: View {
    var body: some View {
        ComposeView()
            .ignoresSafeArea(.keyboard)  // Let CMP handle keyboard insets itself
    }
}

// ComposeView wraps the Kotlin entry point
struct ComposeView: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> UIViewController {
        MainViewControllerKt.MainViewController()  // Kotlin function
    }
    func updateUIViewController(_ uiViewController: UIViewController, context: Context) {}
}
Kotlin
// iosMain — Kotlin entry point called from Swift
fun MainViewController() = ComposeUIViewController(
    configure = {
        // Configure the Compose host here
        // For example, register platform-specific implementations
    }
) {
    // Koin DI initialization for iOS
    KoinApplication(
        application = { modules(platformModule(), sharedModule()) }
    ) {
        AppNavigation()
    }
}

SwiftUI NavigationStack + CMP: You cannot simultaneously use SwiftUI NavigationStack for routing AND CMP’s NavHost for routing. Choose one as the source of truth. Mixing both causes double back-stack management and broken state restoration. The recommended approach for CMP-first apps is to let CMP’s NavHost own all navigation and wrap the entire CMP root as a single SwiftUI view.

Debugging Kotlin/Native on iOS

Xcode’s debugger does not understand Kotlin. For production crash debugging:

  • Kotlin/Native crash reports appear in Xcode Organizer as native crashes with mangled Kotlin symbols
  • You must use konan/bin/llvm-symbolizer with your app’s .dSYM file to demangle crash stacks
  • Sentry’s KMP SDK handles crash symbolication automatically and is the most production-proven option
  • For local debugging, enable Kotlin LLDB formatters by adding the Kotlin LLDB plugin to Xcode

Dependency Injection in CMP 

DI is not mentioned in most CMP tutorials and is the first thing that breaks in real projects. Koin is the most production-proven multiplatform DI framework for CMP. Kodein-DI is a capable alternative.

Kotlin
// core/di/src/commonMain/ — Shared DI modules

val domainModule = module {
    factory<GetProductsUseCase> { GetProductsUseCaseImpl(get()) }
    factory<AddToCartUseCase> { AddToCartUseCaseImpl(get()) }
}

val dataModule = module {
    single<ProductRepository> { ProductRepositoryImpl(get(), get()) }
    single<CartRepository> { CartRepositoryImpl(get()) }
    single { HttpClient(/* Ktor config */) }
}

val viewModelModule = module {
    viewModel { ProductListViewModel(get()) }
    viewModel { (productId: String) -> ProductDetailViewModel(productId, get()) }
    viewModel { CartViewModel(get(), get()) }
}
Kotlin
// composeApp/src/androidMain/ — Android platform module
val androidPlatformModule = module {
    single<FileStorage> { AndroidFileStorage(androidContext()) }
    single<AnalyticsTracker> { FirebaseAnalyticsTracker(androidContext()) }
}

// In Android Application class:
class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApplication)
            modules(androidPlatformModule, dataModule, domainModule, viewModelModule)
        }
    }
}
Kotlin
// composeApp/src/iosMain/ — iOS platform module
val iosPlatformModule = module {
    single<FileStorage> { IosFileStorage() }
    single<AnalyticsTracker> { SentryAnalyticsTracker() }
}

// Called from Swift MainViewController:
fun initKoin() {
    startKoin {
        modules(iosPlatformModule, dataModule, domainModule, viewModelModule)
    }
}
Kotlin
// Usage in navigation — type-safe ViewModel injection
composable<ProductDetail> { backStackEntry ->
    val route: ProductDetail = backStackEntry.toRoute()
    val viewModel: ProductDetailViewModel = koinViewModel(
        parameters = { parametersOf(route.productId) }
    )
    // ...
}

Accessibility — The Non-Negotiable

CMP’s iOS accessibility support is the most significant production gap as of early 2026. This section must be understood before committing to CMP for any app serving users with disabilities or operating in regulated industries (healthcare, finance, government).

Current iOS Accessibility Status

JetBrains is actively improving iOS accessibility. Track progress at youtrack.jetbrains.com — search for “iOS accessibility CMP.”

Semantic Annotations — Always Provide Them

Even where CMP’s accessibility pipeline is strong, you must provide explicit semantics:

Kotlin
@Composable
fun ProductCard(
    product: ProductUiModel,
    onClick: () -> Unit,
    modifier: Modifier = Modifier
) {
    Card(
        onClick = onClick,
        modifier = modifier
            .fillMaxWidth()
            .semantics(mergeDescendants = true) {  // Merge child semantics into one node
                contentDescription = buildString {
                    append(product.name)
                    append(", ")
                    append(product.formattedPrice)
                    append(". ")
                    append(product.description.take(100))  // Truncate long descriptions
                }
                role = Role.Button
                onClick(label = "View details for ${product.name}") {
                    onClick()
                    true
                }
            },
        elevation = CardDefaults.cardElevation(defaultElevation = 2.dp)
    ) {
        // Card content
    }
}
Kotlin
// Loading states need explicit a11y announcements
@Composable
fun LoadingContent(modifier: Modifier = Modifier) {
    Box(
        modifier = modifier
            .fillMaxSize()
            .semantics { contentDescription = "Loading products, please wait" },
        contentAlignment = Alignment.Center
    ) {
        CircularProgressIndicator()
    }
}

If iOS Accessibility Is Required Today

For apps where full iOS VoiceOver compliance is non-negotiable right now, consider:

  1. Hybrid approach: Use CMP for Android + Desktop + Web, keep native SwiftUI for iOS
  2. UIKitView fallback: Implement accessibility-critical screens as UIKit views wrapped in UIKitView
  3. Wait for CMP 1.8+: JetBrains has prioritized iOS accessibility — the gap is closing

Performance: Real Numbers and Real Caveats

iOS Rendering Performance

Startup overhead: The Kotlin/Native runtime initialization time is the most cited performance concern. It is real and not fully eliminable, but it can be minimized:

  • Initialize the Kotlin runtime as early as possible in your Swift AppDelegate or @main struct, before any UI is shown
  • Use MainActor in Swift to ensure the CMP compositor is ready before the first frame

Memory Management on iOS

CMP’s memory behavior on iOS requires awareness of three interacting systems:

  • Kotlin/Native’s concurrent garbage collector (introduced in Kotlin 1.9.20) — significantly improved but still runs GC pauses under pressure
  • Swift’s ARC — automatic reference counting at the Swift/Kotlin boundary
  • Skia’s texture cache — GPU memory managed separately

For LazyColumn with image-heavy items:

Kotlin
// Register for iOS memory pressure notifications and clear image caches
// This should be done in your iosMain platform setup

class IosMemoryPressureHandler(
    private val imageLoader: ImageLoader  // Coil's ImageLoader
) {
    fun register() {
        NSNotificationCenter.defaultCenter.addObserverForName(
            name = UIApplicationDidReceiveMemoryWarningNotification,
            `object` = null,
            queue = NSOperationQueue.mainQueue
        ) { _ ->
            imageLoader.memoryCache?.clear()
            imageLoader.diskCache?.clear()
        }
    }
}

Recomposition Performance

Mark your data models @Immutable or @Stable to enable the Compose compiler to skip recomposition when inputs haven’t changed:

Kotlin
@Immutable  // Tells Compose: all properties are val and of stable types
data class ProductUiModel(
    val id: String,
    val name: String,
    val formattedPrice: String,
    val description: String,
    val imageUrl: String
)

// Without @Immutable, a data class with List<> properties will be inferred
// as unstable by the Compose compiler, causing full recomposition of every
// LazyColumn item on every parent recomposition - a major performance issue
@Immutable
data class CartUiState(
    val items: List<CartItemUiModel>,  // List<> requires @Immutable on the containing class
    val totalFormatted: String,
    val itemCount: Int
)

Enable Compose compiler metrics to verify your composables are stable:

Kotlin
// In your app's build.gradle.kts
composeCompiler {
    metricsDestination = layout.buildDirectory.dir("compose-metrics")
    reportsDestination = layout.buildDirectory.dir("compose-reports")
}

Run ./gradlew assembleRelease and inspect the generated reports for unstable markers.

Web (Wasm) Performance Reality

  • Initial Wasm binary: 5–20MB depending on features used
  • Execution speed once loaded: faster than equivalent JavaScript, competitive with native apps for logic-heavy operations
  • Rendering: <canvas>-based — no DOM, no browser text selection, no SEO crawling, no browser accessibility tree
  • Not suitable for: SEO-dependent content, server-side rendering, or apps requiring native browser accessibility
  • Suitable for: Internal tools, dashboards, B2B applications where load time and SEO are not primary concerns

Testing Strategy Across Platforms

Unit Testing (commonTest)

Kotlin
// core/domain/src/commonTest/ — Pure logic tests run on all platforms

class ProductListViewModelTest {
    private val testProducts = listOf(
        Product(id = "1", name = "Widget", price = 9.99, description = "A widget", imageUrl = ""),
        Product(id = "2", name = "Gadget", price = 19.99, description = "A gadget", imageUrl = "")
    )

    @Test
    fun `loadProducts emits Success state with mapped UI models`() = runTest {
        val fakeRepository = FakeProductRepository(products = testProducts)
        val useCase = GetProductsUseCaseImpl(fakeRepository)
        val viewModel = ProductListViewModel(useCase)
        val state = viewModel.uiState.value
        assertTrue(state is ProductListUiState.Success)
        assertEquals(2, (state as ProductListUiState.Success).products.size)
        assertEquals("$9.99", state.products[0].formattedPrice)
    }

    @Test
    fun `loadProducts emits Error state on network failure`() = runTest {
        val fakeRepository = FakeProductRepository(shouldFail = true)
        val useCase = GetProductsUseCaseImpl(fakeRepository)
        val viewModel = ProductListViewModel(useCase)
        val state = viewModel.uiState.value
        assertTrue(state is ProductListUiState.Error)
        assertTrue((state as ProductListUiState.Error).isRetryable)
    }
}

// Fake repository - not a mock, avoids Mockito (JVM-only)
class FakeProductRepository(
    private val products: List<Product> = emptyList(),
    private val shouldFail: Boolean = false
) : ProductRepository {
    override suspend fun getProducts(): Result<List<Product>> = if (shouldFail) {
        Result.failure(NetworkException("Network unavailable"))
    } else {
        Result.success(products)
    }
}

Do not use Mockito in commonTest — it is JVM-only. Use fakes (hand-written test doubles) or MockK’s multiplatform-compatible subset.

UI Testing

CMP UI tests use ComposeUiTest from compose-ui-test:

Kotlin
// composeApp/src/androidTest/ - Android UI tests
class ProductListScreenTest {
    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun productList_showsLoadingIndicator_whenStateIsLoading() {
        composeTestRule.setContent {
            ProductListScreen(
                uiState = ProductListUiState.Loading,
                onRetry = {},
                onSearchQueryChanged = {},
                onProductClick = {}
            )
        }

        composeTestRule.onNodeWithContentDescription("Loading products, please wait")
            .assertIsDisplayed()
    }

    @Test
    fun productList_showsProducts_whenStateIsSuccess() {
        val products = listOf(
            ProductUiModel("1", "Widget", "$9.99", "A widget", "")
        )

        composeTestRule.setContent {
            ProductListScreen(
                uiState = ProductListUiState.Success(products),
                onRetry = {},
                onSearchQueryChanged = {},
                onProductClick = {}
            )
        }

        composeTestRule.onNodeWithText("Widget").assertIsDisplayed()
        composeTestRule.onNodeWithText("$9.99").assertIsDisplayed()
    }
}

iOS UI testing: ComposeUiTest is not yet available for iOS. iOS UI testing for CMP apps is currently done through:

  • XCUITest (tests the iOS binary as a black box — works, but cannot inspect Compose semantics directly)
  • Screenshot testing via Paparazzi on Android + Roborazzi for cross-platform snapshot comparison
  • Manual testing with VoiceOver enabled

CI/CD Configuration

Kotlin
# .github/workflows/ci.yml
name: CI

on: [push, pull_request]
jobs:
  unit-tests:
    runs-on: macos-14  # macOS required for Kotlin/Native iOS compilation
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - name: Run common unit tests
        run: ./gradlew :core:domain:allTests
      - name: Run data layer tests
        run: ./gradlew :core:data:allTests
  android-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Android UI tests
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 33
          script: ./gradlew :composeApp:connectedAndroidTest
  ios-build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Build iOS framework
        run: ./gradlew :composeApp:linkDebugFrameworkIosSimulatorArm64
      - name: Build Xcode project
        run: |
          xcodebuild build \
            -project iosApp/iosApp.xcodeproj \
            -scheme iosApp \
            -destination 'platform=iOS Simulator,name=iPhone 15'

Observability and Crash Reporting

Crash Reporting

Sentry has the most mature KMP SDK with multiplatform crash reporting, breadcrumbs, and Kotlin/Native stack trace symbolication:

Kotlin
// composeApp/src/commonMain/ — Shared error reporting interface
interface ErrorReporter {
    fun captureException(throwable: Throwable, context: Map<String, String> = emptyMap())
    fun addBreadcrumb(category: String, message: String)
    fun setUser(userId: String)
}

// In your ViewModel base class:
abstract class BaseViewModel(
    protected val errorReporter: ErrorReporter
) : ViewModel() {
    protected fun launchWithErrorHandling(
        block: suspend CoroutineScope.() -> Unit
    ) = viewModelScope.launch {
        try {
            block()
        } catch (e: CancellationException) {
            throw e  // Never swallow CancellationException
        } catch (e: Exception) {
            errorReporter.captureException(e)
            handleError(e)
        }
    }
    protected open fun handleError(e: Exception) {}
}

Firebase Crashlytics does not have a native KMP SDK. You can integrate it via expect/actual where Android uses the Firebase SDK directly and iOS uses the Crashlytics iOS SDK called via Kotlin/Native interop — but setup is significantly more complex than Sentry.

Structured Logging

Kotlin
// commonMain — platform-agnostic logging interface
interface AppLogger {
    fun debug(tag: String, message: String)
    fun info(tag: String, message: String)
    fun warn(tag: String, message: String, throwable: Throwable? = null)
    fun error(tag: String, message: String, throwable: Throwable? = null)
}

// androidMain
class AndroidLogger : AppLogger {
    override fun debug(tag: String, message: String) = Log.d(tag, message)
    override fun error(tag: String, message: String, throwable: Throwable?) =
        Log.e(tag, message, throwable)
    // ...
}

// iosMain
class IosLogger : AppLogger {
    override fun debug(tag: String, message: String) {
        NSLog("DEBUG [$tag]: $message")
    }
    override fun error(tag: String, message: String, throwable: Throwable?) {
        NSLog("ERROR [$tag]: $message ${throwable?.message ?: ""}")
    }
    // ...
}

Common Pitfalls and Correct Patterns

Pitfall 1: Platform Imports in commonMain

Kotlin
// Will not compile — Android import in shared code
import android.content.Context

// Define an interface in commonMain, implement per platform
interface PlatformContext  // Marker interface or use Koin's module system

Pitfall 2: Using JVM-Only Libraries

Pitfall 3: Keyboard Insets on iOS

Kotlin
// Always use imePadding() for forms — handles iOS keyboard differently than Android
@Composable
fun FormScreen() {
    Column(
        modifier = Modifier
            .fillMaxSize()
            .imePadding()           // Pushes content above keyboard on both platforms
            .verticalScroll(rememberScrollState())
            .padding(16.dp)
    ) {
        // Form fields
    }
}

Note: On iOS, imePadding() behavior depends on the window configuration. Ensure your ComposeUIViewController is not configured with ignoresSafeArea(.keyboard) on the Swift side if you want CMP to handle keyboard insets. Choose one approach and apply it consistently.

Pitfall 4: Missing Coroutine Dispatcher Setup on iOS

Kotlin
// iosMain — MUST call this before any coroutine usage on iOS
// Without it, Dispatchers.Main may not be properly initialized

fun initCoroutines() {
    // This is handled automatically when using lifecycle-viewmodel on iOS,
    // but if you use coroutines outside of ViewModels, explicit initialization
    // may be required depending on your kotlinx-coroutines-core version
}

Ensure kotlinx-coroutines-core is in your iosMain dependencies (not just commonMain) to guarantee the Darwin dispatcher (iOS/macOS version of a Coroutine Dispatcher) is available.

Pitfall 5: Skipping Compose Compiler Metrics

Run the Compose compiler metrics on every release build and investigate any composables marked unstable. Unstable composables recompose unnecessarily, degrading performance silently.

Pitfall 6: Forgetting CancellationException

Kotlin
// Swallows coroutine cancellation — causes memory leaks and undefined behavior
try {
    val result = repository.getProducts()
} catch (e: Exception) {
    handleError(e)  // CancellationException caught here!
}

// Always rethrow CancellationException
try {
    val result = repository.getProducts()
} catch (e: CancellationException) {
    throw e  // Must propagate
} catch (e: Exception) {
    handleError(e)
}

Migration Strategy from Native to CMP

Realistic Migration Path

Do not do a big-bang rewrite. Migrate incrementally with feature flags and measurable milestones.

Phase 0 — Foundation (Weeks 1–4)

  • Set up multi-module project structure
  • Migrate data models to commonMain
  • Migrate network layer (Ktor), serialization (kotlinx.serialization), and database (SQLDelight) to KMP
  • Set up DI (Koin) with platform modules
  • Establish CI pipeline building for Android and iOS from day one
  • Measure and baseline: build times, app startup time, binary size, crash rate

Phase 1 — First CMP Screen (Weeks 5–8)

  • Choose a low-risk, low-traffic screen (Settings, About, or a simple list)
  • Implement it in commonMain with full tests
  • Ship behind a feature flag — A/B test CMP vs native version
  • Instrument: performance metrics, crash rate, accessibility reports
  • Collect iOS user feedback specifically

Phase 2 — Expand Coverage (Months 3–6)

  • Migrate screens in order of business risk (lowest risk first)
  • Each migrated screen: unit tests, UI screenshot tests, accessibility audit
  • Track shared code percentage per milestone
  • Platform-specific UI divergences: address immediately, do not defer

Phase 3 — Evaluate and Commit (Month 6+)

  • Measure actual shared code percentage (realistic target: 65–80%)
  • Assess: developer productivity change, bug rate change, iOS user retention change
  • Make a data-driven decision on full commitment vs hybrid approach

What to keep native (permanent exceptions):

  • ARKit / RealityKit scenes
  • Core ML on-device inference UI
  • Custom UIKit animations requiring frame-by-frame UIView manipulation
  • HealthKit / Watch OS integration screens

Production Readiness Checklist

Before shipping a CMP screen to production, verify:

Architecture

  • UiState is a single sealed class (no impossible states)
  • Composables receive state and callbacks — no ViewModel references
  • @Immutable applied to all UiModel data classes
  • All domain code in :core:domain with no platform imports
  • DI configured for all platforms

iOS

  • iOS lifecycle tested: background, foreground, memory warning
  • SharingStarted.WhileSubscribed used for all StateFlows
  • Back-swipe gesture tested on physical device
  • Font rendering reviewed on iOS (San Francisco vs Roboto differences)
  • imePadding() tested with all form screens on iPhone SE (smallest current screen)

Accessibility

  • All interactive elements have contentDescription or semantic roles
  • mergeDescendants = true applied to card-style components
  • TalkBack tested on Android (with CMP screen)
  • VoiceOver tested on iOS (acknowledge any known gaps)
  • Minimum touch target size: 48×48dp enforced

Performance

  • Compose compiler metrics reviewed — no unexpected unstable composables
  • LazyColumn scroll tested at 60fps on target minimum device specs
  • iOS startup time measured and within acceptable threshold
  • IPA size measured and within App Store guidelines

Testing

  • Unit tests in commonTest covering ViewModel state transitions
  • UI tests covering primary happy path and error state
  • Screenshot regression tests configured
  • CI builds both Android and iOS on every PR

Observability

  • Crash reporting integrated (Sentry recommended)
  • Structured logging in place
  • Performance metrics baseline captured

Who Is Using CMP in Production

JetBrains — Uses CMP in JetBrains Toolbox App and Fleet, with ongoing expansion.

Cash App (Block) — KMP used for shared business logic; CMP UI adoption in progress for select screens.

Touchlab — Consultancy with multiple enterprise deployments in healthcare, fintech, and retail; their public case studies are the most detailed available.

IceRock Development — Multiple production CMP deployments; maintains the moko suite of KMP/CMP libraries.

Yandex — Uses KMP for shared business logic in several products; CMP adoption expanding.

Recognized pattern across adopters: Teams that start with shared business logic via KMP report the lowest-risk path to CMP. Direct CMP adoption without prior KMP experience significantly increases migration risk.

Should Your Team Adopt CMP?

Adopt CMP if:

Your team writes Kotlin for Android and you maintain a parallel iOS codebase with feature parity requirements. The marginal cost of adopting CMP is very low; the long-term cost reduction is substantial.

You are starting a new project. The incremental cost of CMP vs Android-only is low, and you avoid the compounding technical debt of two separate UI codebases.

Your product serves non-accessibility-critical markets (B2B tools, internal apps, dashboards) where the iOS VoiceOver gap is manageable today.

You can invest in iOS-specific testing infrastructure from day one, not as an afterthought.

Proceed cautiously or defer if:

Your iOS app is in a regulated industry where WCAG 2.1 / ADA accessibility compliance is legally required. CMP’s iOS accessibility gaps are real and not fully controllable on your timeline.

Your app relies heavily on platform-specific animations, ARKit, Core ML on-device UI, or custom UIKit components that represent a significant portion of your UI surface.

Your team has no Kotlin experience. The KMP learning curve on top of CMP adoption simultaneously is a high-risk combination.

Your iOS app is a primary revenue driver and even a 200–300ms cold startup increase represents a measurable conversion loss at your scale — benchmark first.

The Right Default: Hybrid Approach

The most risk-managed production pattern today is:

  • Android: 100% CMP (builds on your existing Jetpack Compose investment)
  • iOS: CMP for data/logic-heavy screens; native SwiftUI for launch screen, onboarding, and accessibility-critical flows
  • Desktop: CMP if you need desktop support; low-cost add given Android CMP coverage
  • Web: CMP/Wasm for internal tools; native web (React/Vue) for consumer-facing, SEO-dependent products

This hybrid approach maximizes code reuse where CMP is strongest while using native where the gaps are most consequential.

Frequently Asked Questions

Q: Is Compose Multiplatform the same as Kotlin Multiplatform?

No. Kotlin Multiplatform (KMP) is the foundational technology for compiling Kotlin code to multiple targets and sharing business logic, data layers, and domain models across platforms. Compose Multiplatform (CMP) is built on top of KMP and specifically handles the declarative UI layer. You can use KMP without CMP (sharing logic while keeping native UI), but you cannot use CMP without KMP.

Q: Does CMP code run identically on all platforms?

No — and any resource that tells you it does is being imprecise. CMP code compiles and runs on all platforms, but font rendering, scroll physics, shadow appearance, gesture thresholds, and system behavior differ between Android and iOS because the rendering backends (Android’s hardware compositor vs Skia/Metal on iOS) operate differently. These differences require deliberate iOS testing and, in some cases, platform-specific composable implementations.

Q: How does CMP handle accessibility?

On Android, CMP’s accessibility support maps cleanly to Android’s Accessibility API — strong and production-ready. On iOS, CMP’s accessibility integration with UIAccessibility/VoiceOver has known gaps as of CMP 1.7.x. JetBrains is actively improving this. For iOS apps requiring full VoiceOver compliance today, a hybrid approach (native SwiftUI for accessibility-critical screens) is recommended.

Q: What is the realistic shared code percentage?

In production deployments, teams consistently achieve 65–80% shared UI code. The remaining 20–35% is platform-specific handling for: native view interop, platform lifecycle events, accessibility edge cases, and behaviors where native look-and-feel is non-negotiable. Claims of 90%+ shared code are technically possible for simple apps but are not representative of complex, production-quality applications.

Q: Does CMP support Material Design 3?

Yes. Material 3 (compose.material3) is fully supported in commonMain and renders on all platforms. The Material 3 component rendering on iOS is Skia-drawn (not native UIKit), which means it does not automatically adapt to iOS’s Human Interface Guidelines. If HIG compliance is required on iOS, you will need platform-specific theming via the expect/actual pattern or conditional logic using LocalPlatformInfo.

Q: How do I handle different screen sizes and form factors?

Use WindowSizeClass from compose-material3-adaptive, BoxWithConstraints, and responsive Modifier patterns — the same approach as Jetpack Compose on Android, applied in commonMain. These APIs are multiplatform-compatible.

Q: Is CMP free?

Yes. CMP is open-source under the Apache 2.0 license, free for commercial use. JetBrains monetizes through IntelliJ IDEA / Android Studio tooling and Kotlin-based services, not through CMP licensing.

Q: What is the binary size impact on iOS?

Adding CMP to an iOS app adds approximately 15–25MB uncompressed to the app bundle (including the Kotlin/Native runtime and Skia). After Apple’s App Thinning and compression, the incremental App Store download size increase is approximately 8–14MB. This is acceptable for most feature-rich applications; it may be a concern for lightweight utility apps competing on download size.

Conclusion

Compose Multiplatform is a production-viable framework for sharing UI code across Android, iOS, Desktop, and Web when adopted with clear eyes about its genuine tradeoffs.

Its real strengths: True Kotlin compilation (no bridges), zero retraining for Android Kotlin teams, first-class KMP integration, access to all native APIs via expect/actual and native view interop, and a strong trajectory backed by serious JetBrains investment.

Its real limitations today: iOS accessibility gaps requiring active management, startup overhead on iOS from Kotlin/Native runtime initialization, iOS debugging tooling significantly behind Android, and a Web/Wasm target still maturing toward production-grade use for consumer applications.

The teams shipping CMP successfully in production are not doing so because CMP eliminated all platform differences — they are doing so because they invested in proper architecture (Clean + MVI, typed state, state hoisting), iOS-specific testing, accessibility audits, and observability infrastructure. The framework enables code sharing; engineering discipline determines whether that sharing improves or degrades product quality.

Start with a well-scoped pilot. Measure relentlessly. Expand where the data supports it.

BoxWithConstraints in Jetpack Compose

Mastering BoxWithConstraints in Jetpack Compose: Build Truly Responsive UIs

Modern Android apps run on phones, tablets, foldables, Chromebooks, and even desktop environments. If your layout only looks good on one screen size, users will notice.

That’s where BoxWithConstraints in Jetpack Compose becomes powerful.

In this guide, you’ll learn what it is, when to use it, how it works internally, and how to build truly responsive layouts with practical examples. 

What Is BoxWithConstraints in Jetpack Compose?

BoxWithConstraints in Jetpack Compose is a layout composable that gives you access to the size constraints of its parent during composition.

It lets you know how much space is available so you can change your UI dynamically.

Instead of guessing screen size or using hardcoded breakpoints, you can read:

  • maxWidth
  • maxHeight
  • minWidth
  • minHeight

And build your layout accordingly.

Why It Matters for Responsive UI

Responsive design is no longer optional.

Your app may run on:

  • Compact phones
  • Large tablets
  • Foldables in multi-window mode
  • Desktop mode

If you rely only on Modifier.fillMaxWidth() or fixed sizes, your UI may stretch or break.

BoxWithConstraints in Jetpack Compose helps you:

  • Adapt layout based on width
  • Switch between column and row layouts
  • Show or hide content conditionally
  • Change typography and spacing dynamically

This is real responsiveness, not just resizing.

How BoxWithConstraints Works

Here’s the basic structure:

Kotlin
@Composable
fun ResponsiveExample() {
    BoxWithConstraints {
        if (maxWidth < 600.dp) {
            Text("Compact Screen")
        } else {
            Text("Large Screen")
        }
    }
}

Inside BoxWithConstraints, you can directly access maxWidth.

The important thing to understand:

  • The values are Dp
  • They represent the constraints passed from the parent
  • The composable recomposes if constraints change

So your UI reacts automatically.

Example 1: Switching Between Column and Row Layout

This is a common real-world case.

On small screens → stack items vertically
On large screens → place items side by side

Kotlin
@Composable
fun ProfileSection() {
    BoxWithConstraints(
        modifier = Modifier.fillMaxSize()
    ) {
        val isCompact = maxWidth < 600.dp

    if (isCompact) {
            Column(
                modifier = Modifier.padding(16.dp)
            ) {
                Avatar()
                Spacer(modifier = Modifier.height(16.dp))
                UserInfo()
            }
        } else {
            Row(
                modifier = Modifier.padding(24.dp)
            ) {
                Avatar()
                Spacer(modifier = Modifier.width(24.dp))
                UserInfo()
            }
        }
    }
}
  • We check if width is less than 600dp.
  • If true → vertical layout.
  • If false → horizontal layout.
  • Spacing is adjusted accordingly.

This approach is clean and easy to scale.

Example 2: Dynamic Card Grid

Let’s build a responsive grid without using a predefined grid layout.

Kotlin
@Composable
fun ResponsiveGrid() {
    BoxWithConstraints(
        modifier = Modifier.fillMaxWidth()
    ) {
        val columns = when {
            maxWidth < 600.dp -> 1
            maxWidth < 840.dp -> 2
            else -> 3
        }

    LazyVerticalGrid(
            columns = GridCells.Fixed(columns),
            contentPadding = PaddingValues(16.dp)
        ) {
            items(20) { index ->
                Card(
                    modifier = Modifier
                        .padding(8.dp)
                        .fillMaxWidth()
                ) {
                    Text(
                        text = "Item $index",
                        modifier = Modifier.padding(16.dp)
                    )
                }
            }
        }
    }
}
  • We calculate column count dynamically.
  • Grid adapts to available width.
  • No device-specific logic.
  • No hardcoded “tablet mode.”

This is flexible and future-proof.

Accessing Constraints in Pixels

Sometimes you need pixel-level calculations.

Inside BoxWithConstraints in Jetpack Compose, you can convert Dp to pixels:

Kotlin
@Composable
fun WidthInPixelsExample() {
    BoxWithConstraints {
        val widthInPx = with(LocalDensity.current) {
            maxWidth.toPx()
        }

        Text("Width in pixels: $widthInPx")
    }
}

Use this carefully. Most of the time, Dp is enough.

When Should You Use BoxWithConstraints?

Use it when:

  • Layout changes based on available width
  • You need responsive breakpoints
  • Parent constraints matter for child composition
  • You’re building adaptive layouts

Avoid using it:

  • For simple static UI
  • When Modifier constraints are enough
  • When you only need screen size (use LocalConfiguration instead)

Think of BoxWithConstraints in Jetpack Compose as a precision tool, not a default choice.

Common Mistakes Developers Make

1. Confusing Screen Size with Available Space

BoxWithConstraints gives you parent constraints, not the entire screen size.

In split-screen mode, constraints may be smaller than the device width.

This is good. It makes your UI adaptive.

2. Overusing Nested BoxWithConstraints

Nesting multiple constraint readers increases complexity and recomposition cost.

Keep it simple.

3. Hardcoding Too Many Breakpoints

Instead of:

Kotlin
maxWidth < 400.dp
maxWidth < 500.dp
maxWidth < 600.dp

Stick to meaningful layout breakpoints like:

  • Compact
  • Medium
  • Expanded

This keeps logic maintainable.

Performance Considerations

Is BoxWithConstraints in Jetpack Compose expensive?

Not really. But:

  • It introduces recomposition when constraints change.
  • Complex logic inside it can slow composition.

Best practice:

Keep heavy calculations outside or memoize using remember.

Example:

Kotlin
val isCompact = remember(maxWidth) {
    maxWidth < 600.dp
}

This ensures efficient re-composition.

Real-World Pattern: Adaptive Master-Detail Layout

Classic example:

Phone → single column
Tablet → list + details side by side

Kotlin
@Composable
fun MasterDetailLayout() {
    BoxWithConstraints(
        modifier = Modifier.fillMaxSize()
    ) {
        val isTablet = maxWidth >= 840.dp

         if (isTablet) {
            Row {
                Box(modifier = Modifier.weight(1f)) {
                    MasterList()
                }
                Box(modifier = Modifier.weight(2f)) {
                    DetailPane()
                }
            }
        } else {
            MasterList()
        }
    }
}

This pattern is widely used in email apps, dashboards, and productivity tools.

Box vs BoxWithConstraints

You might wonder:

Why not just use Box?

Here’s the difference:

If you don’t need constraint info, stick with Box.

How It Aligns with Modern Android Best Practices

Google encourages:

  • Adaptive layouts
  • Multi-device support
  • Foldable readiness

BoxWithConstraints in Jetpack Compose supports all of this naturally.

It works well alongside:

  • Window size classes
  • Material 3 adaptive design
  • Large screen guidelines

You’re building future-ready UI when you use it correctly.

Quick FAQ

What is BoxWithConstraints in Jetpack Compose?

It is a layout composable that exposes parent layout constraints like maxWidth and maxHeight, allowing dynamic and responsive UI decisions during composition.

When should I use BoxWithConstraints?

Use it when your layout must change depending on available space, such as switching from column to row or adjusting grid columns.

Does BoxWithConstraints affect performance?

It can trigger recomposition when constraints change, but it is generally efficient when used correctly.

Is BoxWithConstraints better than LocalConfiguration?

They serve different purposes.

  • LocalConfiguration gives device configuration.
  • BoxWithConstraints gives parent layout constraints.

Conclusion

Mastering BoxWithConstraints in Jetpack Compose changes how you think about UI design.

Instead of designing for fixed screens, you design for available space.

That shift makes your apps:

  • More adaptive
  • More professional
  • More future-proof

Start simple. Add breakpoints thoughtfully. Test in multi-window mode. Resize your emulator. Observe how your UI behaves.

Responsive design is not about bigger screens. It’s about flexible thinking.

And BoxWithConstraints in Jetpack Compose is one of your best tools to make that happen.

error: Content is protected !!