arst

Frequent, conflicting changes.

Areas of code where multiple engineers are making frequent, often conflicting, changes require version control. That is one of the main reasons everybody uses git. Development would be slow-motion chaos without it.

“Scaling KMP”, as a general goal, means using KMP where you’re doing most of your work. Not coincidentally, that is where you would find multiple engineers making frequent, often conflicting, changes.

Library publishing is linear. A published library is the end product. You can apply the same thinking to your app as a whole. Apps are published to app stores, with linear, infrequent versions.

It is simply the wrong model. Most “shared code” has “distance”. It is used less often, if at all, and whatever it does needs be valuable enough to justify its inclusion. Any team could write their non-UI code in C++. Some have tried. Those efforts have largely been abandoned. However, many apps include C++ for specific purposes. That code, if not edited by different engineers, or even different organizations, is rarely edited in the way KMP needs to be.

The mental model of “shared code”, however, is often a library model. That is because it can, and sometimes needs, to be. Scaled KMP requires new mental models.