Jetpack Compose Compiler Report Reveals Stability Misclassification in Complex UI Trees

Stability System and Parameter Classification in Jetpack Compose

Jetpack Compose's stability system determines whether a Composable can skip recomposition by analyzing parameter stability. Parameters marked as unstable always trigger recomposition of the parent Composable, even when the underlying data hasn't meaningfully changed. This becomes problematic in complex UI trees where multiple nested composables receive parameters from external libraries or classes containing var properties.

The compiler treats classes from external libraries or those with mutable state as unstable by default because it cannot guarantee immutability or proper change notification. While @Stable and @Immutable annotations allow manual marking, misapplication can introduce UI bugs if the stability contract isn't genuinely followed. Additionally, standard Kotlin List and Map interfaces result in instability since they don't guarantee immutability, requiring Kotlinx collections instead.

The Compose compiler report is the primary diagnostic tool for identifying non-skippable composables and their unstable parameters, enabled through Gradle build configuration. However, the report alone doesn't indicate whether the instability classification is correct or if manual annotations would be appropriate.

Questions

• At what point should developers trust the compiler's default stability classification versus manually annotating classes with @Stable or @Immutable?
• How can teams establish consistent guidelines for when to apply stability annotations across a large codebase without introducing stale UI bugs?
• What automated verification approaches exist to ensure stability annotations remain correct as code evolves?