Omisión, @Stable y @Immutable

Sometimes a type is truly safe but Compose cannot prove it. Annotations let you promise stability so skipping kicks back in.

@Immutable tells Compose that once an instance is built, none of its properties will ever change. It is the strongest stability guarantee.

Reach for @Immutable on config-like data: themes, styles, and value objects you create once and never mutate after construction.

@Stable is gentler: properties may change, but when they do, Compose will be notified through Compose state. equals() must stay consistent.

Use @Stable on classes whose mutable fields are backed by mutableStateOf, so Compose still tracks every change correctly.

These annotations are a contract. If you mark a type stable but mutate it silently, the UI shows stale data and bugs creep in.

Instead of List, pass ImmutableList from kotlinx.collections.immutable. Compose treats it as stable, so list Composables can skip.

Lambda parameters are stable already, but remember a lambda capturing changing values is a new instance each recomposition.

One annotation on the class covers every use of that type as a parameter. You do not annotate at each call site.

Prefer real immutability with val first. Only annotate when the compiler genuinely cannot infer stability on its own.

After annotating, check that the Composable actually skips. A wrong promise is worse than no promise at all.

Pick the right annotation.

Use @Immutable for never-changing data and @Stable for state-backed mutables. Honor the contract or the UI lies. ✅