· 5 min read Posted by Kevin Galligan

Introducing KMMBridge For Teams

With a Kotlin Multiplatform beta on the horizon, Touchlab is introducing KMMBridge, a tooling designed to get teams started with KMM.

Introducing KMMBridge for Teams

KMMBridge has had a major update. Please be sure to check out KMP Team Workflows with KMMBridge for the latest.

Today we are announcing KMMBridge, part of Touchlab’s new Faktory* tooling suite. This set of build tools allows mobile teams to successfully publish shared code faster than ever with Kotlin Multiplatform.

Specifically targeted at iOS publishing, teams can now implement the Internal SDK Flow approach, today’s best practice to quickly integrate KMM into production app builds.

To try it for yourself, visit https://github.com/touchlab/KMMBridge

KMMBridge allows teams to publish and integrate Kotlin Multiplatform (KMP) Xcode Frameworks as an internal SDK.

Why We Built a Team-Focused Tool

Touchlab has spent years working with teams at different stages of their Kotlin Multiplatform journey. Evaluating KMP, putting KMP into production, and yes, even a fair bit of time talking to teams who looked at KMP and decided against it. One of the key lessons we’ve learned seems obvious in retrospect.

Different types of teams work in different ways.

Of course, every team is different. Every situation will be different. However, there are common patterns.

Out of the box, the KMP and the Kotlin/Native toolkit will let you build an Xcode Framework, then integrate it locally into your Xcode project. This works well if everybody on the team builds Kotlin. And in an ideal world, everybody would be able to build Kotlin.

But in the real world, most teams who have succeeded followed the Internal SDK Flow approach.

See the KMMBridge Quick Start

The recent KMMBridge update also has a new and improved KMMBridge Quick Start. You can see the original one from the link below, but new users should follow the updated quick start.

Get started with KMMBridge quickly following this tutorial: Quick Start with KMMBridge

The Internal SDK Flow Approach

As with adopting any technology on a team, early wins help build momentum and confidence so the team can unlock the full potential over time. The Internal SDK Flow has emerged as the best practice to get faster ROI when adopting KMM. At its simplest, this approach means the Kotlin Xcode Framework is pre-built and published as an internal SDK (a private module shared with your team) so iOS developers can include it without building Kotlin locally.

The Kotlin Xcode Framework is pre-built and published as an internal SDK

Somebody else (a team member, CI, etc.) builds the Kotlin Xcode Framework and publishes it somewhere internal. That Framework is then consumed by Xcode just like any other SDK. The iOS build workflow does not need to add Gradle or Kotlin and does not add to its build time or risk. Our build tools let teams build their way immediately, increasing efficiency and eliminating unnecessary complexity to get started.

For more context, see Nate Ebel’s talk from Droidcon NYC 2022: Adopting Kotlin Multiplatform in Brownfield Applications. It’s a very good overview of the startup issues teams face.

How KMMBridge Works

KMMBridge is a set of Gradle tools that integrate with your Kotlin Multiplatform project to assist with building and publishing KMM Xcode Frameworks. It is built for the Internal SDK Flow, but you can also use it to publish public SDKs as well.

The basic flow is as follows:

  1. Edit and test your shared Kotlin code, then push to your source control repo
  2. Kick off a CI build with KMMBridge. It packages, versions, and publishes your Xcode Framework
  3. Tell Xcode to update to the new version

The iOS build workflow does not need to add Gradle or Kotlin and does not add to its build time or risk

KMM Bridge flow

For iOS devs, there is no need to install or learn anything new. KMMBridge supports Cocoapods and Swift Package Manager. It can publish to a few different back ends out of the box, including Github Releases, with more support coming soon.

Why Use This Approach?

As a leader or a member of a mid-sized-plus mobile team, does any of this sound familiar?

  • Most of the Android devs don’t know much about iOS builds
  • Most of the iOS devs have never touched Gradle**
  • The apps are in separate repos or at least have very different build workflows

Every team that Touchlab has worked with, that has successfully added KMP to their existing iOS app, has started with an internal SDK flow.

Some teams have relatively sophisticated internal module-sharing systems, Artifactory or similar. Most (and you’d be surprised at who) have nothing like that. Even with some kind of artifact sharing in place, there is a lot of custom work that would need to be done to wire up Kotlin Xcode Frameworks to be included into a production iOS build.

KMMBridge will help most teams speed past this and get started productively with KMM.

What Comes After the Internal SDK Flow?

What is the next step when you want to scale and get shared code closer to your feature dev flow?

It can seem simple on the surface but this can get tricky, depending on team structure and how features are developed. One example we’ve seen a bit of: over time both teams could start to edit the code as if it wasn’t shared, and without clear guidance, those edits can start to conflict in multiple ways.

Most teams with Kotlin Multiplatform in production have used one or more Touchlab solutions. If you are looking to scale your KMM dev (or have already done so), we should chat.

To provide feedback about your experience with KMMBridge, or to show your interest in Kotlin Multiplatform, join the conversation in the Kotlinlang #touchlab-tools Slack channel.


*There is more to the Faktory tooling that is in the works, but we decided to carve out this bit now as it is a necessary entry point for teams adopting KMM. As KMM enters Beta, for continued growth and adoption, there are core capabilities that simply need to exist, and the internal SDK flow is one of them.

**Most Android devs try to avoid it, me included (no offense Gradle)