Kotlin

Android

Jetpack Compose

AndroidDev

Coding

The “Invisible Performance Killer”: A Deep Dive into Jetpack Compose Stability

From “Why Is My App Lagging?” to “Flash Speed!”, Mastering Compose Recomposition

Image generated with ChatGPT by Ahmed Nabil

Salam, fellow Android warriors!

Picture this: It’s 2 AM. Your feature is “done.” The QA team has signed off. You’re about to merge your PR with the confidence of a developer who just discovered remember {}. Then your tech lead drops a bomb in the code review:

“Why is UserProfileScreen recomposing 47 times per scroll?"

Forty. Seven. Times.

And just like that, your Week-end night plans evaporated faster than your app’s frame rate.

Welcome to Episode 1 of what I call “The Stability Saga”, where we’ll journey from the chaos of unstable composables to the zen-like peace of a perfectly optimized UI. Grab your coffee (or tea, I don’t judge), and let’s dive into the belly of the beast.

The Crime Scene: Understanding What Actually Happens

Before we solve the mystery, let’s understand the murder weapon: Recomposition.

Here’s the uncomfortable truth that most tutorials skip: Recomposition is NOT the enemy. Unnecessary recomposition is.

// The Innocent-Looking Suspect
@Composable
fun UserCard(user: User) {
    Card(modifier = Modifier.padding(16.dp)) {
        Column {
            Text(text = user.name)
            Text(text = user.email)
            ProfileStats(stats = user.stats) // The hidden villain
        }
    }
}

data class User(
    val name: String,
    val email: String,
    val stats: UserStats // Unstable! But why?
)

data class UserStats(
    val followers: Int,
    val posts: Int,
    val lastActive: Date // HERE! java.util.Date is the culprit
)

See that innocent Date field? It's the equivalent of inviting a chaos agent to your perfectly organized party. The Compose compiler looks at UserStats and thinks:

“Hmm, this Date class... I don't trust it. It could mutate at any moment. Better recompose every time, just to be safe."

And boom, your UI is now doing more work than your entire backend team on a Monday morning.

The Autopsy: How the Compose Compiler Thinks

Let’s get our hands dirty with some compiler internals. When you build your app, the Compose compiler does something fascinating , it analyzes every single parameter and assigns a stability verdict.

The Three Verdicts:

Here’s how to check your composables’ stability status. Add this to your build.gradle.kts:

// Module-level build.gradle.kts
composeCompiler {
    reportsDestination = layout.buildDirectory.dir("compose_reports")
    metricsDestination = layout.buildDirectory.dir("compose_metrics")
}

Run your build, then open <module>-composables.txt. What you'll find might haunt your dreams:

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun UserCard(
  stable user: User
)
// vs the nightmare version:
restartable scheme("[androidx.compose.ui.UiComposable]") fun UserCard(
  unstable user: User  // No "skippable" = recomposes EVERY. SINGLE. TIME.
)

Notice the missing skippable? That's the compiler saying: "I literally cannot skip this composable even if the inputs look identical."

The Fix: Three Levels of Enlightenment

Level 1: The Quick Win, Immutable Collections

Remember our UserStats with the evil Date? Here's fix number one:

// Before: Unstable chaos
data class UserStats(
    val followers: Int,
    val posts: Int,
    val lastActive: Date // java.util.Date = unstable
)
// After: Stability achieved
data class UserStats(
    val followers: Int,
    val posts: Int,
    val lastActive: Instant // java.time.Instant = stable!
)

But wait, there’s more! What if you’re dealing with collections?

// UNSTABLE - List is a Kotlin interface, could be mutable underneath
data class Feed(
    val posts: List<Post>
)
// STABLE - ImmutableList from kotlinx.collections.immutable
data class Feed(
    val posts: ImmutableList<Post>
)

Add the dependency:

implementation("org.jetbrains.kotlinx:kotlinx-collections-immutable:0.4.0")

Level 2: The Surgical Strike, @Stable and @Immutable

Sometimes you know better than the compiler. You’re the human. Assert dominance:

@Immutable // "Trust me, compiler. This. Won't. Change."
data class UserStats(
    val followers: Int,
    val posts: Int,
    val lastActiveTimestamp: Long // Using Long instead of Date
)

But wield this power responsibly! If you lie to the compiler with @Immutable on a class that actually mutates, you'll get bugs so subtle they'll make you question your career choices.

Level 3: The Master Move, Stability Configuration File

For 2026 and beyond, the Compose team blessed us with the stability configuration file. Create compose_stability.conf in your module:

// compose_stability.conf
// Mark all classes in this package as stable
com.myapp.models.*
// Mark specific external classes as stable
java.time.Instant
java.time.LocalDateTime
java.util.UUID

Then reference it in your build config:

composeCompiler {
    stabilityConfigurationFile = file("compose_stability.conf")
}

This is like giving the compiler a cheat sheet: “Hey, trust these classes. I vouch for them.”

The Real-World Impact: Numbers Don’t Lie

I ran benchmarks on a production-like screen with 50 items in a LazyColumn. The results?

That’s a 92% reduction in unnecessary recompositions. Your users won’t see the code, but they’ll feel the difference.

The Debugging Toolkit: Your New Best Friends

1. Layout Inspector on Steroids

In Android Studio, go to View > Tool Windows > Layout Inspector. Enable "Show Recomposition Counts" and watch the numbers climb in real-time. It's like a fitness tracker, but for your composables' anxiety levels.

2. The remember + derivedStateOf Combo

@Composable
fun SearchResults(query: String, allItems: List<Item>) {
    // Without optimization: filters on EVERY recomposition
    val filtered = allItems.filter { it.name.contains(query) }
    
    // With optimization: only recalculates when dependencies change
    val filtered by remember(query, allItems) {
        derivedStateOf { allItems.filter { it.name.contains(query) } }
    }
    
    LazyColumn {
        items(filtered) { item ->
            ItemCard(item)
        }
    }
}

3. The Nuclear Option: Strong Skipping Mode

In Compose Compiler 2.0+, enable strong skipping:

composeCompiler {
    enableStrongSkippingMode = true
}

This makes the compiler more aggressive about skipping recomposition, even for unstable parameters, by comparing them structurally. It’s experimental but increasingly stable (pun intended) in 2026.

The Checklist: Before You Ship

Here’s your pre-merge checklist, straight from the trenches:

• Run compose metrics report — no surprises
• All domain models use @Immutable or @Stable appropriately
• Collections are from kotlinx-collections-immutable
• No java.util.Date anywhere near Compose
• derivedStateOf for expensive computations
• Layout Inspector shows reasonable recomposition counts
• Scrolling is 60 FPS smooth

The Conclusion: From Chaos to Control

We’ve traveled from the depths of “why is everything recomposing” despair to the heights of Compose stability enlightenment. The key takeaways?

The next time someone asks why your app scrolls like butter while theirs stutters like a nervous intern during their first code review, just smile and say:

“I understand the Compose compiler. We’re friends now.”

What’s Next?

In the next episode, we’ll dive into “The Modifier.Node Revolution” — how to squeeze even more performance out of your custom modifiers using the new Modifier.Node API. We’ll build a custom ripple effect that’s 10x more efficient than the default implementation.

Until then, may your recompositions be minimal and your frame rates high.

Ahmed

Tags: #AndroidDev #JetpackCompose #Performance #Kotlin #DeepDive

Connect: Follow me for more Android deep dives. Drop a comment if you found this useful, or your app is now running smoother, I live for those success stories!

This article is part of the “Compose Performance Saga” series. Check out the other episodes for more deep dives into Android optimization.