Debuggable Binary Cache for Huge iOS Apps Dependencies

Hello Swift Community :raising_hand_man:t2:

I hope to find you all well in these crazy corona times :four_leaf_clover:

Today i would like to talk about Swift Package and the binary artifacts that we can generate

Let me give you first a bit of context

In my current company we are building a very big iOS application and use many in-house developed frameworks.
We want to use our frameworks as precompiled binaries to reduce the build time: we also want to have the access to their source code within one workspace.

We currently use a fork of Carthage (nsOperations/Carthage maintained by @werner77 ) which basically fulfills those needs.

The NSOperations Carthage binary cache grants us the following significant advantages:

  • It allows us to decrease, significantly, the overall build time
  • It allows us to decrease, even more significantly, the Continuous Integration build time
  • It allows us to debug our binary dependencies when we link the source code in our Workspace

We are well aware about XCFramework and we are aware that they were designed for engineers that cannot freely share their source code.

So it seems like it's not exactly what we, and any other big application, need.

I had a long and pleasant read at SPM Support for Binaries Distribution

and eventually, quoting from the proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md)

This proposal is intentionally written to address the above use cases explicitly,
it does not define a general purpose "binary artifact" mechanism intended to address other use cases (such as accelerating build performance).

Hence my main question here is:

is there already any possibility, or concrete future plan, for SPM to leverage a binary cache
that would offer the same (or even improved) functionalities as the one offered from Carthage ?

I certain that this feature would serve well the entire community, especially the many big iOS apps out there

Thanks a lot for reading!

3 Likes

I believe this is part of the plan laid out in the LLBuild2 announcement (assuming their work there pans out). Llbuild2