KMP For Teams

Context

KMP has reached stable. Google’s Android team officially endorses KMP to share business logic. The ecosystem is growing rapidly. KMP, as a technology, has huge potential. Applied well, it can dramatically increase development efficiency, as well as improve quality. Maintaining multiple implementations for effectively the same app, while a practical necessity, is obviously not an ideal situation.

KMP is not just another “cross-platform” tool. It can truly change how native apps are built.

Many new native mobile teams will soon attempt to introduce KMP into their development. Touchlab started putting KMP into production in 2018. Pretty much right after it was possible to do so. KMP has come a long way. It’s an exciting time.

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. Teams certainly do put KMP into their production flows, but approaches vary, as do results.

All new tech goes thorough this phase. However, KMP is entering existing ecosystems, with long-established patterns. Many of these patterns developed to compensate for the very problems KMP is intended to solve.

KMP is unique among mobile development technologies. It requires new ideas, yet most team approaches follow familiar patterns.

In short, KMP is stable, but it needs to mature.

Target Audience

KMP covers many platforms and can be used in many contexts. This guide is specifically for:

• 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.
• Most of the concepts and issues presented will apply directly to teams of 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.

This Guide

There’s quite a bit to cover on this topic, and the situation changes frequently. Trying to cover everything at once would take quite a lot of time. Some topics would become somewhat outdated before anything was published. It is also difficult to fit some detailed topics into an incremental narrative.

We’ll publish this guide with the core concepts on how to introduce KMP to native mobile teams. The guide will also include some “deep dives” after the main part of the guide. Future content will be added over time. Make sure to subscribe for updates!