How to Optimize Your iOS Project Build Time
Vica Cotoarba
Head of Mobile Development
Reading time: 7 min
Published: May 16, 2022
Key takeaways
- Measure first: use Xcode's Build with Timing Summary or the ShowBuildOperationDuration terminal flag.
- Tune project settings like Build Active Architecture Only, Optimization Level, and Incremental compilation.
- Add -warn-long-function-bodies and -warn-long-expression-type-checking flags to surface slow Swift code.
- Use the open-source Build Time Analyzer to rank the most expensive functions by compile time.
- Refactor complex expressions and add explicit type annotations to cut type-checking time dramatically.
You are an iOS developer, and your project builds slowly. What are your options?
One option is to watch videos while it compiles, but we all know how much that hurts productivity. Another is to buy faster hardware, like a Mac with the latest Apple silicon (M5). As engineers, though, we know scalability does not come from raw power alone. It also comes from software optimizations and efficiency. So let's see what we can do on that side to speed up slow iOS builds.
How to measure build times in Xcode
Before you optimize anything, you need to measure it. Xcode gives you two easy ways to do this.
The detailed way
In Xcode, go to Product > Perform Action > Build with Timing Summary. This runs a build that records each step and shows a total in seconds at the end.
To read the summary, open the Report Navigator, the last tab in the left-side menu. It looks like this:
The quick way
In a Terminal window, run this command:
defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES
The next time you build, Xcode shows the time spent right in the toolbar, like this:
You can revert this setting with the same command by writing NO instead of YES.
Part 1: Project setup tips
Let's start with a few settings at the project level that affect build times.
Select your target and open the Build Settings tab. There are a few things to configure here.
First, search for Build Active Architecture Only. Set it to Yes for Debug and No for Release. In Debug mode, you only need to build for the simulator or device you are using right now, not for all of them.
Second, search for Optimization Level. It can be set to No Optimization, Optimize for Speed, or Optimize for Size. If you do not need to debug right away, set Debug to Optimize for Speed. Usually, though, you will want to leave it on No Optimization so you can use breakpoints and inspect variables.
Also make sure the compilation mode is set to Incremental rather than Whole Module for Debug. That way Xcode rebuilds only your changed files instead of the entire project every time.
Part 2: Code analysis
Once your project settings are dialed in, it is time for code analysis. Inspecting and improving your functions and calculations can have a big impact on build times.
How do you inspect every function and expression? Set a couple of flags at the target level, each with a maximum time in milliseconds. Xcode then warns you about any function or expression that exceeds those times. Go to Build Settings > Other Swift Flags and add:
-Xfrontend -warn-long-function-bodies=100-Xfrontend -warn-long-expression-type-checking=50
Now any function that takes more than 100ms to type-check gets a warning, and so does any expression over 50ms. You can pick other values, but these are a good starting point.
You can tackle these warnings one by one. To go further, though, it helps to see how many times each expensive function occurs. A free, open-source tool does exactly that: the Build Time Analyzer for Xcode.
The installation steps are in the repository. You also need to add one more flag to the Other Swift Flags section: -Xfrontend -debug-time-function-bodies. Then build your project, and the tool reads the build summary from Derived Data. Here is what it looks like:
With the Build Time Analyzer, you can focus directly on the most expensive parts of your code. Let's look at some changes that improve the example above.
Part 3: Code optimizations
First, avoid complex, compound statements. We can change this code:
to this:
This change alone improves the build time from 2232ms to 738ms. The type-check time dropped from 248ms to 82ms, and since this function has nine occurrences, the total build time improved a lot.
Another helpful trick is declaring the type of each variable or constant. If we change this code:
to this:
the build time for this function is cut in half. Since it has nine occurrences, the total drops to 1503ms from 3042ms.
In general, aim for clear, readable syntax, even if it is slightly longer. Just do not swing to the other extreme with twice as much code as you need. For example, the nil-coalescing operator increases build time compared to the "if let" alternative:
Here it is 52ms versus 156ms. A similar thing happens with the ternary operator, which is harder to parse than a traditional if-else. Other examples include using string interpolation instead of concatenation, and using array.append(contentsOf:) instead of array + [newArray].
Summary
You can improve iOS build times in several ways. Some relate to the general project setup, and others are specific to your Swift code choices.
The key is to measure your build times first, experiment with those time limits, and then focus on the code that hurts build times the most. Some changes may seem minor, saving only a second, but they add up and make a real difference over time.
Want to keep going? Our mobile development team can help, and you can read more of our mobile development articles. Stay curious, and see you next time.
