Hello there. First of all, thanks for providing th...

# touchlab-tools

[Feri Nagy]

Hello there. First of all, thanks for providing these tools. I just played around with KMMBridge and it works pretty well for our setup. One thing I find a bit odd is the way the it uploads xcframework zip to maven for SPM. I get it is just for storage and it works, but I would be interested if you considered other approaches and the decision process behind the selected solution. Thanks for any info.

[Stylianos Gakis]

Is there something else in particular you would prefer, or just asking because you’re curious?

[Feri Nagy]

Mostly curious. I would not say prefer, I don’t have enough swift expertise for that. For some specific samples I found https://developer.apple.com/documentation/xcode/distributing-binary-frameworks-as-swift-packages where comitting the xcframework to git and linking locally with path seem to work too. And the Artifactory provides https://jfrog.com/help/r/jfrog-artifactory-documentation/swift-registry.

[Daniel Seither]

comitting the xcframework to git and linking locally with path seem to work too

This works, but is not a great solution in the long run because the binaries will bloat your repository. If you have a modest 10MB XCFramework and update it 100 times, your repo will grow by 1GB. You can start working around that with Git LFS and the likes, but storing the binaries outside of the repo is probably the cleaner solution in the end. I’m using S3, for example.

[kpgalligan]

Some history...

[kpgalligan]

All of the concepts in KMMBridge came from working with a client build or dealing with practical realities.

comitting the xcframework to git and linking locally with path seem to work too

Our first SPM build with a client did this. It "works" until you get to huge sizes. In our experience, and that of people we've chatted with, the magic number is about 5g. At that point, Xcode is just angry with you. Also, having a 5g+ repo is not great in general. The size of a framework is not the same as the size it'll be in a deployed app, and framework zips can get rather large. The math above is accurate, except 10m is quite modest. Ours were more like 50m (IIRC), and that was before M1 was common. We were only building the X64 simulator. If you do the math, that's 100 builds, then you're done. Not sustainable, obviously. We had to slice that repo and remove the binaries (which, of course, broke older builds we didn't know were still being used). Storing in repo is, at best, POC-only. That, or you need to create external SPM-only repos. It's not a great solution, in summary.

[kpgalligan]

Why maven? GitHub Packages, Artifactory, JetBrains Space, etc. It allows a lot of options without writing a specific adapter for each. For GitHub specifically, almost everybody can use it out of the box, and if using our templates, you don't need to configure anything. It is very difficult to describe the amount of research and work you don't have to do if you use KMMBridge and the template project.

[kpgalligan]

We have other storage options. Right now, just AWS. However, for private binaries, you need to get access to AWS, and S3 doesn't have a basic auth option.

[kpgalligan]

You can, however, use AWS for public hosting.

[Stylianos Gakis]

So does KMMBridge have some built-in configuration to target GitHub Packages instead of maven?

[kpgalligan]

So does KMMBridge have some built-in configuration to target GitHub Packages instead of maven?

GitHub Packages is using maven, actually. It's just the repo and access config that's specific to GitHub Packages. We have a helper function for that in KMMBridge, as well as various points in the "helper workflow". If we didn't have that helper function, you'd need to add the repo and auth yourself
https://github.com/touchlab/KMMBridge/blob/main/kmmbridge/src/main/kotlin/BuildFileHelper.kt#L31

[kpgalligan]

Now, on other options, we used to support GitHub Releases. It was sort of a loophole. You can store as many files, with arbitrary size, in a GItHub Release. That worked, but was hacky. On other options, KMMBridge has a fairly simple interface that can be implemented to push files somewhere else. "Where" is kind of the question. S3, Google Cloud Storage, etc (haven't looked at Azure) are all possible, but again, don't support basic auth to get artifacts, so some service needs to provide for that. Example: https://engineering.premise.com/publishing-kotlin-multiplatform-swift-packages-to-google-cloud-storage-be5c6987e5d

[kpgalligan]

We have an issue to look into https://git-lfs.com/. Seems like an option, but I've never used it, and it looks like everybody has to install the tool and (possibly) configure things? It might be a better overall option for some, but it's essentially doing what the maven push to GitHub Packages does (although conceptually a lot simpler).

[kpgalligan]

So, the question is, where should files go? The answer will depend on many things. If you're using GitHub, GitHub Packages is nice because access is controlled through GitHub, which you need to do anyway for your team. Using S3 or similar requires extra work. I've seen larger orgs that provide access through some kind of dev machine setup, but that's all org-specific. For public hosting, you really need to pay for a place. S3 will work, but you need an account. GitHub Packages can be used on a public repo, but you still need to configure auth. Presumably to prevent hosting large files for "free", although I haven't chatted with anybody at GitHub about that 🙂

[kpgalligan]

One of the discussions I've been involved in recently about KMMBridge is based on the idea that it's either kind of a "starter" tool, or only works with specific hosts and CI. The idea of KMMBridge is that the raw tool is fairly agnostic to these things, and can be extended. We have a GitHub flow that you can use, or fork. We don't (yet) provide alternative CI implementations, but that's because CI tends to get org-specific as teams grow and projects age, and, honestly, it would be a lot of work. At the end of the day, we're largely driven by client needs as well as our public OSS focus. If we had a few clients that wanted, say, Bitrise or Circle CI, we'd eventually publish some kind of template for those as well.

[Feri Nagy]

Thank you for the detailed answers. 🙏

It is very difficult to describe the amount of research and work you don’t have to do if you use KMMBridge and the template project.

I don’t doubt that and it’s awesome you folks did this. That is exactly why I asked here, so we don’t go and try to do the same kind of research.