We are finally starting with KMP and like the sour...

# touchlab-tools

[audax]

We are finally starting with KMP and like the source code based workflow with gitportal. I got excited and checked it out, only then I discovered that it is a Mac-only tool. My team is MacOS and Linux based. Our CI is linux based as well. How do I integrate my linux team members and the CI with gitportal?
(logging off for today, I am back on monday)

[kpgalligan]

I was on vacation last week, and am super behind on catch up, so the short version. The mac-only CLI tool was due to homebrew and the painful process of signing on mac for distribution. There was an earlier version using Graalvm that worked across systems, but I simply couldn't get the signing and install process working well, and we have other CLI tools that use KMP instead of GraalVM, so I went with that.
There is no non-mac cli, but there is a jar/docker version for CI.

[kpgalligan]

Now, the next question is if you plan to use unidirectional or bidirectional. Unidirectional is just publishing versions, which is conceptually simple. The only difference is you're using source instead of binaries. The urgency and utility of that is lower now, as we have updates to various build tools that let an iOS dev browse and debug Kotlin from SPM dependencies. https://touchlab.co/spm-kotlin-debugging.

[kpgalligan]

Bidirectional is a more complex flow. The current version of GitPortal was written with significant constraints to simplify the logic. The idea was to get that out into the world, get feedback, and add features as time goes on. After feedback, I think GitPortal's bidir mode is a bit too opinionated. It also uses a custom rewrite of git subrepo. In the process of writing that, I've learned quite a bit more about git in general, and it's better-known cross-repo tools: submodule and subtree. There's an in-flight update to GitPortal bidir that would use submodule instead of the custom subrepo code. It would use it internally, as I've found pretty much no team wants to use submodule directly in a relatively complex way. I don't either. submodule can handle pretty much whatever you need, but it's easy to get into trouble. So, the rewrite of bidir had a few goals:
• leverage submodule internally
• hide the details and complexity of submodule for day-to-day
• be less opinionated about how the cross-repo coordination works
However, we're a business before everything else, and priorities lately have been elsewhere, so I can't speak to timelines or plans.

[kpgalligan]

The short version, though, is I still think teams trying to scale KMP to app code that changes regularly, instead of just library code, need a way to safely decouple the native teams. Without that, your teams wind up having to work in lockstep to a degree that significantly erodes KMP's potential efficiencies. My various blog posts and talks on the topic get much more into the details of what I mean by that.

[audax]

Thank you very much! For now we just require a unidirectional flow, at least for the iOS application. The android developer will also push changes, but that's not problem, he is flexible enough to work with gradle composite builds e.g..

I missed that post about debugging with SPM builds. We are using quite a few SPM modules already, so I'll probably go that route. I just have to figure out how to publish the SPM package with on bitbucket instead of Github, but that should be a manageable task. 🙂

[kpgalligan]

how to publish the SPM package with on bitbucket instead of Github

I haven't looked at bitbucket in years. If there's a maven repo you can publish to there, you can use the maven artifact manager in KMMBridge. Just be aware that the SPM quick start is geared towards using GitHub Releases to hold SPM XCFramework binaries, so there a few places you will need to make changes. Also, if you're using bitbucket I assume you're not using GitHub Actions, so the whole CI will need some thinking.

[kpgalligan]

I have a completely different dev flow that needs to be published, using KMMBridge to model something like the GitPortal bidirectional flow. Not quite as good as using actual source, but it gets around the issues related to versioned builds and teams.

[audax]

I found some code that publishes to a git repository via maven publishing and will try that approach next time. Looks promising so far, but I am very interested in the dev flow you are working on!

[audax]

Oh no… I finally need to learn how to configure the maven-publishing stuff with gradle… >.<

[audax]

The solution is:

kotlin.native.enableKlibsCrossCompilation=true

maven-publish-Plugin with

publishing {
  publications {
    create<MavenPublication>("ios-shared") {
      from(components.first())
    }
  repositories { /* target repository */ }
}

kmmbridge in build.gradle.kts:

kmmbridge {
  mavenPublishArtifacts()
  spm(swiftToolVersion = "5.8") {
    iOS { v("14") }
  }
}

skie {
  build {
    produceDistributableFramework()
  }
}

• ./gradlew :iosShared:kmmBridgePublish -PENABLE_PUBLISHING=true to upload the binary artifact to the target repository
• Set and configure the swift package registry (we created one in artifactory) and publish to SPM repository:

echo machine <artifactory-domain> login DUMMY password $ARTIFACTORY_PASSWORD >~/.netrc
swift package-registry set <target SPM repository>
swift package-registry --netrc publish swift.<library name> $VERSION

[audax]

We need both an SPM and a maven repository because we upload the binary lib to a maven repository. This can be replaced by an upload to e.g. S3.