Compose is no longer an emerging technology. It is the Android UI default. Here is what we have learned shipping it.
Google made Jetpack Compose Android's recommended UI toolkit in 2021. Three years and dozens of production apps later, the toolkit has matured. The stories about flaky animations and missing APIs from the early days are largely yesterday's problems.
What Compose got right
Declarative UI with first-class state management. Material 3 components built in. Strong tooling — preview, layout inspector, recomposition counts — all in Android Studio. Theming, accessibility, and dark mode that "just work" if you stay on the rails.
The patterns that stick
- Single-activity, multi-screen with NavHost. Fragments are dead for new apps.
- State hoisted to ViewModel with
StateFloworMutableState; UI only renders. - Stateless composables wherever possible — easier to preview, easier to test.
- Strongly typed navigation with the type-safe Navigation Compose API (3.0+).
The pain points
Recomposition is sometimes too eager — @Stable, @Immutable, and derivedStateOf exist for a reason and you will need all three. Performance optimization on lists requires key parameters and lazy column tuning. Interop with legacy XML views works but is friction-heavy in mixed codebases.
What we still recommend XML for
Existing XML codebases under active development. Migrating screen by screen is fine; rewriting the entire UI in one push is rarely worth the engineering opportunity cost. For greenfield apps in 2026, default to Compose.
Performance benchmark
On a Pixel 6, our standard Compose app cold-starts in under 1.2 seconds and maintains 60fps scrolling on a 100-item LazyColumn with images. The same app in XML did not measurably outperform Compose on any metric we cared about.