Slow builds and constant indexing kill iOS productivity. Here are practical, safe ways to speed up Xcode build times and stop the spinning indexer.
Slow builds and never-ending indexing are among the most reported Xcode frustrations, and they get worse as a project grows.
Xcode does a lot: it compiles Swift and Objective-C, resolves dependencies, indexes your code for autocomplete and navigation, and renders previews.
Each of these consumes CPU, memory, and disk. On large projects or constrained hardware, the combined load translates into long waits.
Most slowdowns come from a few causes: a corrupted cache, a heavy or poorly organized project, type-checking bottlenecks in Swift, or simply not enough machine resources.
When builds suddenly become slow or behave strangely, stale build artifacts are a common culprit.
Start with Product > Clean Build Folder (Shift-Command-K), which removes intermediate build products and forces a fresh compile.
If problems persist, clear Derived Data, the folder where Xcode stores build outputs and indexes. You can do this from Xcode's settings or by deleting the project's derived data.
After clearing, the next build will be slower because everything recompiles, but subsequent builds and indexing often become noticeably faster and more stable.
Indexing powers code completion and symbol navigation. After a clean or a big change, Xcode reindexes, and the project can feel sluggish until it completes.
Give it time to finish once before concluding indexing is stuck. A genuine first index of a large project can take a while.
If indexing truly never completes, clearing derived data and restarting Xcode usually resets it. A corrupted index is a frequent cause of endless spinning.
Closing and reopening the project, or restarting Xcode entirely, clears many index-stuck states without any deeper intervention.
Swift's type inference is powerful but can be slow when expressions are complex. A single gnarly expression can dominate compile time.
Break up very long or deeply nested expressions into smaller, explicitly typed pieces. Adding explicit types reduces the work the compiler must do to infer them.
This is especially common in SwiftUI view bodies and large computed properties, where chained modifiers and operations can balloon type-checking time.
You can enable compiler warnings for slow-to-type-check expressions through build settings to find the worst offenders, then simplify them.
Make sure you are building in the right configuration for what you are doing. Debug builds compile faster than fully optimized release builds.
For day-to-day development you want the Debug configuration, reserving release-level optimization for archives and final testing.
Check that you are not building far more than necessary. Building for a single relevant destination is faster than building for many.
If you have many targets or build phases, audit them. Custom run-script phases that run on every build can quietly add seconds or minutes.
Every dependency you add increases compile and link time. A long list of packages can substantially slow builds.
Audit your dependencies and remove ones you no longer use. Prefer lean, well-maintained packages over large frameworks you barely touch.
Large generated files, enormous single source files, and sprawling asset catalogs can also weigh builds down. Splitting and organizing helps.
Modularizing a very large app into smaller components can improve incremental build times, since unchanged modules need not recompile, though it adds structural complexity.
Xcode benefits from a capable Mac. RAM and fast storage in particular have a strong effect on build and indexing speed.
If your machine is constantly under memory pressure, closing other heavy applications during builds can free resources for the compiler and indexer.
Keep enough free disk space available. Low storage slows everything, including derived data and indexing.
Keeping Xcode and macOS current also helps, since Apple continues to improve build performance, and newer toolchains can compile faster than older ones.
It is easy to guess at what makes a build slow and waste time on the wrong thing. Measuring first tells you where the real cost is.
Xcode can show build timing information, and you can surface a timeline of how long each phase and file took to compile. That data points you to the actual bottleneck.
For Swift specifically, build-setting flags can emit warnings when a single function or expression takes longer than a threshold to type-check. Those warnings highlight the exact code to simplify.
With real numbers in hand, you can focus your effort on the few files or phases that dominate, rather than rearranging things that were never the problem.
Most of your day involves incremental builds, where Xcode recompiles only what changed. Keeping those fast has an outsized effect on productivity.
Changes to widely imported files, such as a shared header or a heavily used Swift type, can force large portions of the project to recompile. Localizing changes helps.
Bridging between Swift and Objective-C, large auto-generated files, and overly broad imports can all reduce how much Xcode is able to skip.
Splitting a giant module into smaller ones means a change in one area no longer rebuilds the whole app. The structure costs some upfront effort, but it keeps everyday edits quick as the project grows.
Some slowdowns are not about the build itself but about everything Xcode does while you edit. SwiftUI previews, for instance, compile continuously in the background.
If you are not actively using previews, pausing the canvas frees CPU and memory that the compiler and indexer can use instead.
Likewise, autocomplete and live issue checking lean on the index, so a project that is still indexing will feel sluggish even when no build is running.
Being deliberate about when these features run, and giving the machine room to finish indexing before you push it harder, smooths out a lot of perceived slowness during everyday editing.
Speed is partly about maintenance. Periodically cleaning derived data and restarting Xcode keeps things healthy.
Write Swift that is friendly to the compiler: explicit types in heavy expressions, reasonable file sizes, and modular structure where it makes sense.
Keep dependencies minimal and intentional. Each one you add is a recurring tax on every build.
Finally, invest in your tools. A capable Mac with ample RAM and fast storage, plus an up-to-date Xcode, is the most reliable long-term fix for slow builds.
Clean the build folder with Shift-Command-K, and if that doesn't help, clear Derived Data and restart Xcode. Stale caches are a very common cause of sudden slowdowns.
A large first index takes time, but if it never finishes, the index may be corrupted. Clearing Derived Data and restarting Xcode usually resets and rebuilds it.
Yes. Complex, deeply nested expressions stress Swift's type inference. Breaking them into smaller, explicitly typed pieces can dramatically cut compile time, especially in SwiftUI views.
Significantly. RAM, fast storage, and free disk space strongly affect build and indexing performance. Keeping Xcode and macOS up to date also helps.