After several months of using Jetpack Compose in a commercial project, I came to some conclusions that are worth sharing.

One thing you need to take into account is that I didn’t use a compose-only setup yet. The first module of our app was done standard-XML-way, with fragments/navigation component and so on, so I decided to use interoperability features.

Nevertheless, I believe that a compose-only setup, can only be better – therefore in my opinion it doesn’t matter for the following list.

If you’re struggling with the decision of whether to use Jetpack Compose in a new and/or existing project, here’s what I think might help you decide.

Pros

1. Low entry barriers

This is based on my experience in the company I’m working for. Recently new junior developer joined my team, and he was able to quickly grasp ideas of “Thinking in Compose”.

But there’s also a second thing to support that thesis. After the presentation of Jetpack Compose during the last workshop I led, participants made 2 coding exercises. And guess what, that was super-quick for them to do it, even though exercises were pretty complex, with both UI and state-management tasks.

2. Interoperability

Interoperability is a thing that lets me convince other people to use it in the latest project. API is working in both directions – Composables in XML’s, and custom view as Composables.

For example, you can use compose-related features in a new module of the app, without affecting others (but with a price of a larger APK).

3. Stable release for production use

Jetpack Compose isn’t a completely new thing. I was working with early (and working) releases almost a year ago. Since that time API evolved and become more mature.

But most important is the fact that compose recently was released with 1.0 stable version.

4. Not only for Android.

Jetpack Compose is the Android side of composing. But there’s more. Compose is a multiplatform solution that recently went alpha! It’s available for desktop and web. Official JetBrains note promotes it this way:

“Compose Multiplatform simplifies and accelerates UI development for Desktop and Web applications, and allows extensive UI code sharing between Android, Desktop, and Web. Currently in Alpha.”

5. More fun

Basically, it’s comparable to the transition from Java to Kotlin.

Do you remember the time, when Google announced that Kotlin becomes second language side by side with Java? A short time later, a community of android developers decides that Kotlin is an industry-standard with no way back. Of course, some people were not happy, but the majority said that Kotlin is the king. Only by the enthusiasm of tweets, articles, and people talking about this topic, you can predict, that the same story will happen to Compose.

6. High-quality sources

If you’re starting, the best places to learn are:

• official examples
• official documentation with details and examples
• dedicated site with lots of codelabs
• codelabs itself

All of that means you can expect similar syntax that is part of Jetpack Compose — at least its core API and the way of thinking about UI, which lead us to the next thing:

7. Declarative paradigm

Which implies one language (Kotlin), to rule them all. No XML’s and imperative programming means low coupling and high cohesion — which means fewer possible problems.

8. Development is noticeably faster and more efficient

I’ve got no number to prove it, but you can feel it once you’ll try it.

8. Less build time and app size

This one is based on declarations and examples from documentation.

Adding compose to the existing app means a bit slower build and a higher app size, but once you migrate fully to compose, that number should be better than current solutions. For more information check https://developer.android.com/jetpack/compose/ergonomics.

Cons

1. It’s not industry-standard – YET.

During the last Jetpack Compose workshops, I felt a clear sign of approval across fellow devs. The majority of voices were eager to deal with it in the future, some were talking about its high potential. None of them were against it.

2. Interoperability is great but comes with a little price

As I mentioned, adding compose may affect your build time and app size. But once it’s fully migrated, you can have better stats than before.

3. Preview issues – rebuild each time

Preview is great. It’s like 10x better than XML one as it provides the ability to view (even interactive) previews with mocked data. But nothing is free. The downside of this solution is re-rendering preview each time code will change – and builds are not that fast.

4. UI is laggy?

It is, but only in debug mode.

I was very upset with the performance of Jetpack Compose at first. Especially lazy columns which are equivalent to recycler view. Lags and glitches. Even on release builds. But there’s actually a kind of hack that makes everything smooth.

Here’s why it’s happening:

https://stackoverflow.com/questions/67383606/jetpack-compoes-lazycolumn-skipping-frames-lagging#comment121445575_67383606

And here’s how to fix it on release builds:

5. Some components are not supported, and some features are “on the way”

Here’s the roadmap of things that are planned to become part of Jetpack Compose in the nearest future: https://developer.android.com/jetpack/androidx/compose-roadmap.

Interoperability is a tool that gives you the ability to deal with old views like MapView, which are not supported by compose yet.

6. Testing

A new way of describing UI means new testing syntax to learn. Fair enough, but still it’s an additional cost of exploration and learning.

7. It’s evolving

You need to keep reading about new solutions, libraries, and architectures. Also, you have to change versions as things are rapidly improved. After 1.0 was released, updates are less frequent and drastic in terms of changes. But lots of focus means many improvements which make me optimistic about Jetpack Compose.

Self format

Thanks for reading — I hope you’ve learned something new. As I’m publishing content in many places about different things, so it’s good to visit self.format where you can find all destinations.

self.format is something I’m creating. It’s a blog about mobile development. It’s a newsletter about self-development. It’s also tweets and stories with handy tools and inspiring content.

See you there!