· 5 min read Posted by Kevin Galligan
KMMBridge 1.0 Release
Overview
When integrating KMP into an iOS app, the Kotlin compiler builds an Xcode Framework. For local builds, this Framework is directly integrated with Xcode. However, many teams need to publish and consume these frameworks like any other Xcode dependency. The process is conceptually straightforward, but can be difficult to implement manually. KMMBridge exists to make that process simple.
If your team is using GitHub and SPM to manage dependencies, our KMMBridge SPM Quick Start will be the quickest and easiest way to start publishing KMP Xcode binaries. It uses GitHub Release artifacts to hold the Xcode Framework binary, and GitHub Packages for the (optional) Android dependencies.
For all other configurations and CI tools, KMMBridge can still be used, although the details of how to set them up vary, and will require custom integration work.
This is a relatively major change focused on how the tool should be used. Feedback will be very useful as teams work with the tool. Please find us in the Kotlin Slack in the “touchlab-tools” channel, or start discussions/create issues in the KMMBridge repo.
Integrating KMP builds for iOS using SPM is straightforward. However, if you want your whole team to start developing with KMP, publishing binaries is not great for the iOS team.
We recommend sharing KMP source instead
For native mobile teams, integrating KMP into your workflow needs planning. See our post series KMP For Native Mobile Teams for more info.
Changes for 1.0
KMMBridge has had three major release versions. 0.3.x, 0.5.x, and now 1.0.x. While most libraries grow in complexity over time, these major phases have each been focused on simplifying the tool.
KMMBridge started life as part of a significantly larger tool, focused on KMP team workflows. It’s features included basic publishing support, but also a lot of developer workflow opinions. This may have been helpful for some, but seemed more likely to confuse users who were simply looking to make their KMP available to iOS devs. The 1.0.0 release completely removes the developer workflow opinions. These can be added, but they would be implemented with CI. KMMBridge 1.0.0 is all about the basic feature of the tool: publishing KMP XCFrameworks.
This release also focuses on SPM. While CocoaPods is still supported with the tool, the templates and tutorials are SPM-only. CocoaPods involves cross-repo CI config, which is complex. The CocoaPods publishing flow is also much more likely to fail during the publishing phase, which required complex and brittle roll-back features. All of that was implemented within our “default” GitHub Actions workflow. Tweaking that workflow and debugging issues is a common source of problems, and largely avoidable for teams who only want to use SPM.
CocoaPods is in maintenance mode. While many teams use CocoaPods, the overall industry has been moving to SPM. Requests for CocoaPods support and submitted issues has gone down dramatically since KMMBridge was originally released, so our focus has shifted as well.
For users familiar with the callable GitHub Actions workflow templates of past releases, we no longer have one for the 1.0.x generation. Because the tool is now focused, and if using SPM-only, there’s no need. Editing your CI workflow directly would be much easier than trying to integrate with an external workflow.
Migration from 0.5.x
Should you migrate? This release doesn’t “fix” anything broken. The goal was to streamline the tool. If publishing currently works, there won’t be much gained immediately by migrating. However, any future work will be focused on this version series. There is currently no roadmap for additional features, although there are occasional additions as feature requests come in.
If you were using GitHub Packages to publish files, Gradle config changes should be fairly minimal. The major workflow change is related to versioning. As mentioned above, earlier KMMBridge designs included developer workflow opinions. Specifically, there was the concept of automatic versions.
The idea was that you’d specify a version prefix like 2.1, and dev builds would be published incrementally. So, each time you publish, the GitHub Actions workflow would calculate the next increment: 2.1.0, 2.1.1, 2.1.2, etc. The current template simply uses whatever you set the Gradle version property to in your Gradle config. To use that, change the Gradle config in your scripts to grab a version number in whatever way you prefer to configure it. KMMBridge will use Gradle’s version (where needed).
Auto-version will still work if you want to use that. However, you should pull the relevant sections from the 0.5.x default workflow and include them in your CI config.
The new quick start CI workflow is a mostly stock KMP build, with the exception of the two steps at the bottom, as well as the step that reads the version from a Gradle property (id versionPropertyValue).
1.0.x includes the ability to publish binaries to GitHub Releases rather than GitHub Packages. This is only for the iOS binaries. If you’re publishing Android, they would still need to be published to a maven repo (GitHub Packages by default).
Note: If you intend to publish iOS binaries to GitHub Releases, you must change the ~/.netrc config. The GitHub Packages config looks like this:
machine maven.pkg.github.com
login <Github User>
password <PAT>Releases point to a different server, so the config should be updated (you can have both in the same file if needed):
machine api.github.com
login <Github User>
password <PAT>