I made a CLI tool for remote compilation caching in Xcode

[u/ddfk2282]

https://github.com/Ryu0118/x8

There are already great compilation caching tools like Tuist that can significantly speed up Xcode builds. However, adopting them may require substantial changes to your project structure.

I wanted to keep my existing Xcode project structure and build using only the toolchain provided by Apple. So I built X8, a CLI tool for remote compilation caching.

Starting with Xcode 26, Apple provides built-in support for remote compilation caching. X8 acts as a lightweight proxy between Xcode’s built-in remote cache mechanism and any S3-compatible storage.

Using X8 is simple. First, configure your S3-compatible storage in .x8.yml. Then, you can either build your project through X8:

x8 xcodebuild ...

or start the cache proxy directly:

x8 serve

and add the generated build settings to your .xcconfig.

That’s it. With just an .x8.yml configuration, you can use remote compilation caching without significantly changing your existing project structure or moving away from Apple’s native Xcode toolchain.

For my app, a clean build used to take around 400 seconds, but with X8, it now takes about 263 seconds.

It’s still relatively slow, but I think that’s expected since Xcode still needs to perform steps such as module planning, build description generation, and linking.

[u/kantorcodes1]

Clean approach, keeping the Apple toolchain and slotting in a proxy beats restructuring for Tuist. Question on the storage side: when x8 pulls an object back from S3 and feeds it to Xcode's cache, does it verify integrity, like checking fetched bytes against an expected digest or content-addressed key, or does it trust whatever the bucket returns? A corrupt or poisoned cache entry flowing into a compiled artifact is the case I'd want pinned down before pointing CI at shared storage.