Pros and Cons of Jetpack Compose in eCommerce Apps. When Should You Use this Technology?

Change is one of the few constants in programming. New technologies appear regularly, promising easier problem-solving, shorter app development time, or task automation.

When declarative solutions for UI development entered the mobile market, they caused quite a stir. Flutter, SwiftUI, and Jetpack Compose quickly gained their supporters, even though some experts remain skeptical. Where is this all coming from?

TL;DR

• The declarative approach for UI development has gained popularity in the mobile market with the introduction of Flutter, SwiftUI, and Jetpack Compose.
• The imperative approach, using XML files on Android and XIB on iOS, and the declarative approach differ in how views are built.
• Jetpack Compose offers benefits such as easier view building and animation, lower technological debt, and the ability to attract experienced developers.
• However, there may be challenges when using Compose, such as more bugs and technological issues, a lack of experienced developers, and a limited number of ready-to-use solutions.
• The choice between the imperative and declarative approach depends on the specific requirements of the project.
• Jetpack Compose facilitates creating non-standardized UI components and offers a new API for animations.
• Using Compose can lead to lower technological debt and a more satisfied team of developers.
• While there may be some challenges and potential for errors, Compose can still result in shorter software development time.

Imperative vs declarative approach – differences

Let’s start with understanding the difference between a classic approach to building views (with XML files on Android and XIB on iOS) and solutions offered by Compose or SwiftUI.

Imperative approach

Views in XML/XIB allow us to develop apps in the imperative approach. Components and screens are modeled with definitions saved in text files.

To create views in a launched app, we use files with definitions of desired elements. Then, in the code, we call methods that modify these elements of the view. We can do it by setting specific values or assigning particular functions.

To put it simply, we create an empty view with an assigned limited number of parameters. Next, we modify it with the proper features and data we want to display. It’s a classic approach used even before the mobile app era, in such environments as .NET (via XML/XAML files) and Java (e.g., Swing framework).

Declarative approach

Jetpack Compose and SwiftUI represent a different perspective on the same problem – a declarative approach. In this case, the delivered data determines how the view must be built and what components should be used.

Software developers specify the state of the view in the code along with the components that will handle it. Every change of this state refreshes the interface and – if necessary – changes/rebuilds the components. The same rules apply to Flutter.

The declarative approach became more popular with the development of React, a web framework that efficiently used some of its mechanisms. On mobile platforms, however, it’s a relatively new solution. That’s the reason why most apps still rely on the imperative approach.

Benefits of Jetpack Compose

Building and animating views is easier

Because the approach to building UI elements is different, Jetpack Compose facilitates creating non-standardized components – and they often appear in mCommerce apps. Introducing adjusted shapes, applying additional effects, or text styling is much easier compared to the classic approach.

Compose also has a completely new API for animations. It enables, for instance, faster creation of eye-catching transitions between the components or building animations that react to user actions.

Lower risk of technological debt

Google – as the owner of the entire Android ecosystem – places emphasis on the adaptation of Compose and its development. This technology is newer, and developers received it warmly, so it might be a safer choice when you plan a long-term project development. 

An additional advantage is that Compose is a part of the Jetpack package. It’s a collection of libraries delivered by Google that facilitate Android app development. This means that we can expect more integrations that will link Compose with other solutions from this package. For example, with `android-paging` (currently in alpha version) or Google Maps.

Satisfied developers

When I worked on projects using Compose, most of the developers I collaborated with had a positive opinion of it. Such specialists often enjoy using new technologies, and a happy team is usually a team more motivated to work.

By choosing Compose, it’s easier to encourage developers to participate in a project. Many of them look for an occasion to try this technology out and learn new skills.

Shorter software development time

I’m aware of the fact that this is a matter of dispute. Many people stress that Compose is a relatively new technology, so it’s prone to errors. And indeed, it can be problematic. You also need to keep in mind that solving some problems (even simple ones) might take more time.

However, from our experience, Compose still allows us to build native Android UI faster than a classic XML approach.

It’s easy to see in views made up of many components of different kinds. In mCommerce apps, these are usually order summaries or product pages. You can also observe it on non-standardized components. It’s hard to say precisely how many hours we save thanks to the declarative approach. However, according to developers who work on our projects, the difference is significant.

What kind of problems can you run into?

Bugs and technological issues

Despite Google’s support, you need to remember that Compose is still a new and constantly developed solution. Thus, it is not bug-free. Sometimes, we had to deal with problems that required contacting Google, and they were responsible for fixing these issues.

Luckily, these problems didn’t have a significant impact on the development of the apps and their performance. Nevertheless, building some specific functionalities took us more time. This doesn’t mean that you won’t run into problems when using XML but most likely, there won’t be so many of them.

Less experienced developers

Because Compose is still a novelty, not all developers had a chance to work with it. So, even if some specialists have many years of experience in coding, it isn’t obvious that they have ever built UI in a declarative way.

In mCommerce projects, time and cost are the factors that help us decide whether we want to build some features or not. Teams less experienced in Compose will have more difficulties using this technology. This might cause delays in the project or even lead to giving up on some functionalities.

A small number of ready-to-use solutions

Not all libraries and components used in apps are compatible with Compose (although the situation constantly changes for the better). For some elements, it might be necessary to use classic views with XML. This is the case with, for example, a barcode scanner or maps with pickup points.

It’s not a problem because Compose and XML interoperability is pretty straightforward. However, it might complicate the execution of some tasks.

Which way of building native UI is best?

There is no one good answer to this question. The choice between a classic approach and Compose should be based on the knowledge of the subject matter and the project requirements. So, it’s recommended to make this decision only after verifying, what features must be implemented. Then, you can consider which ones will be easier to make in the first or the second approach.

Alternative solution

In case of our last project, Homla app, based on the previous experience, we’ve made a decision to use hybrid approach. We’ve created all the views and components with Jetpack Compose. However, after the verification of client’s requirements related to navigation, we decided to use solutions from classic `Fragments`. Navigation in Compose just couldn’t give us the functionalities we needed.

The decision to choose a particular solution shouldn’t depend solely on developers. It’s best to engage people responsible for UI design and tests as well. 

Designers can verify what components are available in Compose libraries. Then, they should discuss with software developers how complex it can be to implement non-standardized components in the first and second approaches. This way, the final decision should please every member of your app development team.