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.

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.

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.

You can, however, use AWS for public hosting.

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

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).

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 🙂

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.