Transitioning to Jetpack Compose: Challenges and Benefits of Migrating from XML-Based UIs

The world of Android development has evolved rapidly, and one of the most significant changes in recent years is the introduction of Jetpack Compose. As a modern toolkit for building native UIs, Jetpack Compose offers a declarative approach, replacing the traditional XML-based UI design. While the transition brings exciting opportunities, it’s not without its challenges. This blog will explore the obstacles and advantages of migrating to Jetpack Compose, offering insights for developers embarking on this journey.

Why Migrate to Jetpack Compose?

Jetpack Compose simplifies UI development with a declarative approach, allowing developers to describe the UI rather than manually constructing it. This shift aligns with modern development practices and offers several compelling benefits:

1. Simplified Codebase – Eliminates XML layouts and reduces boilerplate code, improving readability and maintainability.
2. Reactive UI – Seamlessly integrates with Kotlin’s coroutines and state management for intuitive, real-time UI updates.
3. Improved Productivity – Features like hot reload and Android Studio’s preview accelerate the development cycle.
4. Customizable Components – Makes it easy to create and reuse custom UI elements for a more flexible and unique user experience.
5. Future-Proofing – As Google’s recommended UI framework, migrating to Compose ensures long-term compatibility and support.
6. Better Collaboration – Compose Preview bridges the gap between designers and developers, enabling faster iteration.
7. Easier Onboarding – Compose’s Kotlin-first approach simplifies learning, reducing onboarding time for new developers.

Challenges of Migrating to Jetpack Compose

While the benefits are appealing, transitioning to Jetpack Compose has its own hurdles. During migration, you’ll likely need to mix Compose with existing XML views. Use <ComposeView> to integrate Compose inside the XML layouts. We could use this approach only as a temporary bridge before fully migrating screens to Compose.

Understanding these challenges can help developers plan and execute their migration effectively:

1. Partial Ecosystem Support: Some libraries and tools might not yet fully support Compose, necessitating workarounds or hybrid solutions.
2. Backward Compatibility: Compose supports Android 5.0 (API level 21) and above. Maintaining a hybrid architecture becomes necessary for apps targeting older devices.
3. Performance Optimization: While Compose is optimized for modern devices, developers may need to fine-tune performance for complex UIs.
4. Migration Overhead: Transitioning from XML-based UIs involves rewriting large parts of the app, which can be resource-intensive.

Integration Challenges:

We considered migrating small components like Button, TextView, Inputs, etc. This lead us to adding the multiple <ComposeView> tags in single XML screen. The potential downsides were:

1. Performance Overhead: Each <ComposeView> initializes a separate Compose runtime environment, resulting in higher memory consumption and potential performance issues due to multiple independent Compose trees. This increases rendering costs, causes UI lag, and leads to more frequent recompositions, as each <ComposeView> handles its own lifecycle separately.
2. Increased Migration Effort: Relying on multiple <ComposeView> tags as a temporary solution creates technical debt, making it more challenging to fully transition the screen to Jetpack Compose. Eventually, these <ComposeView> instances will need to be removed, requiring additional effort to refactor the entire screen. As more Compose-based components are introduced, the complexity of restructuring increases, leading to redundant work.

However, to optimize performance, we ensured that no more than one <ComposeView> was used in each XML. By grouping multiple views into a single <ComposeView>, we eliminated the performance overhead. This also helped reduce the migration effort moving forward.

How Halodoc Benefited by Migrating to Jetpack Compose

Migrating to Jetpack Compose has significantly improved our development workflow and product quality. Here are some key benefits our organization experienced:

1. Increased Development Speed: With Compose's hot reload and real-time preview features, UI development time was significantly reduced.
2. Better Code Maintainability: Eliminating XML layouts led to a more concise and manageable codebase.
3. Enhanced UI Consistency: Compose's theming system enabled a more uniform design language, reducing UI inconsistencies across screens.
4. Seamless Integration with Modern Architecture: Jetpack Compose seamlessly integrates with our existing MVVM architecture, leading to a more modular and scalable codebase.

Strategies for a Smooth Migration

We started migrating to Jetpack Compose based upon components. The challenge that we faced was to migrate a single component which was places inside the XML. At some instances we had to use the tag view of Compose as shown below:

This declared a ComposeView along with the other views inside the XML. And in the Activity/Fragment, we used below code to set the Composable View:

• Bottom sheet from XML view: During our migration to Jetpack views, we also transitioned our Bottom Sheets to use ModalBottomSheet. This approach worked well when opening the bottom sheet from another Jetpack view. However, we encountered issues when opening the bottom sheet from an XML view. To address this, we opted for BottomSheetDialogFragment, which proved to be effective for both XML views and Jetpack Compose views.

Below is the code snippet we use for Jetpack Compose provided ModalBottom Sheet. This works well when opened from another Jetpack view but has downside when opened from an XML view.

And, below is the code snippet we use for Jetpack Compose Bottom Sheet that works well when opened from XML.

Below are the other strategic points to be taken care of:

1. Start with Isolated UI Components: Introduce Compose in isolated parts of the app, such as new features or screens, to gain familiarity without disrupting the entire project, but making sure not using more then one <ComposeView> in single XML file. This lets you test Compose without affecting the entire app.
2. Target New Features First: Implement new UI features directly in Jetpack Compose instead of XML. This prevents rewriting existing, stable code and lets you integrate Compose into future development naturally.
3. Refactor Screens in Phases: Migrate individual screens/common components one at a time instead of converting the entire UI at once. Prioritize less complex screens before moving to UI-heavy or complex interactions
4. Hybrid Approach: Use ComposeView to integrate Compose UI within existing XML layouts, allowing gradual migration.
5. Monitor Performance: Continuously monitor and optimize Compose components using Android Studio’s Layout Inspector, Profiler, and System Trace to ensure a smooth and responsive user experience.

As migrating a smaller UI component in the bigger UI was a challenge and had downsides, we decided to follow a gradual migration approach by migrating a whole of a component, leaving no more than one <ComposeView> for the entire screen. And that component would include multiple smaller UI components. This gradual migration approach reduces performance overhead, maintains a single Compose runtime, and simplifies state management, and resulted into a cleaner and more efficient UI structure.

Conclusion

Transitioning to Jetpack Compose represents a paradigm shift in Android development, bringing a modern, declarative approach to UI design. While the migration process presents challenges—such as interoperability with existing XML views, state management complexities, and performance considerations—the long-term benefits make it a worthwhile investment.

By adopting a strategic, phased migration plan, we successfully overcame these challenges, ensuring a smooth transition while maintaining app stability. Through this migration, we achieved:

• A more modular and reusable UI, reducing code duplication.
• Improved development efficiency, thanks to Compose’s intuitive and concise syntax.
• Better UI consistency and customization, leveraging Material 3 and dynamic theming.
• Enhanced performance, with optimised rendering and fewer UI recompositions.

By embracing Jetpack Compose, we have modernised our UI architecture, paving the way for a more maintainable, scalable, and future-ready Android application.

References

1. This blog helped us with the migration strategy
2. This blog helped us using the compose views in the existing UIs without introducing any downsides

Join us

Scalability, reliability and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels and if solving hard problems with challenging requirements is your forte, please reach out to us with your resumé at careers.india@halodoc.com.

About Halodoc

Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek, and many more. We recently closed our Series D round and In total have raised around USD$100+ million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.