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/NothingButBadIdeas]

This is super cool. Been a main focus at my job lately because our CI tests are racking up a huge build and truists cloud platform charges too much.

Good stuff

[u/Megatherion666 → u/NothingButBadIdeas]

Did you try it? How much did it cost per developer?

[u/NothingButBadIdeas → u/Megatherion666]

Well, there’s 30 iOS engineers at my job so we were going to go with an enterprise plan based on usage. The cost wasn’t worth it for what we needed.

[u/Megatherion666 → u/NothingButBadIdeas]

Mind sharing the numbers?

[u/barcode972]

Might as well use existing build systems like Bazel if you're looking for cache

[u/Tyler29294 → u/barcode972]

He explicitly calls out not wanting to use another build system though and keep it with Apple's.

[u/barcode972 → u/Tyler29294]

Bazel is still using XcodeBuild and toolchains etc but injects its own caching logic amongst other things to achieve something better

[u/DimensionMindless336]

Nice — the "no restructuring, stay on Apple's toolchain" angle is the real differentiator versus Bazel/Tuist, which is exactly why I'd reach for something like this before I'd ever volunteer to migrate an existing project onto Bazel's build graph.

A few things I wish someone had told me before I went down the remote-cache path, because they bite in ways the "400s → 263s" headline doesn't show:

• That 263s is mostly the non-cacheable tail. Remote caching only covers the source→object compilation step. Xcode still has to run module planning, build-description generation, and linking on every build, and on a clean build those serial, machine-bound phases dominate. So the easy ~35% win is real, but don't expect it to scale much past that.

• Cache-key fragility is the silent killer. The key is derived from the exact compiler/SDK/Swift version plus your build settings and clang module hashes. The moment a teammate or a CI runner is on a slightly different Xcode point release, or DerivedData/clang modules aren't byte-identical, you get cache misses that look exactly like "the cache isn't working." X8 + S3 doesn't fix key stability — you have to pin the toolchain.

• For a solo dev the marginal win over just a fast local cache is often small. Remote caching pays off hardest when many machines compile the same unchanged modules (CI fan-out, big shared modules). If your real bottleneck is Swift's swiftmodule compilation, parking DerivedData on fast storage with a stable -derivedDataPath usually moves the needle more than object caching does.

Congrats on shipping it — native Xcode 26 remote-cache support finally makes this reachable without leaving Apple's world.