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 :(

[calvincestari]

HI @waitbutY - we discussed this issue a bit more today and have decided against creating a separate repo like lottie-spm.

Instead we're considering attaching built binaries of the various Apollo packages to each release. As you mentioned, cloning the whole repo is an unfortunate side-effect of how SPM works and we feel that supplying the built binaries is a reasonable compromise. This would allow anyone to take those binaries and make them available in an SPM package that suits their needs. Unfortunately I also do not have a timeline for when this work will get done.

[emersonhsieh]

@waitbutY I was running into this issue with Xcode 15.2, with the installing hanging and then timing out. The issue was resolved by upgrading to Xcode 15.4.

[AnthonyMDev]

After further discussion, the team feels that there isn't really an actionable solution to this we are comfortable with. With the introduction of registry support in Swift 5.7.1, users who have concerns here could feasibly set up their own artifact repository. You can also create your own repo that contains the bundled artifact as suggested the OP here. We don't believe there is a way to decrease the size of the existing repo without causing downstream effects. We're going to close this issue for now. If there is significant community feedback, we may consider reopening and trying to find a better solution.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.