· 5 min read Posted by Kevin Galligan
Getting Started
KMP For Native Mobile Teams
This is a post series with several sections. If you landed here first, make sure to go back to the Intro to get the full story.
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 the same issues will apply. Most of our discussion will assume adding KMP to existing apps.
In our discussions, we’ll usually assume two separate git repos for the apps, and we’ll be adding KMP by introducing a third repo. This is not absolutely necessary. Tooling and workflows can be adapted to different repo configurations, but the 3 repo model is common and conceptually simple, so we’ll use that as our assumed configuration.
Plan Ahead
As discussed in the concepts section, KMP for native mobile falls into two basic buckets: library dev and feature dev. Library dev is generally straightforward to set up, while scaling to feature dev is where teams tend to run into trouble. However, the majority of KMP’s potential can generally be found in feature dev, because that’s where most of the code changes happen.
That isn’t to say all teams will, or should, have scaling as a goal. Some apps have a large amount of “library” code, and the team’s main goal is to consolidate that code with KMP. Having that as a goal will certainly simplify adoption, and a lot of effort and steps found in this guide can be skipped.
For teams hoping to move KMP into feature dev, being intentional about that goal and taking steps to target that goal early on will result in faster and better outcomes.
Although we won’t discuss the topic much in this guide, adding shared UI to portions of an app can have significant efficiency benefits. It is a different topic, however, with potentially very different best-practice. Adding shared UI to existing apps with native UIs will be similar to scaling KMP with feature dev. A new app with mostly shared UI and native UIs reserved for a few core screens, however, might look very different.
“Merging” Teams
We’ve talked to many devs and managers hoping to use KMP to “merge” their mobile teams. We’ve experienced a small handful of teams who have actually tried this.
It’s risky.
I won’t say you “can’t”, but it’s important to understand that simply merging teams will be painful. It will be painful for the team, and will certainly impact your efficiency.
We’ll touch on this topic at various points in this guide, and go into detail with later posts. The simple advice is if merging teams is something you want to do, you can minimize the risk by having a reasonable plan and structure in place. I would follow our feature dev scaling plan, and as individuals are comfortable editing both apps, they can do so. Training engineers to be competent on Android and iOS is not a quick process, and starts over when new engineers join the team.
Merging “teams” really happens on an individual basis. At least from a technical capability perspective.
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 code flow. This is library dev, with a limited amount of shared 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. In 2024, this is more of a psychological milestone than in the past. However, there are many important lessons to learn when publishing apps and shipping real production KMP code.
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. The bulk of the code and effort for most apps is found in app feature implementation. The difficultly teams generally face is not complex to understand. Avoiding that difficulty also is not complex, but does require understanding the problems and resolutions.
Next Section : Piloting
Piloting is the first phase. This is where KMP is introduced to your team. Having a plan and maximizing the developer experience, especially for the iOS team, is important.