At the beginning of this year, we started rewriting one of our Android applications into Jetpack Compose. Why are we doing this? Are we just creating unnecessary work for ourselves? Are we trying to stay trendy in the world of programming? Or perhaps, at the very least, when your partner mentions buying new shoes, we want to have the option to respond with, "Sweetie, that's lovely, but I just updated the paging library and tried out a new implementation of maps in Compose."
These may not be the exact reasons, although there's some truth to them. In this article, I'd like to delve deeper into the situation of rewriting an application into a new UI framework and explore this issue from various angles using an example from one of our applications where we are currently tackling the rewrite.
As developers, we are well aware of the dynamic environment in which we operate. However, this might not be so apparent to those who manage projects. One of our tasks (especially for the more senior members of our team) is to regularly, patiently, and gradually educate our clients about this reality. This is not only in the interest of the project's longevity but also for our mental well-being and, consequently, the speed of development.
New technologies often emerge much faster than trends in fashion. This, in itself, might not be so critical, but unfortunately, older technologies (those older than the brand-new ones) quickly become unmaintained and outdated by their creators. Not to mention compatibility with other libraries and security risks. Developers are thus under immense pressure to balance the development of new features and the effort to update the libraries they've already used, so as not to accumulate too much technical debt.
For those of you who have read Uncle Bob's "Clean Code," you will surely remember the technical debt curve. For those who haven't read the book, in a nutshell: as technical debt grows, the costs of change increase exponentially. So, rewriting XML files into Compose is simply another step in eliminating technical debt. However, as we will show, it's not entirely trivial, and there are many reasons for this.
In our case, we're dealing with a moderately to highly complex mobile application with many interesting features (paging lists, calls to payment gateways, calls to bank identities, calls to other applications, deep links), API endpoints, and quite customised UI elements.
It is important to realise that rewriting the entire application is not (and will not be) a one-time effort but a long journey. Due to limited resources, gradual rewriting is the only acceptable solution for both the client and the developers. And of course, the right moment must be awaited.
Internally, we decided in advance that in the first phase, we would write completely new features in Compose and leave the old ones as they are. At the beginning (before the initial excitement about Compose settles down), we will clean up "baggage" utility methods and delete what can be removed within the context of contextual changes. Only after that will we consider the actual extraction and rewriting of older code into Compose.
Once we received the green light to create a brand-new feature, we could start:
Navigation to new Compose features was not the only temporary compromise we had to accept. Here are a few other specific examples we had to learn to live with:
There probably isn't a one-size-fits-all recipe for approaching the rewrite of an application into an entirely new UI framework. Since programming is a creative activity, each application may be written differently, in different architectures, in different programming languages, and may use different third-party libraries that provide the same functionality. Conversely, even slight variations in identical libraries are enough to make us look at the rewrite differently.
In short, rewriting is not an easy task and usually falls far from the ideal scenario. Nevertheless, I hope that similar escapades in your days are indeed happening because it means that your codebase is healthy, and your client understands and supports your efforts to maintain it in good shape.
And that, in my opinion, is good business.