For Apple-platform targets, the Kotlin Multiplatform compiler produces Xcode Framework binaries. KMMBridge provides the necessary tooling and configuration to publish these Framework binaries and make them accessible though Swift Package Manager (SPM) and CocoaPods.

The 1.1.0 release is a significant refactor of the project’s code. There are few public-facing changes, but many internal changes were made to help support long-term maintainability, stability, and potential future enhancements and improvements.

Upgrading from 1.0.x

There should be few changes for users who have not written custom extensions. Custom extensions may have minor method signature changes, but those changes shouldn’t impact existing implementations.

Read more about Upgrading from KMMBridge 1.0.

If you are accessing something from KMMBridge that was not intended as an extension point, it’s visibility may have changed. Please reach out to discuss and find a resolution.

Major Updates

Gradle Configuration Cache Support

Gradle configuration cache can significantly improve Gradle performance, so this enhancement has been high on the list. KMMBridge now supports Gradle configuration cache where possible.

If you are using the Maven repository artifact manager, which includes publishing to GitHub Packages, there is a bug with the Gradle publishing plugin that makes it incompatible with configuration cache. See our tracking issue.

Because KMMBridge is generally called from CI, if you need Maven publishing support, you should disable configuration cache when publishing your builds. You should be able to accomplish this by passing --no-configuration-cache on the command line.

Separate Modules

KMMBridge has evolved since launch by adding specific features as needed. That had resulted in vendor-specific and core code all living in the same place. For 1.1.0, various features have been moved to separate modules. Specifically GitHub features have been moved to a separate module and plugin id, which will have the most likely impact on current users.

If you are publishing to GitHub releases or GitHub Packages, you will need to change the KMMBridge plugin id from co.touchlab.kmmbridge to co.touchlab.kmmbridge.github.

Reduced Public API Surface

Earlier versions of KMMBridge left much of the internal workings of the project with public visibility. This release restricts the public API as much as possible, to better support future maintenance.

Streamlined Extension Interfaces

KMMBridge provides some explicit extension interfaces. These have been streamlined. See the upgrading doc for details.

External Repo SPM Publishing Support for GitHub

There are a few scenarios where publishing to an external git repo is necessary for SPM. If you are publishing a KMP module from an Android repo, git tags related to Android may conflict with those necessary for SPM versioning. In addition, if you want to publish a dependency without access to the source code, the publication will need to be sent to a separate repo.

The KMMBridge GitHub implementation now explicitly supports publishing from one repo to another repo, specifically dedicated for SPM versioning.

KMMBridge Direction

KMMBridge has had a fairly long history and an unusual origin story. Rather than starting small and growing, the first version of KMMBridge was carved out of what was a significantly more complex tool. The details of how that tool worked aren’t important, but the problem that tool was attempting to solve certainly is.

Native mobile teams adopting KMP almost always start with a few KMP libraries. For virtually all of those teams, that is also where they stop. Making the leap from “some shared logic” to “everything up to the screen” is unfortunately rare.

The “bigger tool” was an attempt to automate a workflow that might enable teams to move beyond the library stage, but after experiments and feedback, it wasn’t solving the deeper issues.

However, what it did do well was orchestrate shipping KMP builds to iOS devs. At the time, if you wanted to give your iOS devs a KMP build, you would have to write the whole thing yourself. Since most teams get started with KMP by using libraries, the lack of a simple way to do so was a serious problem for adoption.

So, KMMBridge was (roughly) pulled out from the bigger tool. It served the immediate purpose of enabling KMP/Xcode dependency publishing, but many of the opinionated workflow concepts of the bigger tool came with it.

The evolution since, especially the 1.0 and the current 1.1 release, have involved removing the “complications” that were carried over from the original project.

KMMBridge now has one job: publish KMP code for use by Xcode. It should do that job well. That’s the direction going forward.

Is scaling still a problem? Very much so. Expect to hear more soon. However, every team starts with libraries. That step should be as easy as it can be.

Also, we’ve maybe figured out a simple way to debug Kotlin, from Xcode, without building Kotlin locally, using SPM. Check back next week…