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...
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...
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.
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:
Use AnimatedContent when:
@Composable
fun SimpleAnimatedContentExample(count: Int) {
AnimatedContent(targetState = count) { targetCount ->
Text(
text = "Count: $targetCount",
fontSize = 24.sp
)
}
}targetState = count → tells Compose what state to watchcount changes → animation is triggeredtargetCount → the new value inside the animation blockThis is the core idea of AnimatedContent.
Let’s build a simple counter with animation.
@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:
No extra animation code needed.
By default, animations are nice but basic. You can customize them using transitionSpec.
@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()
}
}
Inside transitionSpec, you define:
You combine them using:
enterAnimation togetherWith exitAnimationYou can change animation depending on state.
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)
}This small detail makes your UI feel intelligent.
You can use AnimatedContent to switch UI states like this:
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()
}
}
Instead of hard switching screens:
If your targetState changes too frequently or unpredictably, animations may feel glitchy.
Tip: Use proper state management (remember, ViewModel).
Too many animations can overwhelm users.
Keep it simple:
If your composable is too complex, animation may lag.
Solution:
remember wiselyYou can use AnimatedContent for:
Good animation:
AnimatedContent does this automatically, which saves time and improves quality.
Mastering AnimatedContent is less about memorizing APIs and more about understanding when and why to animate.
Start small:
Over time, you’ll naturally build smoother, more polished apps.
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...
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.
Spring animations simulate real physics, Instead of moving linearly from point A to point B, they behave like a spring:
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.
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:
Different types need different thresholds because “closeness” depends on the unit.
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:
spring<Float>(
dampingRatio = Spring.DampingRatioNoBouncy,
stiffness = Spring.StiffnessMediumLow,
visibilityThreshold = 0.01f
)Stops when difference < 0.01
Why this matters:
spring(
dampingRatio = Spring.DampingRatioMediumBouncy,
stiffness = Spring.StiffnessHigh,
visibilityThreshold = Offset(1f, 1f)
)Stops when both X and Y are within 1 pixel
Why:
Dp)@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:
Float)@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:
Offset)@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:
visibilityThreshold is Important Without it:
With it:
Tiny sub-pixel movements can cause:
Threshold eliminates those artifacts.
Users don’t perceive microscopic differences.
Ending animations early:
Here’s a practical guideline:
Avoid:
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
visibilityThreshold is easy to overlook, but it has a noticeable impact on how polished your animations feel.
A small tweak here can:
It’s one of those details that separates a working UI from a well-crafted one.
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...
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.
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:
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.
Before writing any animations, it helps to understand the main APIs you’ll actually use:
animate*AsStateFor simple, one-off animations tied to a single value.
updateTransitionFor animating multiple values based on the same state.
AnimatedVisibilityFor showing and hiding composables with animation.
AnimatedContentFor switching between UI states.
rememberInfiniteTransitionFor looping animations.
You don’t need all of them at once. Most real screens use 1–2 of these consistently.
Once you lean into this approach, a few things improve right away:
This becomes especially useful when multiple properties change together. You don’t coordinate them manually. You just describe the end result.
Let’s build something practical: a card that expands when clicked.
@Composable
fun ExpandableCard() {
var expanded by remember { mutableStateOf(false) }This is the trigger. Everything depends on this boolean.
val height by animateDpAsState(
targetValue = if (expanded) 200.dp else 100.dp,
label = "cardHeight"
)What’s happening here:
targetValue changes when expanded changesheight) updates continuously during animationYou don’t write animation logic. You describe the end state.
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.
@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()
}
}
The default animation works, but real apps need control.
val height by animateDpAsState(
targetValue = if (expanded) 200.dp else 100.dp,
animationSpec = tween(
durationMillis = 500,
easing = FastOutSlowInEasing
),
label = "cardHeight"
)Now you control:
animationSpec = spring(
dampingRatio = Spring.DampingRatioMediumBouncy,
stiffness = Spring.StiffnessLow
)Spring animations feel more natural for things like cards or draggable UI.
This is where updateTransition becomes useful.
Let’s animate both height and color based on the same state.
val transition = updateTransition(
targetState = expanded,
label = "cardTransition"
)val height by transition.animateDp(
label = "height"
) { state ->
if (state) 200.dp else 100.dp
}val backgroundColor by transition.animateColor(
label = "color"
) { state ->
if (state) Color.Blue else Color.Gray
}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.
For visibility changes, don’t animate alpha manually. Use AnimatedVisibility.
AnimatedVisibility(visible = expanded) {
Text(
text = "Extra details shown here",
modifier = Modifier.padding(16.dp)
)
}By default, it fades and expands. You can customize it:
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.
For replacing content, use AnimatedContent.
AnimatedContent(targetState = expanded, label = "content") { state ->
if (state) {
Text("Expanded View")
} else {
Text("Collapsed View")
}
}This automatically animates between the two layouts.
For loaders or subtle UI effects:
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:
Box(
modifier = Modifier
.size(100.dp)
.scale(scale)
.background(Color.Blue)
)Good for:
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:
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.
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...
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...
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...