KMP For Teams

Quick Review

KMP is stable and quickly gaining adoption. The tech is amazing and has the potential to radically improve native mobile development. However, team guidance is virtually nonexistant. Most tooling and docs are focused on a single dev, in a single repo, doing “everything”. Most teams struggle to scale beyond library dev.

Native mobile teams in this context generally have platform “specialists” working on the Android and iOS apps, in different repos, with different conventions and workflows. While some of this guide will apply to cases outside of that common configuration, the guide is written with that kind of team in mind.

New apps may have some advantages, but if the developers are “specialists”, many of these issues with apply. The more common model we’ll be assuming here is adding KMP code to an existing product.

Have a Clear Vision

You should have a clear idea of what you’d like to accomplish. That doesn’t mean a detailed plan around architecture or repo structure. Just what you’d like to do with KMP, and what’s feasible for your team.

If your goal is to just add some shared libraries and not really to try to scale KMP usage, then of course, you should do just that. Adding a KMP library, once it’s configured and your team gets some expertise, is straightforward.

Scaling to core feature dev is what’s difficult. Some teams are open to trying this out. Some teams will simply not be interested, regardless of how well the tech works. While I’d never say “don’t try”, it’s a good idea to understand what’s likely feasible, and approach the topic accordingly.

If the goal is to “merge” the mobile teams and have “mobile devs” rather than platform specialists, understand that that will be difficult. Not impossible, of course, but from our observations, often impractical and if “forced”, risky. We’ll discuss that topic in more detail when we get to Scaling.

Adoption Phases

We generally bucket KMP adoption into three phases:

• Piloting
• Iterating
• Scaling

Piloting

In this phase, you plan your approach to KMP, pitch the tech to the team, and start introducing some code. This is the phase where you get some KMP code set up and integrated into the apps.

It’s a critical phase, but generally straightforward. Assuming no major blockers, most teams should be able to get through it. The primary goals here are to make the team comfortable with the tech, and start learning how it works.

“Piloting” usually involves adding a KMP repo in a unidirectional model (AKA “library model” and “publishing builds”). This is library dev, with just a bit of code.

Iterating

The shift from “piloting” to “iterating” is not very distinct, but it is useful to decide you are shifting focus and make intentional decisions.

Iterating happens after some KMP has been successfully integrated into the apps, but not much more has happened. This is the phase where learning and adjusting should happen, to improve the developer experience and become more comfortable with the technology.

We want both teams on board, and that means collaborating and making decisions that work for everybody.

If the app is “public”, this is also the phase to put some KMP into production. That is, of course, a psychological milestone. It’s also important to learn how to monitor production KMP code. Crash reporting, etc.

You can think of Iterating as “pre-Scaling”.

Scaling

Scaling is when you significantly increase KMP usage. That generally means moving from library dev to feature dev.

While scaling seems straightforward from a technical perspective, in practice, most teams struggle to be successful. It is hard from an organizational perspective.

Scaling is also where the biggest potential advantages of KMP live. At least for shared code (again, shared UI is different, as are other KMP targets).