How it works
A Compose screen is made of composable functions, Kotlin functions marked @Composable that emit interface elements such as Text, Button and LazyColumn (a scrolling list). They read state, and when that state changes Compose re-runs only the affected functions, a process called recomposition. There are no XML layout files and no manual view updates, which removes a whole class of bugs where the screen and the data drift apart.
Google recommends Compose for new Android apps. It replaces the older View system (XML layouts), although the two can live side by side in one app. Material 3 components, animation, navigation and Android Studio previews are built around it. The same model runs on Wear OS and Android TV, and JetBrains' Compose Multiplatform brings it to iOS, desktop and the web.
Jetpack Compose pros and cons
Pros
- Less code than XML layouts, all in Kotlin
- State-driven, so the screen always matches the data
- Live and interactive previews in Android Studio
- Works alongside existing View-based screens, so migration can be gradual
- Shares its model with Compose Multiplatform for iOS and desktop
Cons
- Recomposition and state rules take time to understand
- Careless state handling can make screens slow or janky
- Android-only unless you adopt Compose Multiplatform
When to use Jetpack Compose
Pick it when
- Any new native Android app
- Modernising an existing app screen by screen
- Android teams that may later share UI with iOS through Compose Multiplatform
Skip it when
- One shared codebase for both platforms matters most and the team knows Dart or JavaScript
Jetpack Compose pricing
Jetpack Compose vs the alternatives
Related terms
More in Mobile apps
Native Android