Intro

With any new technology, the best-practice of how it should be applied develops over time, with experimentation and observation. KMP is no different, and in fact, potentially much more complex than other technology ecosystems. KMP can target many platforms, and be used in different configurations. Nuanced, context-specific workflows, libraries, and tooling needs to emerge for KMP to properly scale in adoption.

Native-mobile apps are generally built by native-mobile specialists, working on either app individually. GitPortal’s bidirectional mode models this approach with shared KMP logic.

Part 1: Repo and CI Setup

Intro

For native-mobile teams building separate native mobile apps, who intend to primarily focus on native UI, there are specific conditions and risks that should be considered. Shared native-mobile logic and architecture is often presented as the “killer app” for KMP. However, teams actually implementing KMP for native-mobile often face a frustrating and inefficient experience. The reasons for this are simple.

The default KMP setup, for native-mobile with native UI, is wrong.

Non-directional

KMP’s default config is a single repo, with a KMP module, consumed by both Android and iOS modules living in the same git repo and timeline. That is, the shared code is immediately shared. All changes are immediately available, and immediately impact, both apps.

A change to one app needs to be implemented on both. Changes focused on one app risk impacting the other.

In formal terms, this is non-directional. Everything is in one place.

Technically, this is fine. As a long-term fan of KMP, with years of experience with other similar tech, J2ObjC in particular, I’d argue KMP’s design is elegant.

It is “wrong” in the sense that native-mobile apps built at scale are rarely edited in lockstep by the same engineers. It’s simply not how these teams work. There are certainly teams that operate in the same repo, but an engineer editing Swift code generally doesn’t worry about breaking the Android app.

Native mobile specialists almost universally work on either Android or iOS. There has long been, and continues to be, a desire to merge these teams. Few teams actually achieve this, and for those that do, it isn’t without significant cost.

Unidirectional

The more common approach native-mobile teams take with KMP is with unidirectional library dev. A separate repo with versioned builds. This approach works with library code, but this approach is organizationally mismatched when attempting feature dev.

Your potential gains with KMP are lost to bad workflow.

Bidirectional

A better approach is one in which the native apps can be developed independently. Both the app code and KMP code. KMP changes in one app are made without the immediate need to implement or test in the other app. Those changes are eventually, and intentionally, shared with the other app and vice-versa.

To model this approach, GitPortal has a bidirectional mode.

Part 1: Repo and CI Setup