KMP For Teams

In the sections so far, we’ve had a general overview of KMP and teams. The terminology used has been “conversational” and familiar. However, it can also lead to some confusion. Before moving on to actually planning and implementing KMP, we’ll establish a few more precise terms and concepts.

Development Modes

Introduced in the previous section, these two development modes are critical to internalize.

Mode 1: Library dev

Smaller, discrete “modules”. Logic that is removed from the daily app concerns, or at least not tied to the dev cycle. Back end calls (they’re externally defined), db storage (app-related, but schema changes are usually not frequent), tax calculation, etc. Can be written and tested separately, and published as a versioned “SDK”.

Library dev has a slow velocity of change, and is not directly tied to daily app dev.

Mode 2: Feature dev

This is day-to-day coding. It is the architecture and logic underpinning app features. Without KMP, this code is all in the “app” repo, and changed as a unit. Changes are overlapping and frequent. This code is managed with version control. Software development would be chaos without it.

Changing as a unit is critical. Writing “architecture” and “logic” separate from “display” would be painful and inefficient.

Feature dev has a fast velocity of change, with overlapping and conflicting changes.

Code Flow Directionality

Code flow directionality is a conceptual way of looking at how code is shared. Structurally speaking. Rather than focusing on the specific techniques with which KMP is added to a project, it’s a conceptual definition.

Unidirectional

The KMP code is in one repo, the apps in their own repos. Code changes flow in one direction.

When we’re talking about “library dev”, with versioned, published builds, that’s unidirectional.

For KMP, this generally means “publishing binary dependencies”, but it doesn’t need to. We will be discussing unidirectional models with source code in later sections. Rather than focusing on the exact “how”, “unidirectional” is agnostic to the specific mechanism, but all unidirectional implementations share similar implications and outcomes.

This is, of course, not specific to KMP. Any library you use has essentially a unidirectional code flow model.

Specifically: KMP —> App. Generically: SDK —> Consumer.

Non-directional

Code doesn’t “flow” anywhere. It’s a “monorepo”. It’s an odd concept to define outside of this context, and we’ll mostly say “monorepo” rather than “non-directional”, but they’re effectively the same thing.

Non-directional basically means that all code is changed as a unit.

That usually means all of the code is in one repo. However, you could implement this with some CI slight of hand. Also, some people object to using the term “monorepo” to mean “just the apps”, as it usually means “everything”.

Bidirectional

KMP code flows in both directions. From app repo to KMP, from KMP to app. We’ll give a much longer description later, when we get to “scaling”. For now, just know that this is also one of our formal directional models.