KMP Team Workflows with KMMBridge

Most of the default tooling for Kotlin Multiplatform assumes developers will all build Kotlin locally. While active Kotlin development certainly requires locally building code, there are many situations that call for building and publishing libraries that can be directly used by iOS/Apple developers who don’t need to be building the Kotlin code locally, or even be aware that the code they’re calling isn’t just another Swift or Objective-C library.

What does KMMBridge Do?

KMMBridge let’s you assemble and publish Xcode Framework binaries from Kotlin, to various public or private repositories. It allows you to publish to either SPM, CocoaPods, or both.

Who needs it?

Any team where not everybody calling the Kotlin code wants or needs to build it locally, especially on the iOS side. That generally means:

Existing Teams Trying KMP

Existing teams trying KMP generally consist of platform-native developers. The pitch for KMP usually comes from the Android side. There is often resistance to introducing a major new tool into an existing build system before anybody has bought in, so the first step is usually to figure out how to build and publish an Xcode Framework. That’s a lot to figure out for Android devs generally unfamiliar with the iOS build system, so “trying out KMP” can be quite difficult out of the gate.

Larger Teams

Even if everybody is on board with KMP, most large teams modularize their code, and have different feature teams contributing libraries as versioned, tested SDKs. In these kinds of environments, adding KMP without published builds is quite difficult.

SDK Publishers

Many teams need to publish packaged and versioned SDKs, internally or externally. Doing that with either Android or iOS is well documented, but doing that with KMP, while certainly possible, again involves quite a bit of up front work. Or would, without KMMBridge :)

More Info

We’ve written a fair bit about KMMBridge since launch, so we won’t go too deep into the detail here. You can find more reading links at the end. For this post, we’ll focus on changes in this release, and how to use our new Quick Start project to get up and running quickly.

Getting Started

Quick Start Template

Along with our updated KMMBridge project, we are publishing a new Quick Start template project and post with instructions. You can create a new repo with a KMP project, ready to publish both Android and iOS binaries.

This is definitely the first stop if you want to try out the tool and be publishing Kotlin binaries quickly.

Existing Android Projects

Instead of a separate Kotlin repo, many teams choose to create a KMP module in an existing Android project and publish iOS binaries from there. This is generally straightforward, but will take more time to get started as you have existing configuration and code configure.

If you haven’t used KMMBridge, and especially if you aren’t pretty familiar with KMP and configuring Xcode dependencies, we would suggest trying the Quick Start Template first. This will make sure your setup is working and can be a guide for your custom setup.

If you’re comfortable with KMP and Xcode config, move right ahead into the KMMBridge Docs.

YouTube Live

We’ll be talking about KMP Team workflows and the KMMBridge Quick Start project on Thursday, Oct 12th, at 11am EST. Come join and ask some questions.

Upgrading KMMBridge

Along with this post series and a new Quick Start template repo, we have made major changes to KMMBridge itself. Projects using earlier versions of KMMBridge will almost certainly not be compatible with the updated version without some config changes. If you already use an existing version of KMMBridge and would like to know what’s changed and how to migrate, check out PORTING_0.3.x in the KMMBridge docs. If you are running into issues with anything we’ve changed, please reach out.