Hey gang ... We are finally getting our ios app of...

# touchlab-tools

[Bradleycorn]

Hey gang ...
We are finally getting our ios app off of cocoapods ( 🎉 ). We're using KmmBridge and have it setup with binaries and SPM. This works fine. Our next step is to setup Kotlin Debugging in Xcode. I've done this a little bit before in a demo project, so I'm familiar with how it works, etc... Our devs are setup to use the local dev flow so that they can build the app, and have it use their local copy of the kmp project (which is based on a feature branch of the feature they are working on).

My question is, how do you all handle doing CI builds of in-flight features (i.e. builds in between versioned releases). We basically need something similar to the "local dev flow", but for CI (specifically, github actions). When a PR is merged into a feature branch, we kick off a build of the feature branch in github actions to produce a build of the app that our QA team can use for testing.

I'm curious if anyone has come up with a good way to facilitate these incremental CI builds? Right now, we just publish a new version of the kmp library every time. But that's not really sustainable. I'm wondering if there's a better way?

[Simon Binder]

Are the app and the KMP projects are in different GH repositories? Something we've done is to to just build the XCFramework using regular Kotlin Gradle tools and upload it as an artifact. Then you could trigger a build of the app and patch the SPM definition to use that XCFramework as a binary target instead of depending on it as a package.

If the app and KMP project are in the same repository, it's trivial. Just build the XCFramework in one CI step and do something like this with the local path when building the app.

You can probably use environment variables read in Package.swift for both approaches to conditionally override how you depend on our Kotlin project.