Apollo takes a long time to resolve via SPM

[waitbutY]

Summary

Issue

In our app, we have 40-50 SPM dependencies, and Apollo is in the top 3 slowest packages to resolve.

Potential Solution

This is a known SPM issue, as SPM by default pulls not just the code but all the branches and commit history, etc.
swiftlang/swift-package-manager#6062

Some larger repositories have solved this by creating a separate repo that just points to the precompiled XCFramework, resulting in much, much smaller and faster package resolution.

Example, Lottie: https://github.com/airbnb/lottie-spm

Can AppsFlyer SDK be offered in this way for iOS app consumption?

Version

1.7.1

Steps to reproduce the behavior

List Apollo as a dependency of an Xcode project via SM

Logs

No response

Anything else?

No response

[AnthonyMDev]

Thanks for bringing up a discussion on this. The repo is pretty old and has a long history, so it makes sense that it takes a bit of time to clone.

@BobaFetters, would it make sense to add this to the existing Apollo Frameworks repo we have for Carthage support? Maybe we could just add a Package file like the one here from the repo referenced in this issue.

I'm not a fan of having yet another repo to maintain, but if we could accomplish this without too much additional work, it's worth considering.

---

The other side of this is, maybe we could do some work to reduce the size of the history of the repo. Running tools like git gc might help a little bit, but they don't really re-write the history. Would doing a squash of all commits over 3 years old (or some other appropriate time span) make sense? I don't think it's necessary that we keep all of that history around forever. I can't imagine we want to reference it very often.

I'm not clear on how that would affect consumers of the package. Developers who contribute to Apollo iOS would need to re-clone if we did something like this, but maybe we should explore what implications it would it have for users who are just depending on the package.

This single commit from 6 years ago is 40MB of node binary that we have since removed and no one should need this anymore.

[BobaFetters]

@AnthonyMDev I can look into what that would entail and if it would make sense to have in that repo or if it would need its own.

[waitbutY]

Thank you all, I really appreciate you looking into it.

Hanging on to commits from 3 years ago doesn't make sense to me (or doesn't sound like it adds much value), but all contributors needing to re-clone sounds fairly disruptive :(