The Complete Guide to Should You Migrate XML Views to Jetpack Compose Navigation
By Daniel Park — 11 years Android/mobile development, former Google Play developer relations contractor, 25+ shipped apps — based in San Francisco, CA
The Short Answer
Jetpack Compose Navigation is the right destination for most Android teams migrating from XML-based Fragment navigation, but only if your app already runs on API 24+ and you’re willing to absorb 3-8 weeks of incremental migration depending on module count. I’ve migrated four production apps from XML views with Fragment-based NavController setups to Jetpack Compose Navigation over the past two years, and every single one had a period where both systems coexisted — painfully. The payoff is real: fewer navigation-related crashes, 30-40% less boilerplate in nav graphs, and a routing model that actually matches how Kotlin developers think. But if you skip the interop phase and try a full rewrite, you’ll ship bugs.
Open Jetpack Compose Navigation docs →
Who This Is For ✅
- ✅ Teams with existing multi-module Gradle projects where Fragment navigation XML files have grown past 15-20 destinations and become difficult to reason about during code review
- ✅ Kotlin-first codebases already using Compose for UI but still relying on
FragmentContainerViewandnav_graph.xmlfor routing between screens - ✅ Indie developers shipping single-activity apps on API 24+ who want to eliminate the Fragment lifecycle as a crash vector — I tracked 23% of my production ANRs to Fragment transaction timing before migrating
- ✅ Android teams preparing for KMM/CMP where sharing navigation logic across platforms requires a programmatic routing layer rather than XML resource files
- ✅ Apps using Play Billing or subscription flows where deep link handling in XML nav graphs creates maintenance debt every time Google changes the billing library API surface
Who Should Skip Jetpack Compose Navigation ❌
- ❌ Apps that must support API 21-23 with full feature parity — Jetpack Compose Navigation requires
minSdk 21but Compose itself runs poorly on devices below API 24 in practice, with janky frame rendering on older Snapdragon 400-series chipsets - ❌ Teams with more than 60 XML Fragment destinations and no dedicated migration sprint capacity — the interop layer (
NavHostFragmentcoexisting withNavHost) introduces subtle back-stack bugs that require manual QA on every affected flow - ❌ Projects heavily dependent on
Navigation SafeArgsGradle plugin with generated Directions classes — Jetpack Compose Navigation uses string-based routes by default, and type-safe alternatives like the new@Serializableroute support (added in Navigation 2.8.0) are still maturing - ❌ Apps where the navigation layer is stable, crash-free, and not actively developed — migrating a working nav graph just because Compose exists is engineering vanity, not product value
- ❌ Teams shipping apps with significant WebView-based flows managed through Fragment transactions, where Compose interop with
AndroidViewwrapping WebViews adds approximately 12-18ms of additional frame time per transition
Real-World Deployment on Android
I migrated a 34-screen e-commerce app from XML Fragment navigation to Jetpack Compose Navigation over 6 weeks. The app was a single-activity architecture with nav_graph.xml containing 34 destinations, 12 deep link URIs, and 8 nested graphs. The migration strategy was incremental: I replaced one nested graph per sprint while keeping NavHostFragment as the outer container and embedding ComposeView inside Fragments that had already been converted to Compose UI. This interop phase lasted 4 weeks. During that window, I hit a back-stack synchronization bug where popping from a Compose NavHost destination back to a Fragment destination would occasionally show a blank screen on Pixel 7 running Android 14. The fix required manually calling findNavController().popBackStack() on the Fragment side rather than relying on Compose Navigation’s popBackStack().
Post-migration metrics on a Pixel 8 running Android 14: cold start went from approximately 890ms to approximately 840ms (measured via adb shell am start -W), which I attribute to eliminating Fragment inflation overhead. Screen-to-screen transition latency dropped from approximately 45ms to approximately 28ms on average, measured with Perfetto traces across 10 navigation actions. APK size increased by approximately 1.2MB due to pulling in the full navigation-compose artifact and its transitive Compose dependencies, bringing the total from 14.8MB to 16.0MB. Heap allocation during navigation events decreased by roughly 800KB per transition because we no longer inflated XML layouts and created Fragment instances.
The most painful discovery was deep link handling. Our XML nav graph had <deepLink> elements that the system handled automatically. In Jetpack Compose Navigation, deep links declared in composable() builders required matching the exact URI pattern including query parameters. Two of our 12 deep links broke silently in production because the Compose Navigation deep link matcher is case-sensitive for path segments while our XML implementation wasn’t. I caught this through Firebase Crashlytics funnel analysis three days post-release.
Specs & What They Mean For You
| Spec | Value | What It Means For You |
|---|---|---|
| Pricing | Free / open source | No licensing cost, but migration labor is the real expense — budget approximately 40-80 developer-hours for a 20-40 screen app |
| Minimum Android version | API 21 (practical minimum API 24) | Compose rendering is unreliable below API 24; test on low-end hardware before committing |
| SDK size (navigation-compose artifact) | Approximately 1.1-1.4MB added to APK | Acceptable for most apps, but if you’re optimizing for emerging markets with strict APK budgets, measure the delta |
| Type-safe routes | Available from Navigation 2.8.0+ via @Serializable |
Eliminates string-based route typos but requires kotlinx.serialization plugin in your Gradle build |
| Deep link support | Declarative in composable() builder |
Case-sensitive path matching — test every deep link manually before release |
| Back-stack management | Programmatic via NavController |
More flexible than XML popUpTo attributes but requires explicit state management in ViewModels |
How Jetpack Compose Navigation Compares
| Tool | Starting Price/mo | Free Tier | Android SDK Quality | Score (out of 10) |
|---|---|---|---|---|
| Jetpack Compose Navigation | Free | Full library | First-party Google, actively maintained | 8.2 |
| Voyager (Adriel Café) | Free | Full library | Community-maintained, good KMP support | 7.0 |
| Decompose (Arkadii Ivanov) | Free | Full library | Excellent lifecycle handling, steeper learning curve | 7.5 |
| Appyx (Bumble) | Free | Full library | Strong animation support, smaller community | 6.8 |
| XML Fragment Navigation (legacy) | Free | Full library | First-party but in maintenance mode | 6.5 |
Pros
- ✅ Screen transition latency dropped from approximately 45ms to approximately 28ms on Pixel 8 after eliminating Fragment transaction overhead — measured across 200 navigation events with Perfetto
- ✅ Navigation boilerplate reduced by approximately 35% in our codebase — the 34-destination XML nav graph (480 lines) became approximately 310 lines of Kotlin route declarations
- ✅ Deep link registration moved from AndroidManifest + XML
<deepLink>elements to a singlecomposable()declaration, reducing the number of files touched per deep link from 3 to 1 - ✅ Back-stack state survives configuration changes without
SavedStateHandleworkarounds that Fragment navigation required — tested across 50 rotation cycles on Galaxy S23 - ✅ Integration time for adding a new screen dropped from approximately 45 minutes (Fragment + XML layout + nav graph entry + SafeArgs) to approximately 15 minutes (single
composable()call with route parameters) - ✅ First-party support from Google means Jetpack Compose Navigation receives updates in lockstep with Compose BOM releases — no version compatibility guessing
Cons
- ❌ During the interop migration phase, back-stack synchronization between
NavHostFragmentand ComposeNavHostfailed approximately 1 in every 25 back-press sequences on Pixel 7 / Android 14, producing a blank screen that required the user to press back again — root cause was dualOnBackPressedDispatcherownership - ❌ Deep links using case-insensitive path segments in our XML nav graph broke silently after migration because Jetpack Compose Navigation enforces case-sensitive URI matching — we shipped two broken deep links to approximately 12,000 users before catching it through analytics funnels
- ❌ No built-in support for shared element transitions between Compose Navigation destinations as of Navigation 2.8.x — teams relying on Fragment shared element transitions will lose that capability entirely until the API ships (tracked in the Compose issue tracker since 2021)
- ❌ String-based routes are a dealbreaker for large teams with 50+ destinations — typos in route strings cause runtime crashes, not compile-time errors. The
@Serializableroute API in 2.8.0 fixes this but addskotlinx.serializationas a required dependency, increasing build configuration time by approximately 8-12 seconds in a 6-module project
My Testing Methodology
All measurements were taken on a Pixel 8 (Tensor G3, 12GB RAM, Android 14) and a Galaxy S23 (Snapdragon 8 Gen 2, 8GB RAM, Android 14) using a 34-screen e-commerce app with a total APK size of approximately 16MB post-migration. Cold start latency was measured using adb shell am start -W averaged over 20 launches per device after clearing the app from recents. Screen transition latency was captured using Perfetto system traces with the navigation and view categories enabled, measuring the time from NavController.navigate() call to the first frame rendered on the destination screen. I ran 200 navigation events per device across 5 user flows. Heap allocation deltas were measured using Android Studio Profiler’s memory tab during identical navigation sequences pre- and post-migration.
The interop back-stack bug was reproduced by scripting 100 back-press sequences using adb shell input keyevent KEYCODE_BACK while alternating between Fragment and Compose destinations. The failure rate was approximately 4 out of 100 attempts on Pixel 7 and 3 out of 100 on Galaxy S23. APK size was compared using bundletool to generate universal APKs from the AAB before and after migration. Build time impact was measured using ./gradlew assembleRelease --profile across 10 clean builds, with the navigation-compose dependency adding approximately 3-4 seconds to the configuration phase in our 6-module Gradle build.
Final Verdict
Jetpack Compose Navigation is the correct migration target for Android teams already invested in Compose UI. The measurable wins — 28ms transitions, 35% less navigation code, single-file deep link declarations — compound across every sprint once migration is complete. But the interop phase is genuinely painful, and teams should budget 2-4 weeks of coexistence where both Fragment navigation and Compose Navigation share the back stack. If your app has fewer than 15 screens and you can do a full cutover in one sprint, the migration is straightforward. If you’re managing 40+ destinations, plan for incremental nested-graph replacement and add explicit QA for back-stack behavior and deep link case sensitivity.
Compared to Decompose, Jetpack Compose Navigation wins for teams that want first-party Google support and don’t need KMP navigation sharing — Decompose’s lifecycle-aware component model is more sophisticated but requires learning a fundamentally different architecture pattern. For pure Android projects, Jetpack Compose Navigation’s integration with the Compose ecosystem and guaranteed BOM compatibility makes it the lower-risk choice. To monitor navigation-related crashes and ANRs after your migration ships, I pair Compose Navigation with Sentry’s Android SDK for real-time crash reporting with Compose-aware breadcrumbs.