Why Jetpack Compose is a game-changer for Android Development

What is Android Compose?

Google’s first sentence describing Android Compose on its landing page is: “Jetpack Compose is Android’s modern toolkit for building native UI”. I agree this is true, yet I think this statement significantly understates the importance and future impact of Jetpack Compose. Of course Google doesn’t hold back on superlatives about Jetpack Compose in other areas of communication!

In an article on SwiftUI I penned last week, I called Declarative UI Development a megatrend. The declarative UI trend includes Android too, and Jetpack Compose is the Android framework to enable declarative UI development for native Android applications.

Jetpack Compose Positioning

Google’s clear direction is to move developers toward Declarative UI development tools for future Android mobile development. Google isn’t alone in this paradigm shift. Apple iOS development is moving in the same direction (SwiftUI), and Google’s Flutter cross-platform framework was built from the beginning with similar declarative UI principles.

Important points regarding Jetpack Compose’s positioning and architecture:

  • Compose is clearly articulated as the future of native Android, and is certain to be the target for future platform SDK efforts–likely diverting resources from legacy development paradigms. Google will expect Android UI development to migrate to Compose over time.
  • Compose is built with–and is intended to be used with–Kotlin. This doesn’t close the door on Android Java development–there’s nothing in Compose that “breaks” traditional approaches yet–but it provides further impetus for Android developers to make the switch from Java to Kotlin if they haven’t already.
  • Like other Jetpack components, Compose has excellent backward-compatiblity with older Android OS levels – even users with older Android devices can run applications built with Jetpack Compose UI.
  • New UI developed with Jetpack Compose can be incrementally added to existing applications built with conventional Android UI techniques (i.e. XML-based or code-based UI development). This allows developers to dip a toe in the Jetpack Compose water without a wholesale rewrite of their apps up-front.

Declarative UI Development

The most important and architectural feature of Jetpack Compose is that it uses (and requires) a declarative syntax for UI development.

What does that mean?

Put simply, the code (syntax) of Jetpack Compose describes what the the UI should present–not how UI elements should be constructed. The how part is left to the runtime Jetpack Compose library to work out.

The declarative paradigm shifts a great deal of work from the developer to the underlying Jetpack Compose subsystem–read as “writing less code to do the same thing”. This saves time and money during initial development–and reduces the occurrence of UI bugs and regressions throughout the life of the codebase.

In a traditional Android UI development, a combination of XML documents and UI code will tediously describe both what andhow every UI component is constructed. The how part can be quite a lot of code, and is potentially a source of difficult to find UI state change bugs. State bugs in mobile apps are a significant risk–so reducing them from the start is a big win.

Declarative UI Development shifts a great deal of work from the developer to the underlying UI subsystem–saving time and money during initial development and reducing long-run codebase TCO.

Jetpack Compose Advantages over traditional UI development

Google has drawn a roadmap that all Android native developers are eventually expected to follow, but there are some short-term practical advantages of Jetpack compose to consider as well:

  • Compose is designed from the ground up to improve developer productivity. Many tedious software modules needed in the current Android development architecture have been refactored out of the developer workload. Looking at you, ListAdapter!
  • Declarative UI creates immutable UI objects, eliminating the need for programmers to write code that keeps UI components and underlying controller code in sync.  This simplified approach can eliminate an entire class of difficult to reproduce bugs–reducing overall product development costs.
  • Compose is designed from the ground-up with MVVM architecture in mind. MVVM architecture enforces a much more clear separation of concerns and makes code more maintainable. An opinionated framework like Jetpack Compose provides productivity incentives to fully embrace MVVM.

Disadvantages for Jetpack Compose

Most of the reasons not to adopt Jetpack Compose yet relate to timing, risk and learning curve.

  • Jetpack Compose at this writing (March 2021), is still relatively new. Compose holds the promise for increased productivity, but new technologies can have unknown limitations and internal bugs that may need temporary workarounds.
  • The declarative UI model, immutable UI and opinionated push toward MVVM may represent a significant learning curve for an existing development team. When timelines are tight, it’s often pragmatic to stick with what’s working rather than introduce new technologies and process changes into a project with committed delivery dates.

Can I use Jetpack Compose today??

The short answer is yes. Compose can be used as the basis for new apps or added to existing apps today. Apps that use Compose will still run on older versions of Android.

Is it still too Early (Spring 2021)?

As of this writing (March 2021), Jetpack compose is in Beta. For Google, Beta means the software interfaces are feature complete and developers can expect minimal breaking changes before the production release (planned for Summer 2021). So while it’s early days, it’s not too early to get started with Jetpack Compose for those who are willing to be among the first movers.

Compatibility with older Android Devices

Android has a highly diverse installed base, and devices are often removed from Android OS upgrade support before the end of their useful life (Android Fragmentation). Android application developers need to support older Android OS versions to avoid excluding large numbers of users.

Google has been mindful of the Android fragmentation issue, and whenever possible designs new UI and application services (such as AppCompat and Jetpack components) as backward-compatible libraries that are bundled with each application that uses them. Conversely, Apple’s iOS installed base is far less fragmented, so the company often includes new features with new iOS versions, making it unnecessary for these services to be bundled with applications.

Jetpack Compose, like most other Jetpack components, is designed for backward compatibility. Under the covers, Compose is a Kotlin-based software layer bundled with your app. That bundled software layer transforms the Declarative Kotlin code at runtime into UI components that even older versions of Android can create and use.

Jetpack Compose, while a new UI design paradigm, generates UI that older versions of Android can use.

Should I use Jetpack Compose?

Google has made it clear that Jetpack Compose is their direction. In the long-run (2-3 years), virtually all new native Android development will be built using Jetpack Compose–so the more relevant question probably is is “when should I start using Jetpack Compose”.

Other platforms that have already made the primary pivot to declarative syntax (such as Apple SwiftUI) have been enthusiastically received by developers. It should be expected that Jetpack Compose is highly likely to succeed and acquire significant adoption in the coming months and years.

Jetpack Compose is a good candidate when

  • This is a green field, new application, and the UI requirements fit into Compose’s current capabilities. I’d look for validation that 80%-90% of planned UI can be built with Jetpack Compose, with the remainder covered by interoperability with traditional UI development where needed.
  • Or the application is an existing app, it is stable, there are new features that could be built with Jetpack Compose now. This would allow some limited experimentation with Compose without the risk and disruption of a large-scale rewrite.
  • The development team has bandwidth and eagerness to learn a new app development paradigm (i.e. time spent on the learning curve can be budgeted).

It may be better to wait on Jetpack Compose if

  • The features or UI design that’s planned (or already built) is highly customized, non-standard in its styling or navigation, or calls for too many features that aren’t directly supported by Jetpack compose.
  • The project has dependencies on 3rd-party libraries that aren’t compatible with Jetpack Compose. In theory this should be a minimal risk, but should be assessed.
  • The development team doesn’t have the bandwidth to climb the learning curve for a new app development architecture at this time.
  • The organization is very conservative, and is not willing to adopt new technologies until they’ve proven themselves in the market for many years, have shipped at least three major versions, etc.


The first Android Development SDK was released in 2007–14 years ago as of this writing. The Android SDK has evolved–significantly–in that time, yet the basic paradigm of loosely coupled layout (usually in XML files) with code in Java (more recently, Kotlin), has largely remained the same.

While the current Android development architecture works–and works well, for the most part– much has been learned over the years about how to help developers build UI faster, with fewer bugs and with higher levels of quality. Some of these learnings have been incorporated in the current SDK, but others need an architectural/paradigm shift to be efficiently incorporated.

Jetpack Compose represents a major shift of the Android UI development paradigm–a direction which will be easier, faster and ultimately result in less expensive, higher quality software that better meets the needs of companies field software in a competitive mobile software marketplace.

View All Posts