It would definitely be possible to cache Xcode's
DerivedData folder, which would presumably give you some improvements to incremental builds.
The first problem with that is that the
xcodebuild archive action always performs a clean build. So without prebuilding your dependencies into a
.xcframework outside of the
xcodebuild process, I don't think it would be possible to meaningfully cache the build output.
The second problem is the same as with command-line use of SwiftPM, in that the build system is not fully deterministic, and so even if you cache all of
DerivedData, things would likely still be rebuilt across CI runs.
One area where you can potentially make some gains though is the dependency resolution phase: if you check the output of
xcodebuild -help, there are a few options in there related to manually resolving dependencies (
-resolvePackageDependencies) and controlling where the packages are checked out (
-clonedSourcePackagesDirPath). By caching the dependency checkouts across CI runs you could potentially remove the need for
xcodebuild to resolve dependencies at all. The
-disableAutomaticPackageResolution flag will let you turn that off manually to build from the cached sources.
One potential solution to caching the build products of your Swift packages would be to link them all into a single dynamic framework and then use
carthage build to prebuild that framework. I haven't personally tested this setup, but it could be quite useful.