Why are data classes from my library module treated as unstable by the Compose compiler?

Answer to the Core Question

The Compose compiler only treats a type as stable if it is defined in the same Gradle module that is compiling the composables, or if the type is explicitly annotated with @Stable or @Immutable. Data classes that live in a separate module (e.g. :core:model) are therefore inferred as unstable by default, even if they contain only immutable val properties. There is no official stability‑configuration file that can be added to a library module to change this behaviour without adding a Compose dependency.

Why the Inference Is Module‑Local

• Compose’s stability algorithm is intentionally conservative to avoid accidental recomposition of mutable state that a consumer might not notice.
• It relies on the compiler’s visibility of type annotations; external modules cannot be inspected for Compose‑specific annotations unless they depend on the Compose artifact.
• Because the library module has no Compose dependency, the compiler has no way to see @Stable or @Immutable on its classes, so they default to unstable.

Supported Ways to Declare External Types as Stable

1. Add Compose Annotations to the Library

When the library can depend on androidx.compose.runtime:runtime, add @Stable (or @Immutable if the class is truly immutable) to the data class. The compiler will then treat the type as stable across modules.

2. Wrap the Library Type in a Stable Wrapper in the Feature Module

• Create a small wrapper data class in the consuming module:

data class UserUiModel(val user: com.example.model.User) @Stable

• Expose only the wrapper to composables. The wrapper is stable because it is defined in the same module and annotated.
• This adds negligible runtime overhead – the wrapper simply forwards property access to the underlying model.

3. No Other Official Mechanism Exists

There is no stability configuration file or plugin that can declare external types as stable without adding Compose annotations or a wrapper. This behaviour is documented in the Compose compiler release notes and is expected to remain consistent across future releases.

Practical Impact of Wrapping vs. Annotating

• Runtime cost: The wrapper adds only a single reference indirection; no additional allocations or GC pressure.
• Maintenance: If the underlying model changes (new properties, mutability), update the wrapper or re‑annotate the library. The wrapper keeps the Compose‑specific change isolated to the consuming module.
• Recomposition: Once the wrapper is annotated, Compose will treat it as stable, eliminating unnecessary recompositions for composables that only read the model.

Next Diagnostic Step

To ensure the chosen solution works, confirm that the library module is compiled with the same Kotlin version (1.9) as the app. Mismatched Kotlin versions can affect stability inference. If you can add a Compose runtime dependency to the library, try annotating the data class directly; otherwise, implement the wrapper in the feature module.

Summary

Compose treats cross‑module data classes as unstable unless they are annotated or wrapped. The only supported ways are to add @Stable/@Immutable in the library (requiring a Compose dependency) or to create a stable wrapper in the consuming module. Neither approach introduces meaningful runtime overhead, and the wrapper keeps Compose concerns isolated from the domain layer.