KMMBridge

KMMBridge - XCFramework publishing for Kotlin Multiplatform

KMMBridge is a Gradle plugin that allows you to publish Xcode XCFrameworks from your Kotlin Multiplatform projects. Developers using Xcode can then directly consume these XCFrameworks using Swift Package Manager (SPM) or CocoaPods.

KMMBridge can be used to publish your iOS KMP builds to public or private repos, using various backend options to host the binary XCFramework files.

Quick Start

Configuring any production publication from scratch can be difficult. However, if you are using GitHub and looking to publish only for SPM, we have a quick-start option that will get you up and running in minutes.

SPM Quick Start

We also have a quick-start option for publishing with CocoaPods.

CocoaPods Quick Start

If you are upgrading from KMMBridge 1.0, you likely do not have much to do, but there might be minimal changes necessary. See Upgrading from KMMBridge 1.0.

Publishing Overview

To make Kotlin code available to Xcode and/or Swift build targets, the Kotlin KMP compiler builds an Xcode Framework. Regardless of the method by which you include that Framework, that is how Kotlin code is made available to Xcode.

All out-of-the-box build configurations for KMP are locally integrated. That means, to call KMP from Xcode, you need to locally build your Kotlin code.

Kotlin compiler builds an Xcode framework

However, you can assemble and publish these same builds for others to use directly. That is what KMMBrdige does. The broad steps are:

  • In CI, the Kotlin compiler builds an Xcode Framework from KMP source
  • The Framework outputs are converted to XCFramework packages, then all architectures are zipped into one file
  • The binary file is uploaded to some cloud host (GitHub Packages/Releases, AWS S3, Maven Repo, etc)
  • The Package.swift file is updated in the KMP repo
  • Xcode accesses the Kotlin build through SPM. It gets the Package.swift file from git, and the Kotlin XCFramework from the cloud host

Publish XCFramework with SPM

Publishing for CocoaPods is possible with KMMBridge as well. The binary XCFramework is published in the same way. In fact, if you publish both SPM and CocoaPods, they’ll both use the same published binary. CocoaPods needs to publish its package metadata, a “podspec” file, to a separate repo whose only purpose is to host podspec files.

Publish XCFramework with CocoaPods

CocoaPods Status

KMMBridge supports CocoaPods. However, we rarely use it, and we get few requests these days from clients or open-source users related to it. In addition, the official CocoaPods project is in maintenance mode, and appears to be slowly winding down.

As a result, the bulk of our focus and documentation is with Swift Package Manager (SPM). If you run into CocoaPods-related issues, please reach out.

Read More

KMMBridge Setup Overview

To use KMMBridge, you’ll need the following:

  1. A KMP module configured to build some Xcode Frameworks that you want to publish (this is in your Gradle config).
  2. A DependencyManager implementation and it’s related configuration. The options are SPM and CocoaPods. You can use both at the same time if publishing to both.
  3. An ArtifactManager. This interface actually “publishes” the zip file to a remote server, and generates the url from which your published binary can be accessed.
  4. Build and publication process. Generally a CI workflow. This is also your code. Our tutorials provide examples focused on GitHub Actions, but CI integration with production systems is often custom.
  5. Xcode config to access both the dependency config file and the zip file.

Xcode access to dependencies can be confusing and is often a source of issues. Please make sure to pay particular attention to the instructions and possible error conditions.

Specifically, for private repos and private XCFramework.zip binary storage, access must be configured separately for both. This is often a source of confusion and errors.

Swift Package Manager (SPM)

CocoaPods

Binary Artifacts

When publishing XCFrameworks, the Kotlin compiler creates a Framework for each target architecture. Each Framework is then converted to an XCFramework. All of these are then bundled into a single zip file.

That zip file needs to be hosted somewhere that is accessible by a stable URL.

If that URL is intended to be private, it needs to provide access through basic authentication. Services like AWS S3 do not provide basic authentication by default. You would need to create some kind of server, or find a service, that will provide private access to these resources. For a detailed post about the auth complexities involved (for Google Cloud, but it is the same fundamental problem) see Nate Ebel’s post on SPM publishing

Options provided by KMMBridge:

You can implement a custom artifact location by implementing ArtifactManager.

Reach Out

For help, discussions, issues, etc, Reach Out