blog / compose · architecture

Jetpack Compose vs XML: Which to Use for a New App

5 November 2026 · 9 min read · AppMama

For a new Android app in 2026, use Jetpack Compose. That is Google’s recommendation, it is where new Jetpack and Material work lands first, and it removes a whole class of bugs that come from keeping XML layouts and Kotlin state in sync. XML views still matter, though: almost every large app has some, and a few things still have no Compose-native version. This guide covers the Jetpack Compose vs XML decision honestly: where each wins, how the two interoperate, what performance really looks like, and how to migrate an existing app without stopping feature work.

The short answer: Compose vs XML for a new app

Start a new app in Compose unless one of these is true:

• Your team has deep View expertise, a shared custom View library, and a deadline that leaves no room to learn a new mental model.
• The core of the app is a heavy third-party View SDK (a map, a video player, a document renderer) with no Compose wrapper, and the rest of the UI is thin.
• You must support a platform surface that does not run Compose directly. Home screen widgets are the main one, and even there Jetpack Glance gives you a Compose-style API that produces RemoteViews.

Even in those cases the answer is usually “Compose, with a few AndroidView islands”, not “all XML”. Views are not deprecated and will keep working for years, but new UI APIs, samples and Material 3 Expressive components arrive in Compose first, and some arrive only there.

What is the difference between Compose and XML views?

With XML, you describe a tree of View objects in a layout file, inflate it, then mutate those objects from Kotlin as state changes: textView.text = ..., button.isEnabled = ..., adapter.notifyItemChanged(...). The UI is a long-lived object graph and your code is responsible for keeping it consistent with your data.

With Compose, UI is a Kotlin function of state. You describe what the screen should look like for the current state, and when that state changes the runtime re-runs (recomposes) only the functions that read it.

CartRow.kt

@Composable
fun CartRow(item: CartItem, onRemove: () -> Unit) {
    Row(verticalAlignment = Alignment.CenterVertically) {
        Text(item.name, modifier = Modifier.weight(1f))
        Text("x${item.quantity}")
        IconButton(onClick = onRemove, enabled = item.quantity > 0) {
            Icon(Icons.Default.Delete, contentDescription = "Remove")
        }
    }
}

There is no “find the view, then update it” step, so there is no way for the enabled state of the button to drift away from item.quantity. That one property, UI that cannot get out of sync with state, is most of the practical benefit.

Jetpack Compose vs XML at a glance

Is Jetpack Compose slower than XML?

Steady-state, a well-written Compose screen performs on par with an equivalent View screen, and complex lists are often easier to make fast in Compose because there is no adapter boilerplate to get wrong. The real differences are narrower than the internet suggests:

• Startup and first frame. The View system ships inside the OS and is already ahead-of-time compiled. Compose is a library bundled in your APK, so without help its code is interpreted and JIT-compiled the first times it runs. Baseline Profiles fix most of this; Compose libraries ship their own, and you should generate one for your app’s critical journeys.
• Debug builds lie. Debug builds are not optimized by R8 and run with extra checks. Never judge Compose performance from a debug build; measure a release build, ideally with Macrobenchmark.
• Unnecessary recomposition. The common real-world slowdown is reading fast-changing state (scroll position, animation values) too high in the tree. Read it as late as possible, use lambda-based modifiers such as Modifier.offset { ... }, and use derivedStateOf when you only care about a threshold.
• Stability is less of a trap than it used to be. Since Kotlin 2.0.20, the Compose compiler’s strong skipping mode is on by default, so composables with unstable parameters can still be skipped. You rarely need to sprinkle @Stable everywhere.

APK size goes up a little when you add Compose, and goes back down as you delete XML layouts, adapters and View-based libraries. With R8 enabled, it is rarely a deciding factor; see how to reduce Android app size if it is for you.

How do I set up Compose in a new project?

Since Kotlin 2.0, the Compose compiler ships with Kotlin as a Gradle plugin, so its version always matches your Kotlin version. Library versions come from the Compose BOM.

app/build.gradle.kts

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.plugin.compose")
}

android {
    buildFeatures {
        compose = true
    }
}

dependencies {
    // Check developer.android.com/develop/ui/compose/bom for the latest BOM
    val composeBom = platform("androidx.compose:compose-bom:2026.09.00")
    implementation(composeBom)
    androidTestImplementation(composeBom)

    implementation("androidx.compose.material3:material3")
    implementation("androidx.compose.ui:ui-tooling-preview")
    debugImplementation("androidx.compose.ui:ui-tooling")
    implementation("androidx.activity:activity-compose:1.13.0")

    androidTestImplementation("androidx.compose.ui:ui-test-junit4")
    debugImplementation("androidx.compose.ui:ui-test-manifest")
}

The versions above are current as of November 2026; check the BOM mapping page for the latest, and declare them in a version catalog rather than inline. The plugins block assumes AGP 9, which has Kotlin support built in; on older AGP versions also apply org.jetbrains.kotlin.android. Recent Compose releases also require a recent compileSdk and Android Gradle Plugin, which is the most common reason a BOM bump fails to build.

How do Compose and XML views work together?

Interop works in both directions and is production-grade. This is what makes gradual migration possible.

Compose inside an XML layout: ComposeView

ComposeView is an ordinary View, so it can go anywhere in an XML layout:

res/layout/fragment_profile.xml

<androidx.compose.ui.platform.ComposeView
    android:id="@+id/compose_view"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

In a Fragment, set a composition strategy tied to the Fragment’s view lifecycle before calling setContent:

ProfileFragment.kt

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    binding.composeView.apply {
        setViewCompositionStrategy(
            ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
        )
        setContent {
            AppTheme {
                ProfileHeader(viewModel)
            }
        }
    }
}

The default strategy, DisposeOnDetachedFromWindowOrReleasedFromPool, disposes the composition when the view detaches from the window (and handles RecyclerView pooling). In Fragments the view can detach and reattach, for example on the back stack, so the default can throw away state you expected to keep. If you have more than one ComposeView in a layout, give each a unique ID or saved state will not restore correctly.

XML views inside Compose: AndroidView

Use AndroidView for a View with no Compose equivalent, such as a WebView, an ad view or a custom chart from an old library. Create the View in factory and push state into it in update, which re-runs whenever the state it reads changes:

@Composable
fun LegacyChart(points: List<Float>, modifier: Modifier = Modifier) {
    AndroidView(
        modifier = modifier,
        factory = { context -> SparklineView(context) },
        update = { view -> view.setPoints(points) }
    )
}

Inside a LazyColumn, pass an onReset callback too; it opts the View into reuse, the same way RecyclerView recycles ViewHolders. To embed a whole existing XML layout, AndroidViewBinding from androidx.compose.ui:ui-viewbinding inflates a view binding class. To embed a Fragment during migration, AndroidFragment from androidx.fragment:fragment-compose does it with the right lifecycle handling.

One theme, two systems

The XML theme (themes.xml) and the Compose MaterialTheme are separate. A ComposeView does not inherit your XML colors, and an AndroidView does not see MaterialTheme. In a mixed app, define your colors once as resources or Kotlin constants and feed both. Even a pure Compose app still needs a minimal XML theme for the window background and splash screen. The Material 3 theming guide covers the Compose side in depth.

How do I migrate an existing XML app to Compose?

Do not rewrite. Migrate incrementally, and let the boundary move as you touch code anyway.

1. Write all new screens in Compose. Host them in a Fragment with a ComposeView if your navigation is still Fragment-based. This stops the XML codebase from growing.
2. Build shared components first. Recreate your design system (buttons, text fields, cards, empty states) as composables with your theme. Every later screen gets faster to build.
3. Convert leaf UI next. Replace small pieces inside existing XML screens, such as a header, a list row or a dialog, with ComposeViews. Low risk, quick wins, and the team learns on real code.
4. Move state into ViewModels with StateFlow. Screens that already expose a single UI state object convert easily; screens that poke Views from ten callbacks do not. Fix the architecture before the UI (see modern Android app architecture).
5. Convert whole screens, then navigation. Once most screens are composables, move to Compose navigation in a single Activity and delete the Fragments.

Expect the awkward phase to be lists and complex custom Views. A RecyclerView with many view types usually maps to a LazyColumn with a when over item types, which is simpler, but do it as a dedicated change with screenshot tests in place.

When is XML still the better choice?

• A mature View codebase that works. If a screen is stable and rarely changes, converting it costs time and adds risk for little gain. Leave it.
• Heavy custom View code with precise drawing and touch handling. It can all be done in Compose with Canvas and pointer input, but a rewrite of a battle-tested custom View is rarely the best use of a sprint.
• View-only SDKs at the centre of the app. Check first, though: many popular SDKs now ship official Compose libraries.
• App widgets. Widgets render via RemoteViews. You can write them in XML or with Glance; Glance is Compose-like but not full Compose, so not every composable is available.

Things that are no longer good reasons: “Compose is not stable” (it has been stable since 2021), “there is no ConstraintLayout” (there is, but Row/Column/Box cover most layouts without it), and “Compose cannot do edge-to-edge” (it handles window insets well, arguably better than Views).

What is the learning curve like?

For developers coming from Views, the syntax takes a day and the mental model takes a few weeks. The concepts that trip people up are:

• State ownership. Use remember for UI-only state, hoist anything shared to the caller or a ViewModel, and pass events up as lambdas.
• Side effects. Composables can run many times, so work like starting a network call goes in LaunchedEffect or the ViewModel, never directly in the function body.
• Modifier order. Modifier.padding(16.dp).background(c) and Modifier.background(c).padding(16.dp) produce different results. Modifiers apply outside-in, in order.
• Lists need keys. Pass key = { it.id } to items() so state and animations follow the item, not the position.

Once those click, most teams report building screens noticeably faster than with XML, mainly because previews, theming and lists need so much less ceremony.

Frequently asked questions