How Speed Up Xcode Build by mastering compilation modes

Introduction: The Swift Compiler
If you are an iOS developer, it’s highly likely you’ve concluded that Swift has rapidly become one of the most popular native programming languages over the last few years, thanks to its modern syntax, safety features, and performance.

Whether you’re debugging a small feature or optimizing a production app, selecting the right compilation mode can save hours of development time. In this article, we’ll take a deep dive into the Swift compiler, exploring its key components, how they interact, and what factors influence its performance. By the end, you’ll have a clear understanding of the compilation process, empowering you to write better code and optimize your builds. Let’s get started!

Why Build Time Increases with More Modules
If you work on a team project with multiple layers each as its own module build time and performance are likely daily concerns. A key observation early in my investigation was: the more modules you add to your app, the longer the build time. But why?

To understand this, let’s revisit how Swift code is compiled. Whether you’re building a small script or a large-scale application, you’ll use either swift or swiftc:

• swift: The Swift interpreter. It executes scripts directly (e.g., swift script.swift) without compiling them into a binary. This is why Xcode can instantly show relationships between methods and variables without building or running your app. It interprets the code on the fly.
• swiftc: The Swift compiler driver. It orchestrates the entire compilation process, transforming Swift source code into machine-executable binaries. When you build a project, swiftc manages subprocesses like compiling, linking, and attaching debug symbols. For example, during an Xcode build, you’ll see messages like “Linking…” because linking is the penultimate step before the final executable is ready.

The Driver: The Orchestrator of the Compilation Process

The Driver is the top-level process in the swiftc compilation pipeline. Think of it as the conductor of an orchestra: it doesn’t perform the compilation itself but coordinates all subprocesses required to transform your code into an executable.

Roles of the Driver:

• Parses command-line arguments.
• Determines the sequence of jobs (tasks) needed for compilation.
• Invokes subprocesses like the frontend, linker, and debugging tools.
• Manages dependencies and ensures operations occur in the correct order.

Jobs in the Compilation Pipeline

The Driver launches several jobs, with the Frontend Job being the most critical. When Xcode runs swift -frontend, the Driver initiates frontend jobs—the initial stage of compilation after your code is converted into an intermediate representation.

Tasks Within Frontend Jobs:

1. Parsing: Converts Swift code into an Abstract Syntax Tree (AST).
2. Type Checking: Ensures semantic correctness (e.g., verifying variable types match their usage).
3. SIL Generation: Produces Swift Intermediate Language (SIL), an optimized representation of your code.
4. Optimization: Applies high-level optimizations to SIL (e.g., removing dead code).
5. Code Generation: Converts SIL into LLVM Intermediate Representation (IR), which is passed to the LLVM backend for machine code generation.

The frontend is where most Swift-specific optimizations happen, ensuring your code is efficient and error-free.

Other Key Jobs:

• ld: The linker combines object files and libraries into a single executable.
• swift -modulewrap: Wraps Swift modules for reuse in other projects.
• swift-autolink-extract: Extracts autolink information for libraries.
• dsymutil: Generates debug symbols for tools like Xcode’s debugger.
• dwarfdump: Analyzes debugging information in binaries.

+-------------------+
|      Driver       |  (Orchestrates the process)
+-------------------+
          |
          v
+-------------------+
|   Frontend Jobs   |   (Parsing, Type Checking, SIL)
+-------------------+    (Generation, Optimization)
          |
          v
+-------------------+
|    Other Jobs     |  (Linking, Debug Symbols, Module Wrapping)
+-------------------+
          |
          v
+-------------------+
|   Executable      |  (Final Binary)
+-------------------+

Understanding Swift Compilation Modes

When building Swift applications—whether for a small feature or optimizing a production app—the compiler’s behavior varies dramatically depending on the compilation mode you choose. These modes balance trade-offs between build speed, runtime performance, and incremental development efficiency. Mastering these modes is critical for Swift compile time optimization and improving Xcode build performance.

There are three core compilation modes: Primary-file, Batch, and Whole Module Optimization (WMO). Let’s break them down:

1. Primary-file Mode

As its name suggests, this mode compiles each file individually. This approach is ideal for debugging because it supports incremental compilation, where only changed files are rebuilt, and it allows parallelization of work across multiple CPU cores. However, this mode is not perfectly optimized due to redundant parsing: each job parses all files in the module, leading to quadratic overhead. For example, with 100 files and 100 jobs, you end up with 10,000 parses.

Sub-modes:

• Single-file: One compiler job per file. For example, 10 files result in 10 jobs, result 10,000 parses.
• Batch: Groups files into batches per CPU core. For example, 10 files on 2 CPUs would create 2 batches of 5 files each.

# Single-file mode (default for Debug)  
swiftc *.swift -Onone -o MyApp  

2. Batch Mode

This is a refined version of the primary-file mode that reduces redundant parsing overhead by grouping files into batches. For instance, 100 files on 4 CPUs would become 4 batches of 25 files each. Batch mode retains incremental compilation benefits while being more efficient for large projects where single-file mode’s parsing overhead becomes prohibitive. You can activate batch mode using the -enable-batch-mode flag.

# Batch mode (groups files per CPU)  
swiftc *.swift -enable-batch-mode -Onone -o MyApp  

3. Whole Module Optimization (WMO)

This mode compiles the entire module in a single job, enabling advanced optimizations such as dead code elimination and function inlining. It avoids redundant parsing entirely—for example, 100 files would require 1 job and 100 parses. However, WMO has two major drawbacks: it lacks incremental compilation (forcing full rebuilds) and has limited parallelism during early stages like SIL/AST phases, which are single-threaded.

# Compile with WMO and optimizations  
swiftc *.swift -wmo -O -o MyApp  

4. Xcode Configuration

1. Debug Configuration:
   • Mode: Primary-file (single-file or batch).
   • Optimization: -Onone (no optimizations).
   • Enable Batch Mode: Add -enable-batch-mode under Build Settings > Other Swift Flags.
2. Release Configuration:
   • Mode: WMO.
   • Optimization: -O (aggressive optimizations).
   • Enable WMO: Go to Build Settings > Swift Compiler – Code Generation > Whole Module Optimization > Yes.

Build Time Comparison

I conducted compilation performance tests on three Swift/Xcode build configurations Single-file mode, Batch mode, WMO + Optimizations in my project there are 166 files and I have a chip Apple M3 Max, 14 CPU cores and 36 GB of Memory:

Benchmarking Swift Compilation Modes: Single-File, Batch, and WMO with xcodebuild:

I just compared Swift compilation performance across the three mentioned strategies using xcodebuild. Use these commands to quantify trade-offs between development iteration speed and production-ready binaries in your Xcode projects.
NB : Results may vary based on project size, dependency structure, and hardware parallelism.

# Single-file mode  
time xcodebuild -project YourProject.xcodeproj -scheme "YourSchemeName" clean build SWIFT_COMPILATION_MODE=singlefile SWIFT_OPTIMIZATION_LEVEL=-Onone 

# Batch mode  
time xcodebuild -project YourProject.xcodeproj -scheme "YourSchemeName" clean build SWIFT_COMPILATION_MODE=wholemodule SWIFT_OPTIMIZATION_LEVEL=-Onone 

# WMO + Optimizations
time xcodebuild -project YourProject.xcodeproj -scheme "YourSchemeName" clean build SWIFT_COMPILATION_MODE=wholemodule SWIFT_OPTIMIZATION_LEVEL=-O

You can also create a Debug-WMO configuration to test WMO with -Onone. Observe how it disables incremental builds but reduces parsing overhead.

How to Boost Xcode Compilation Speed with Explicitly Built Modules

Optimizing compilation times in Xcode is a major challenge for iOS and macOS developers. An advanced solution to speed up this process is the use of Explicitly Built Modules. Unlike implicit module discovery, this approach precompiles dependencies and stores them as reusable binary products. The result: faster builds, increased parallelism, and optimized system resource management.
By adopting this strategy, you reduce dependency analysis time and minimize disk access bottlenecks, significantly improving your development efficiency in Xcode. However, be aware that this mode is not effective for all projects.

Comparing Implicit Module Discovery vs. Explicit Module Compilation Approaches

For this investigation, we tested IceCubesApp, an open-source application with numerous Swift and Clang dependencies. Due to its modular architecture, we compared the performance between implicit module discovery and explicit module compilation to assess the impact on build times.

Observations

Given the way the application is developed, the results show that Explicit Module Build is less efficient due to the large number of Clang dependencies (*.pcm). In this case, implicit compilation remains more efficient as it allows for better task parallelization. However, for a project primarily using Swift modules, explicit compilation could provide gains in incremental builds. Unfortunately, the design of SwiftPM modules in this project wasn’t well thought out.

Optimizing Compilation Times on Xcode: Best Practices and Recommendations

Following tests conducted on IceCubesApp, we confirmed that module management directly impacts compilation time. According to a document published by Artem Chikin (Swift Explicitly-Built Modules) and in conjunction with the results from my research phase, here are some recommendations I can offer to optimize your Xcode builds and avoid unnecessary slowdowns.

1 – Use Precompiled Modules to Avoid Unnecessary Recompilation

One of the most effective ways to speed up compilation is to precompile your modules to avoid their constant rebuilding. To achieve this, you can use Swift Explicitly Built Modules, which allow you to generate and store modules as reusable binary files.

💡 Tip: Check your DerivedData folder (~/Library/Developer/Xcode/DerivedData/) to see if an excessive number of *.pcm (Clang modules) files are being generated, as this can slow down the compilation.

If you find an excessive number of *.pcm files in DerivedData, it means that Xcode is excessively generating and recompiling Clang modules, which can slow down your builds. Here’s what to do in that case:

# Start by Cleaning DerivedData to Force a More Efficient Recompilation
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Check Automatically Generated Clang Modules
find ~/Library/Developer/Xcode/DerivedData/ -name "*.pcm"

# Disable Unnecessary Clang Module Compilation
OTHER_CFLAGS="-fno-implicit-modules -fno-implicit-module-maps"

Why?

• -fno-implicit-modules: Prevents Clang from automatically generating module files (.pcm), forcing it to use precompiled modules instead.
• -fno-implicit-module-maps: Ensures that module maps are explicitly defined rather than being inferred, improving build stability.

2 – Leverage swiftc -emit-module for Efficient Build Management

Instead of letting Xcode manage dependencies automatically, you can manually generate Swift modules before the main compilation. This reduces analysis time and allows for better reuse of modules.

Command to manually generate a Swift module:

swiftc -emit-module -module-name MyModule -o MyModule.swiftmodule MyModule.swift

Benefits:

• Avoids recompiling modules on every build.
• Improves dependency consistency across different configurations.
• Reduces linking errors caused by dependencies.

Conclusion

By applying these strategies, you can reduce Xcode compilation times and avoid slowdowns caused by module discovery and recompilation. Since every project is unique, optimization will depend on the number of Swift and Clang dependencies used.

By mastering these modes, we understand that creating more files (class / struct / enum) is not necessarily an advantage, and that having files that are too long isn’t beneficial either. For example, in WMO mode, a very long file can slow down compilation because the compiler has to process a large amount of code at once. By delving deeper into these modes and their parameters, we realize that the best way to optimize build time starts with how we structure and write our code, adopting the right approach and defining the appropriate configuration mode for each module based on its intended use.

That’s all for today! I hope you enjoyed this analysis.

References & Further Reading

For readers interested in exploring Swift’s compiler architecture and performance optimizations in greater depth, here are key resources:

1. Swift Compiler Documentation: The official guide to Swift compiler performance, including details on modes, diagnostics, and optimization flags.
2. Apple’s Swift.org: Overview of Swift’s compiler design and its integration with LLVM.
3. WWDC 2020: Dive Into Swift Compiler Diagnostics: A session explaining how the compiler processes code and generates diagnostics.
4. LLVM Project: Learn about LLVM, the backend infrastructure powering Swift’s code generation and optimizations.

These resources provide foundational knowledge for mastering Swift’s compilation pipeline. Happy coding! 🛠️