Braintree iOS SDK takes a long amount of time to resolve via SPM

[waitbutY]

Is your feature request related to a problem? Please describe.

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

Describe the solution you'd like.

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 Braintree SDK be offered in this way for iOS app consumption?

[scannillo]

Hello @waitbutY - thank you for bringing this to our attention. I do see that SPM does a git clone --mirror (snippet) which copies all ref, remotes, & branches.

This is something we would love to improve. My first idea of why our SDK is so massive is the way we store our 3rd party dependencies (in a local Frameworks dir). We will explore this route, as well as others, to see how we can get the SPM install time down.

Will update this ticket once we're able to prioritize this initiative. Any other concerns please don't hesitate to bring them to our attention - any feedback helps us greatly!

[sphanley]

Just wanted to throw in my two cents to second the original suggestion here of offering Braintree's SDKs as precompiled binary targets. Running git clone --mirror against this repo pulls down 557 MB due to the depth of the history, whereas a single branch is only 12 MB. In lieu of SPM offering any way to perform a shallow fetch, binary targets referencing precompiled .xcframework(s) stored outside the repo seems to be emerging as the most common way of providing quick package resolution for packages with large repositories. As another data point, AWS utilizes the same approach for consuming their iOS SDK via SPM.