Introducing KMMBridge For Teams

Introducing KMMBridge for Teams

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 Mobile.  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 Mobile (KMM) Xcode Frameworks as an internal SDK.

When you're ready, head to our Quickstart Guide to KMMBridge to get started!

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.

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 Mobile 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

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 Mobile 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.

When you're ready, head to our Quickstart Guide to KMMBridge to get started!

1. 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._ ↩

2. Most Android devs try to avoid it, me included (no offense Gradle)_ ↩