XCBundles

While working on adding support for binary-caching Swift Macros and multi-platform targets in Swift. I realized that there isn’t an equivalent to XCFrameworks for bundle targets. Why would you need that?

Tuist uses XCFrameworks to binary-cache framework targets (soon libraries too). Xcode supports defining links to XCFrameworks and Xcode takes care of using the right framework or library based on the destination. It’s very convenient. XCFrameworks is a directory with a convention around how to structure libraries and frameworks for different platforms and architectures.

But Tuist needs to be able to cache resource bundles too, and they are not supported by XCFrameworks. It’d be a huge stretch for the XCFrameworks name :). So I started pondering about creating our internal container, XCBundle. The structure of an XCBundle would be similar to the one of an XCFramework, but it’d be used to bundle resources instead of libraries and frameworks:

MyBundle.xcbundle/
  Info.plist
  ios-arm64/
    MyBundle.bundle
  ios-arm64_x86_64-simulator/
    MyBundle.bundle

This is going to be an internal container not exposed to the public. When generating Xcode projects, we’d introduce the necessary script build phases to copy the right one based on the destination. This is something that Xcode does automatically for XCFrameworks, but we’d have to do it manually for our own container.

This will most likely be worked on after we release Tuist 4, which is going to be a big milestone for us.