Intro

Context

In 2024, KMP has been declared stable. Google’s Android team officially endorses KMP to share business logic. The ecosystem is growing rapidly. KMP is proven, “production-ready” technology.

Many new native mobile teams will soon attempt to introduce KMP into their development. For your team and organization, there’s a lot of potential value when adopting KMP. Applied well, it can dramatically increase development efficiency, as well as improve quality.

Maintaining multiple sets of code that do essentially the same thing is clearly not ideal. There are many tools attempting to “fix” that problem, with a wide range of approaches. Within that set of tools, KMP is unique.

KMP is not just another “cross-platform” tool. It can truly change how native apps are built. While there have been code-sharing methods for the entire history of Android and iOS development, those methods are rarely deployed at scale. The reasons are varied, but in summary, we don’t use code-sharing options at scale because they are impractical. KMP is designed to change that situation.

While the tech is stable, the path for teams is not. All of the tooling, and virtually all of the online discussion of KMP, is focused on local development, for an individual developer. The basic structure of most KMP sample apps and template projects assume one developer will be writing the shared code, as well as implementing screens on both platforms.

The basic structure of KMP for native mobile, designed around a single developer, is impractical for teams. Without guidance and new approaches, the reality of KMP won’t match its potential. This is a bad result for an individual team, but it’s also a risk for the platform. If scaling KMP is difficult for teams, the KMP platform could join the pile of other code-sharing options. Rarely deployed at scale.

Because KMP is now stable and has significant traction and endorsement, many teams who previously passed over KMP will give it serious consideration in the near future. Having a reasonable story for teams is critical, and the time to figure that out is now.

Touchlab started putting KMP into production in 2018. Pretty much right after it was possible to do so. We’ve worked with many teams of various sizes, and have had a lot of observations and feedback from teams adopting the technology. KMP adoption for teams, at scale, is certainly possible, but it requires a shift from the common approaches.

Nuanced Solutions

All new tech goes thorough a maturing phase, where the basic technical tools combine with applied best-practice for different scenarios. For example, this website has some React in it. Various Netflix UI’s use React. However, it’s a safe bet that how Touchlab’s site uses React and how Netflix uses React are quite different. The tech is the same. The difference is that large teams and mission-critical, large-scale deployments, present very different problems than static websites with a handful of forms. Large-scale React deployments need large-scale-specific approaches. In short, different situations require nuanced solutions.

KMP needs the same. However, in the case of KMP, there are complicating factors. First, the scope of “KMP” is large. In this series we’ll be talking about native mobile code sharing, but you can also build:

• Desktop apps
• Command-line tools
• WASM apps
• Compose UI apps
• C static libraries
• Etc…

These are all very different situations, and require their own approaches.

Second, native mobile is mature technology. There are existing ecosystems, with long-established patterns. Many of these patterns developed to facilitate two separate code bases building essentially the same thing. KMP needs to bridge these platforms, at a higher level than existing code-sharing tools, while not attempting to replace the platforms, like shared-UI options.

From our observations, most teams either apply existing ideas to KMP, or, for the risk-taking early adopters, attempt to chuck all “legacy” patterns out of the window. Generally speaking, neither approach is particularly successful.

KMP is unique among mobile development technologies. It requires new ideas, and nuanced approaches. The context in which KMP is to be applied, and the desired outcomes, are critical to how KMP should be introduced.

Target Audience

This guide will cover KMP adoption issues and solutions for a specific set of situations. That will allow for nuanced approaches, which are only relevant to those audiences. We will be discussing native mobile development, for teams, who are not attempting to share UI with Compose. Specifically:

• Native mobile development. Android and iOS. Shared KMP code, with native UI. Compose for iOS is discussed, but approaches to sharing UI will likely differ (we’ll talk a lot about that in other places).
• This is for teams. A “team” is relative, but assume more than 2 native mobile developers, at a bare minimum. Smaller teams kind of “figure it out”, and often need to be reasonably capable of developing for both platforms.
• The developers on these teams are native mobile “specialists”. Self-described “Android devs” and “iOS devs”.

Common Assumptions

There are some common assumptions about your environment that will be made, although these can be more variable:

• The native apps are developed mostly separately, and probably in separate repos.
• KMP is being introduced into existing apps. Greenfield apps have special opportunities for adopting KMP, but much of the content still applies. Just be aware that some of the initial stages may not apply.

Next Section : Basic Concepts

In the next section, we’ll introduce some basic concepts that are critical to understanding the issues that code-sharing for native mobile presents, and certainly for understanding the proposed solutions.