As projects grow, build times can become problematic. However, there are several tweaks you can make to Xcode that can decrease the amount of time it takes for builds to complete without any extra work.

UPDATE: This post has been updated to reflect changes in Xcode 14. While many of the same principles apply to speeding up Xcode builds, Xcode 14 tackles the problem of slow builds head on with a variety of new features.

Measure the build time of each element in your project:

Xcode 14 allows developers to easily measure their iOS and macOS build times in order to identify potential bottlenecks, and to allow for easier optimization for faster builds. Xcode’s new Build Timeline feature will help you to identify which portions of your application are building in parallel, and whether there are any unnecessary steps in the build process that are slowing things down within a particular portion of the build. To view the Build Timeline for a particular target in your project, right click on the target and select “View in Timeline.”

Only run custom scripts when needed:

By default, Xcode will run any custom build scripts included in your project during every build – including incremental builds. This may not be needed if your custom scripts are performing actions like setting environment variables for the build or other preparatory steps for the larger build process. To control when custom scripts are executed during the build process, you will need to provide at least one input and one output file for each script, as Xcode will execute each script that meets any of these conditions:

  • Your script doesn’t have any input files.
  • Your script doesn’t have any output files.
  • Your script’s input files changed.
  • Your script’s output files are missing.

Increase the thread count:

By default, Xcode typically uses the same number of threads as the number of cores in the machine’s CPU. However, you can dramatically reduce build times – in some instances by a full 30% - by increasing the thread count beyond the default. This takes advantage of some processors’ ability to multi-thread or simulate additional cores. Keep in mind that you may need to experiment to determine if there are diminishing returns for parallelized builds with your code base, and then adjust the thread count accordingly.

Tweak the iOS simulator:

The Apple iOS test simulator lets you test across different software and hardware combinations (but only from a Mac). By using Physical Size or Pixel Accurate window sizes, you can reduce both the size of your tests and the time it takes for them to complete. These configuration changes use less resources and help prevent tests from slowing down simulating pixels that no one will ever see.  

You can find configuration instructions here: Adjusting the Xcode iPhone simulator scale and size

Use parallelized builds:

Parallelized builds can reduce total Xcode build times by building components of the app that do not depend on each other at the same time.  For projects with many smaller dependencies that can easily be run in parallel, this can offer significant time savings. Gains will obviously depend on how your code is written, but it is worth testing since parallelized builds aren’t enabled by default.  You can enable parallel builds by editing the Xcode Scheme and checking ‘Parallel Builds’ in the build action of the scheme.

You can find more detail on leveraging parallelized builds here:  When should I check “Parallelize Build” for an Xcode scheme?

Bigger build machines:

This one isn’t technically an Xcode tweak, but bigger build machines do have an outsized impact when attempting to speed up builds. More computing power simply translates into faster completion of processes and builds. Our testing shows that moving from a dual-core Mac mini to a 12-core Mac Pro can give a 3x speedup without any additional effort.  When you’re ready to upgrade or scale your Mac infrastructure, feel free to contact us at MacStadium.

Increase your clock speed:

With the recent Xcode 11 release, more and more builds are showing signs of single-threaded-like behavior. That is, some elements are not being run in parallel like before. In this event, hardware with more cores is not necessarily better. MacStadium is currently finding customers can complete builds faster by picking a 6-core 2013 Mac Pro, which has a 3.5 GHz clock speed over the 12-core 2013 Mac Pro at 2.7 GHz. Individual builds vary, but this a factor to check.

Enable caching:

Xcode now supports caching automatically as long as users do not run the Product > Clean feature before builds. This is a great improvement for local developers who are the primary audience for Apple’s continued development. For teams, the caching features of Bazel make it a very attractive choice. The implementation of Bazel is not always easy, but implementing Bazel for iOS and macOS builds was the specific focus of the 2019 BazelCon. All the talks are now on YouTube.

‍Additional Resources:

Of course, these are only a few of the suggestions you can use to speed your Xcode build times. The following resources can provide additional information and suggestions on improving your Xcode build times.

Share this article


Orka, Orka Workspace and Orka Pulse are trademarks of MacStadium, Inc. Apple, Mac, Mac mini, Mac Pro, Mac Studio, and macOS are trademarks of Apple Inc. The names and logos of third-party products and companies shown on the website are the property of their respective owners and may also be trademarked.

©2023 MacStadium, Inc. is a U.S. corporation headquartered at 3525 Piedmont Road, NE, Building 7, Suite 700, Atlanta, GA 30305. MacStadium, Ltd. is registered in Ireland, company no. 562354.