:wave: We're using a shared KMM module in an Andr...

# touchlab-tools

[Niek]

👋 We're using a shared KMM module in an Android/iOS monorepo, so team members can modify KMM code whilst developing for the app. This allows us to develop KMM code and app code simultaneously, without having to first 'publish' KMM code to a repository. We're doing this by assembling an XCFramework into our local build folder which the XCode project then includes. Unfortunately this assemble step takes about 2 minutes for every minor code change.

What I've read here and there is that Touchlab recommends the latter option, by publishing KMM code as a Swift Package to a GitHub repository and then pulling it in into the XCode project.

I'm curious about a few things here, before I dig deeper:
• Could publishing KMM code through SPM be quicker than our assemble step?
• Is there a way (possibly through KMMBridge) we could set this up in a monorepo?

[kpgalligan]

What I’ve read here and there is that Touchlab recommends the latter option, by publishing KMM code as a Swift Package to a GitHub repository and then pulling it in into the XCode project.

We recommend that only for teams that aren’t using KMM at all and refuse to introduce the local build step. When we started working with teams who haven’t been doing KMM, there is often pushback to introducing KMM into the build pipeline for a variety of reasons.
• Android and iOS are in separate repos
• Most of the iOS team wouldn’t be editing Kotlin so the extra build is frustrating
• The iOS team has no experience with JVM/Gradle and the dev setup is creating issues
• The CI pipeline for iOS is already complex and/or doesn’t easily incorporate Kotlin/Gradle
Often, the KMM is sort of just a “trial” and requiring a bunch of new tooling and build time is a lot for something that the team hasn’t really committed to.
You get the idea. I’d actually recommend your setup, because the whole team can edit and contribute to Kotlin.
To your questions:

Could publishing KMM code through SPM be quicker than our assemble step?

That depends. If the dev using the Kotlin isn’t changing the Kotlin, then yes. By that I mean if you have a larger team and you have devs who only ever edit Swift and never really touch Kotlin, then for sure, just including a binary will be faster. Now, if they’re not editing Kotlin, the first XCFramework build takes a few minutes, and after that you don’t need to build again in your local branch, so the benefit would only be after pulling changed Kotlin code.

Is there a way (possibly through KMMBridge) we could set this up in a monorepo?

Yes, but you’d need to figure out if it’s worth it, as mentioned WRT the first question. Setting that up is straightforward, but if you then want to edit Kotlin locally, doing that with SPM is kind of tricky. If you do go down this route, we’d really like to improve the local dev experience with SPM and would like to chat.
However… (I’ll start a new comment to split up the big next concept)

[kpgalligan]

If you’re using the Kotlin XCFramework support and running assemble or assembleXCFramework on that, you’re probably building multiples of what you need to. Our builds have 3 machine targets configured: iosX64, iosArm64, and iosSimulatorArm64 (might have the words in the wrong order on the last one). That’s for the Intel simulator, ios device, and M1 simulator respectively. Also, if you don’t specify the build type, debug or release, then I think you’re building both of those. So, that’s 6 targets. To run locally, you only need one. On my machine, if I’m building and testing locally, I only need iosX64+DEBUG, because I’m on an intel machine and I only want to run debug on my simulator. If you’re on an M1, probably iosSimulatorArm64+DEBUG. `XCFramework`support in Kotlin doesn’t make that easy. KMMBridge has very basic support for this in the plugin. See https://touchlab.github.io/KMMBridge/spm/IOS_LOCAL_DEV_SPM.

[kpgalligan]

Running ./gradlew spmDevBuild -PspmBuildTargets=ios_x64 on my local terminal just builds iosX64+DEBUG. It’s not elegant, but functional. You can open up the source and see how it works if you just want to change your current build scripts. In KMMBridge, we configure XCFramework and kind of hack that to restrict targets. Anyway, if you’re poking around this and have thoughts, @russhwolf and I are thinking through making SPM better, and he’s going to be largely figuring out next steps. Possibly separating the local SPM dev from KMMBridge, as they’re kind of separate concerns.

[Niek]

Thanks! I think I should first dig into the build targets, it looks like I'm indeed building more than I need.
Our project will be sharing web and database code, so it will be quite common that iOS devs may need to modify Kotlin code.

I'll see what I can figure out and let you know!