When Should I Use KMMBridge?

Every team is a little different​

Different teams come to Kotlin Multiplatform Mobile in different ways. You might have two existing native apps and want to start sharing some logic between them. You might only have an existing Android app and want to extract some shared code that you can use as the base for a new iOS app. You might be starting a new app on both platforms from the ground up with the goal of sharing a large percentage of the code.

How is your team organized? Perhaps you are a small team where everyone touches all parts of the codebase and all platforms, or you might be a large team where different devs specialize in different platforms. You might be an organization with multiple teams working on separate features and shared Kotlin is only used by some.

For certain teams, building Kotlin/Native locally can be painful​

For teams that have an existing iOS app, adding Kotlin to the build and development process can sometimes be painful. The iOS dev team might not have any of the usual JDK and Android developer tooling that the Android team is used to. Even if they are set up to build locally, waiting for Kotlin builds can be painful for iOS developers who don’t need to make Kotlin changes. This doesn’t just matter for the developers themselves. Kotlin/Native needs to be built on a macOS host when targeting Apple platforms, and minimizing how often you build can be key to managing total build times and costs.

KMMBridge is designed to help teams avoid these issues.

By making it easy to publish and consume a Kotlin binary, iOS developers can consume Kotlin code via Cocoapods or Swift Package Manager, and don’t need to worry about what’s happening under the hood. This makes the Kotlin library behave similar to any other dependency in the iOS codebase and minimizes the impact of introducing Kotlin code. But more KMP-aware developers still have the option of building Kotlin locally when needed, which can be helpful to test changes.

KMMBridge optimizes for scenarios where existing iOS applications are migrating to using shared Kotlin, or where the apps will live in different repositories and not everyone will be working with Kotlin directly. If this describes your team, we’d love you to try it! The 1 hour quick start tutorial can be a good starting point, and there are other samples to demonstrate some different configuration options.

For other teams, these issues aren’t as important​

Some teams are coming from a different starting point. If you’re starting a new app, or have a smaller team where everybody is Kotlin-aware and comfortable setting up all the usual JVM tooling, then publishing binary builds probably isn’t as important to your development workflow. In that case KMMBridge might not be the right tool for you.

Instead, we recommend using KaMPKit as a model of a more all-in-one monorepo setup. KaMPKit showcases a lot of our standard practices when starting new projects from scratch, and is designed to get you up and running without needing any custom configuration. This makes it a much more accessible starting point if you aren’t at a scale where you’re concerned about publishing your shared code as an iOS library.

Whatever your starting point and team structure, we think Kotlin Multiplatform is the best way to build apps that can share code in a scalable way. Whether you use KMMBridge or KaMPKit, we hope you’ll find a setup that fits your needs. And if you want to go further, you can always reach out to Touchlab!