Why fetching packages using Swift Package Manager takes too much time?
Let’s get directly into it without explaining the history of Swift Package Manager or the history of the fall of the roman empire.
Problem
When you add a dependency to your project using Swift Package Manager (spm), it fetches the whole repository of the package, with all the branches, and the full git history, which can be years and years of git snapshots.
Why?
You may ask, but why? Why not fetch only the release branch or even the release tagged commit?
The answer lays in this comment of a GitHub infrastructure engineer who was replying to an issue in Cocoapods when doing the exact same thing that we want spm to do, a shallow clone.
As mentioned in the comment, shallow clones, for some reason, are much more expensive than cloning the whole repository. And therefore, GitHub will do a rate limit to fetching those repositories, which can result in taking a lot of time to clone that package, even if its size is relatively smaller than the whole repo size. Even worse, the fetching can fail altogether because of the timeout.
That’s why Apple is fetching the whole repo, and this comment of a main contributor to spm who works at Apple confirms this claim.
Solution
So what is the solution?
Apparently there is an approach many companies are taking. It’s creating a separate repo which includes a precompiled .xcframework of the package and the consumer of that package now fetches a fraction of the size of the original repo that contains the source code.
Examples
For example airbnb/lottie team took that approach and reduced the size of their repo from +300MB to less than 500KB!!
- Original lottie-ios repo (+300MB)
- Optimized lottie-spm repo (less than 500KB)
Signal are also doing the same thing.
- Original OneSignal-iOS-SDK
- Optimized OneSignal-XCFramework
Conclusion
There is no conclusion, I’m just putting this section because every blogger adds it and making up random words to fill the spaces.
Real conclusion
If you found this article helpful feel free to share, and if you have any feedback, I’d love to hear it.
