Compose-first Migration

This topic focuses on migrating Android applications toward a Compose-first architecture.

Jetpack Compose has moved from “new UI framework” to the default path for new Android UI work. This page is for teams dealing with questions such as how to migrate from XML, why Compose screens become janky, and what a Compose-first architecture should mean in an existing app.

The goal is not a rewrite for its own sake. The goal is a controlled path toward simpler UI architecture, clearer state ownership, and better testability.

Who This Is For

• Teams with existing View/XML screens that need to migrate module by module.
• Developers debugging frequent recomposition, LazyColumn frame drops, or poorly scoped state reads.
• Apps that must maintain both Compose and View code while handling AndroidView, ComposeView, lifecycle, and scroll conflicts.
• Teams exploring Compose for Wear OS, Glance AppWidget, large screens, foldables, or multi-platform UI.

Migration Route

1. Start with low-risk screens. Do not begin by rewriting the most critical transaction flow.
2. Use View/Compose interoperability to connect existing screens while defining lifecycle, state hoisting, and event boundaries.
3. Trace recomposition on high-frequency lists and complex state screens. Pay close attention to stability, derivedStateOf, and where state is read.
4. Add Compose UI tests, screenshot tests, and CI regression checks so migration quality does not depend on manual acceptance.
5. Treat AppWidget, Wear OS, large screens, and foldables as separate adaptation tracks.

Core Reading

• Jetpack Compose engineering notes
• Why does Compose recompose so often? Stability and state-read scope
• Jetpack Compose recomposition performance: stability, derivedStateOf, and skip behavior
• Compose LazyColumn scroll performance: from recomposition tracing to frame-rate stability
• Compose and View interoperability: AndroidView, ComposeView, and two-way communication
• Progressive Android Compose migration: from mixed View/Compose screens to full declarative UI

Performance Checklist

• Recomposition: parameter stability, remember scope, and state-read location.
• Lists: stable keys, contentType, item composition granularity, and image loading.
• Layout and drawing: Modifier order, custom Layout, Canvas drawing, and unnecessary remeasurement.
• Input and gestures: pointerInput, nested scroll, and touch-target boundaries.
• Test stability: Compose test dispatching, asynchronous state, and screenshot baselines.

Related Topics

• Kotlin and Coroutines: Compose state streams and side effects often depend on Flow, StateFlow, and structured concurrency.
• Android Performance: If the issue reaches startup, rendering, memory, or traces, use system-level performance methods.
• Mobile Engineering: Migration needs testing, CI, release gates, and module-boundary support.