A fading hope

I have been an engineering manager at Cuvva for over 18 months, and it has been an incredible experience. Cuvva’s (unique) context, its challenges and achievements have made the past two years of employment, the most diverse and eventful of my entire professional career.

As I mentioned in Growing at Cuvva: lessons from a first-time engineering manager, I have been exposed to so many different angles of product development that my connection to mobile development and its community has been fading over time as a result.

However, recently I noticed that JetBrains plans to release a stable version of KMP (Kotlin multiplatform) by the end of 2023. In that moment, a sense of nostalgia ran through me and made me think about the article a hopeful shift that I wrote in 2020.

Almost three years have passed since then. I wondered how much, or maybe how little, has the environment changed since I envisioned that possible future. I noticed that today there are more case studies of KMP in production as the Kotlin blog can attest, but it does not seem like the technology has taken off yet.

But why? Why are not more companies adopting what is, in theory, such a great solution?

Interestingly, all anecdotal evidence I have gathered over the past few years leads me to believe that very few engineers would start their own businesses with native mobile applications for their products. My suspicion is that given time is of the essence in the world of startups, native mobile development would be a hindrance compared to a simple web based solution, even if at the (potential) cost of the user experience.

Today’s hiring market is also fundamentally different from the booming market of late 2020. In a downward economy with less venture capital money available, many companies have decided to cut down on staff, and most have become more conservative in how many professionals they are looking to hire.

In parallel, most cross-platform tools have also improved in the past two years. Quite a few applications developed in Flutter are almost indistinguishable from a native application. Moreover, some Web APIs nowadays are also able to leverage smartphone sensors. Think about it, outside of the top 10 most popular mobile applications, as a user, can you list at least 3 applications that you really wish had a native look and feel?

I still believe KMP to be a very clean technical solution to address the many problems that still exist in mobile teams nowadays. Problems like mismatch in analytics events, incoherent business logic and user navigation flow, as well as, the challenges of keeping feature parity within platforms, could all be addressed more easily with KMP while still leveraging all the benefits of native development.

These are problems that stem from the many organisational changes and communication issues that almost all companies face over time. Engineers move to other companies, new employees have different ways of working and expectations, habits and standards get lost. Believe it or not, sometime in the future, your codebase will reflect those periods.

At this point you are probably thinking that “that is not something a cross-platform tool should be responsible to solve”, and you would be right. But if a tool contributes to reducing these problems somehow, then it will be another strong reason to adopt it.

That is why I believe that for a platform like KMP to become more adopted, it has to have clear benefits not only for greenfield projects, but mainly for existing and ongoing projects.

KMP can provide less risk, from both the user experience and all the logistical nightmares of staff changes, that a big-bang migration to a cross-platform framework like React Native or Flutter would require. KMP can, in theory, leverage existing teams and capabilities with comparatively less risk.

As I have written in my past article, with KMP teams could end up having fewer native engineers in total, albeit they would be more focused on each app’s UI and UX, and have a few Kotlin-only developers that would focus on the domain/business logic and user data flow in general. For example, and I am grossly oversimplifying, a team could have three kotlin developers, one iOS and one Android developer instead of three iOS and three Android developers.

Less specialised staff is a clear business benefit since companies would have to hire less native developer engineers and could “more easily” grow less experienced engineers into the Kotlin-only part of the codebase.

However, no matter how beneficial a new tool may be, its ease of adoption and integration is still one of the main factors to consider, especially for those companies that constantly run “against the clock”.

In these contexts, which have been the case for almost all companies I have worked for, it has to be clear how existing teams will communicate and cooperate:

• How much would existing Android and iOS teams have to change in their codebases before KMP’s adoption? Is there any checklist or set of standards that teams could check against to measure themselves before starting? How long could it take?
• Where does code ownership sit between teams, who owns the repositories, and what new ways of working will have to emerge for this closer collaboration between native platforms? What are the trade-offs?
• Are most tutorials and examples up to date so that engineers face almost zero migration obstacles? What if the migration attempt fails for some reason? How quickly is it to revert?

I am not expecting Jetbrains to have all the answers to these highly contextual questions. I was happy to see that they have attempted to address some of them in the Introduce cross-platform mobile development to your team article. But I wish teams and companies that have “successfully” adopted KMP, would focus more on this side of the story and less on the technical benefits of KMP or their own technical solution.

In the meantime, I have downloaded and run a KMP project referenced in the official documentation on my laptop just for fun. The app ran great on an Android device, but unfortunately, I have been unable to build it on Xcode due to a few build issues I struggled to resolve.

Maybe next time.