Greetings, traveler!<\/p>\n\n\n\n
Most iOS engineers don\u2019t need another reminder that builds are expensive \u2014 we feel it every day.<\/p>\n\n\n\n
You change a few lines. You wait. You switch branches. You wait again. CI rebuilds the same targets for the tenth time today. Someone suggests cleaning DerivedData. The build gets slower, then faster, then weird again.<\/p>\n\n\n\n
For years, we treated this as a fact of life: large Swift projects compile slowly, and the best you can do is keep the project modular and hope the compiler behaves.<\/p>\n\n\n\n
Xcode 26 introduces a feature that changes the situation in a more fundamental way: Compilation Cache<\/strong>. The goal isn\u2019t to make the compiler 5% faster. The goal is to stop repeating work that has already been done.<\/p>\n\n\n\n Let\u2019s break down what this cache actually means, when it pays off, and where it doesn\u2019t.<\/p>\n\n\n\n Consider a typical week in a team:<\/p>\n\n\n\n A large portion of this work is redundant. It\u2019s rebuilding because the build system has no reliable way to reuse the previous result.<\/p>\n\n\n\n This is the exact problem compilation caching is designed to solve.<\/p>\n\n\n\n Xcode has always stored artifacts \u2014 object files, intermediates, indexing outputs. But DerivedData was never built to support reusable caching across builds in a robust way.<\/p>\n\n\n\n The easiest way to see it: DerivedData is treated as disposable.<\/p>\n\n\n\n If you\u2019ve been on iOS long enough, you\u2019ve probably heard all of these:<\/p>\n\n\n\n That works because DerivedData is a local build workspace. It\u2019s convenient and practical, but it\u2019s not a structured cache with correctness guarantees.<\/p>\n\n\n\n With Xcode 26, compilation results can be cached in a more intentional and reusable way.<\/p>\n\n\n\n The key shift is this: Xcode can now decide whether a compilation action is reusable based on what went into it.<\/p>\n\n\n\n If the relevant inputs didn\u2019t change (sources, compiler settings, toolchain, etc.), Xcode can skip repeating the work and pull the result from cache.<\/p>\n\n\n\n This often improves two common workflows:<\/p>\n\n\n\n In other words: the cache targets \u201cI already compiled this exact thing yesterday (or five minutes ago)\u201d situations.<\/p>\n\n\n\n Compilation Cache can be enabled via build settings (including In many projects you can enable it by setting:<\/p>\n\n\n\n Once enabled, it builds up over time as you compile.<\/p>\n\n\n\n 1) Branch switching<\/strong><\/p>\n\n\n\n Some branches touch parts of the project that trigger a rebuild of modules you didn\u2019t edit directly.<\/p>\n\n\n\n When cache hits work well, you avoid recompiling a large portion of that unchanged code.<\/p>\n\n\n\n 2) Clean builds that aren\u2019t truly \u201ccold\u201d<\/strong><\/p>\n\n\n\n A clean build used to mean: \u201cyou\u2019re paying the full cost.\u201d<\/p>\n\n\n\n With compilation caching enabled, even rebuilds after cleaning build products can reuse previously compiled artifacts \u2014 as long as the compilation cache is still present on disk.<\/p>\n\n\n\n 3) High-churn CI<\/strong><\/p>\n\n\n\n Many teams rebuild the same dependency graph dozens of times daily.<\/p>\n\n\n\n If your CI setup persists caches between runs, you reduce a large chunk of repeated work.<\/p>\n\n\n\n This is where expectations matter.<\/p>\n\n\n\n Even if compilation becomes fast, builds can still be slow because compilation is only one piece of the pipeline.<\/p>\n\n\n\n Common non-compiler bottlenecks:<\/p>\n\n\n\n If your build time is dominated by these steps, compilation caching won\u2019t feel like magic.<\/p>\n\n\n\n It\u2019s doing its job \u2014 you just have other bottlenecks.<\/p>\n\n\n\n Many modern iOS projects are modular, and a lot of that modularity is implemented with Swift Packages.<\/p>\n\n\n\n In theory, modularity helps caching. In practice, cacheability depends heavily on how the build system models the dependency graph and compilation actions.<\/p>\n\n\n\n That means you can observe a slightly counterintuitive outcome:<\/p>\n\n\n\n This isn\u2019t a reason to avoid SwiftPM. It\u2019s simply the current state of a feature that is still evolving.<\/p>\n\n\n\n Measure it.<\/p>\n\n\n\n A simple evaluation approach:<\/p>\n\n\n\n Run a second build without changes and open the Build Report. If the total time doesn\u2019t drop, look at the longest steps in the timeline \u2014 scripts, asset processing, and resource copying often dominate once compilation is cached.<\/p>\n\n\n\n Compilation Cache is one of the most practical performance improvements in recent Xcode history.<\/p>\n\n\n\n It won\u2019t fix every slow build, and it won\u2019t replace good build hygiene. But it attacks a specific and very expensive category of waste: repeating compilation work unnecessarily<\/strong>.<\/p>\n\n\n\n Enable it. Measure it. And once compilation stops being the bottleneck, use that clarity to address the real build pipeline issues your project has been carrying for years.<\/p>\n\n\n\nThe repeating-work problem<\/h2>\n\n\n\n
\n
Why DerivedData never solved it<\/h2>\n\n\n\n
\n
What Compilation Cache changes<\/h2>\n\n\n\n
\n
Enabling it<\/h2>\n\n\n\n
xcodebuild<\/code>), which makes it approachable for both local development and CI.<\/p>\n\n\n\nCOMPILATION_CACHE_ENABLE_CACHING = YES<\/code><\/p>\n\n\n\nWhere you\u2019ll notice the biggest difference<\/h2>\n\n\n\n
Why some projects won\u2019t see dramatic wins (yet)<\/h2>\n\n\n\n
\n
A note on Swift packages and modular graphs<\/h2>\n\n\n\n
\n
How to tell if the cache is working for you<\/h2>\n\n\n\n
\n
Conclusion<\/h2>\n\n\n\n