Awesome
Optimizing Swift build times
Collection of advice on optimizing compile times of Swift projects.
Swift is constantly improving ❤️. For the time being, though, long compile times persist as a big issue when working on medium-to-large apps. The goal of this project is to gather all there is that can help you shorten your build times.
👷🏻 Maintainer: Arek Holko. Anything missing? Issues and pull requests welcomed!
Table of contents
- Incremental Compilation Mode with No Optimization
- Type checking of functions and expressions
- Slowly compiling files
- Build active architecture only
- dSYM generation
- Third-party dependencies
- Modularization
- XIBs
- Xcode Schemes
- Use the new Xcode build system
- Showing build times in Xcode
Incremental Compilation Mode with No Optimization
Until Xcode 10, it was common to enable Whole Module Optimization to speed up Debug builds. It was a workaround that's no longer needed in Xcode 10!
Currently, the recommended setup is to have Incremental
Compilation Mode
set for Debug builds and Whole Module
for Release builds. Also, No Optimization
should be chosen for Optimization Level
setting of Debug builds.
📖 Sources:
Type checking of functions and expressions
Swift build times are slow mostly because of expensive type checking. By default Xcode doesn't show code that's slow to compile. You can instruct it to show slowly compiling functions and expressions, though by adding:
-Xfrontend -warn-long-function-bodies=100
(100
means 100ms here, you should experiment with this value depending on your computer speed and project)-Xfrontend -warn-long-expression-type-checking=100
to Other Swift Flags
in build settings:
Build again and you should now see warnings like these:
<img src="assets/xcode-warning@2x.png" width="801">Next step is to address code that Swift compiler has problems with. John Sundell and Robert Gummesson are here to help you with that.
📖 Sources:
- Guarding Against Long Compiles
- Measuring Swift compile times in Xcode 9 · Jesse Squires
- Improving Swift compile times — Swift by Sundell
- Swift build time optimizations — Part 2
Slowly compiling files
The previous section described working on an expression- and function-level but it’s often interesting to know compile times of whole files too.
There’s no UI in Xcode for that, though, so you have to build the project from the CLI with correct flags set:
xcodebuild -destination 'platform=iOS Simulator,name=iPhone 8' \
-sdk iphonesimulator -project YourProject.xcodeproj \
-scheme YourScheme -configuration Debug \
clean build \
OTHER_SWIFT_FLAGS="-driver-time-compilation \
-Xfrontend -debug-time-function-bodies \
-Xfrontend -debug-time-compilation" | \
tee profile.log
(Replace -project YourProject.xcodeproj
with -workspace YourProject.xcworkspace
if you use a workspace.)
Then extract the interesting statistics using:
awk '/Driver Compilation Time/,/Total$/ { print }' profile.log | \
grep compile | \
cut -c 55- | \
sed -e 's/^ *//;s/ (.*%) compile / /;s/ [^ ]*Bridging-Header.h$//' | \
sed -e "s|$(pwd)/||" | \
sort -rn | \
tee slowest.log
You’ll end up with slowest.log
file containing list of all files in the project, along with their compile times. Example:
2.7288 ( 0.3%) {compile: Account.o <= Account.swift }
2.7221 ( 0.3%) {compile: MessageTag.o <= MessageTag.swift }
2.7089 ( 0.3%) {compile: EdgeShadowLayer.o <= EdgeShadowLayer.swift }
2.4605 ( 0.3%) {compile: SlideInPresentationAnimator.o <= SlideInPresentationAnimator.swift }
📖 Sources:
Build active architecture only
This setting is a default but you should double check that it’s correct. Your project should build only active architecture in Debug configuration.
<img src="assets/active-arch@2x.png" width="488">📖 Sources:
dSYM generation
By default in new projects, dSYM files aren’t generated at all for Debug builds. However, it’s sometimes useful to have them available when running on a device – to be able to analyze crashes happening without the debugger attached.
Recommended setup:
<img src="assets/dsym@2x.png" width="536">📖 Sources:
Third-party dependencies
There are two ways you can embed third-party dependencies in your projects:
- as a source that gets compiled each time you perform a clean build of your project (examples: CocoaPods, git submodules, copy-pasted code, internal libraries in subprojects that the app target depends on)
- as a prebuilt framework/library (examples: Carthage, static library distributed by a vendor that doesn’t want to provide the source code)
CocoaPods being the most popular dependency manager for iOS by design leads to longer compile times, as the source code of 3rd-party libraries in most cases gets compiled each time you perform a clean build. In general you shouldn’t have to do that often but in reality, you do (e.g. because of switching branches, Xcode bugs, etc.).
Carthage, even though it’s harder to use, is a better choice if you care about build times. You build external dependencies only when you change something in the dependency list (add a new framework, update a framework to a newer version, etc.). That may take 5 or 15 minutes to complete but you do it a lot less often than building code embedded with CocoaPods. You can even skip those initial minutes using Rome.
📖 Sources:
- time spent waiting for Xcode to finish builds 😅
Modularization
Incremental compilation in Swift isn’t perfect. There are projects where changing one string somewhere causes almost a whole project to get recompiled during an incremental build. It’s something that can be debugged and improved but a good tooling for that isn’t available yet.
To avoid issues like that, you should consider splitting your app into modules. In iOS, these are either: dynamic frameworks or static libraries (support for Swift was added in Xcode 9).
Let’s say your app target depends on an internal framework called DatabaseKit
. The main guarantee of this approach is that when you change something in your app project, DatabaseKit
won’t get recompiled during an incremental build.
📖 Sources:
XIBs
XIBs/storyboards vs. code. 🔥 It’s as hot a topic as they go but let’s not discuss it fully here. What’s interesting is that when you change the contents of a file in Interface Builder, only that file gets compiled (to NIB format). On the other hand, Swift compiler may decide to recompile a big part of your project when you change e.g. a single line in a public method in a UIView
subclass.
📖 Sources:
Xcode Schemes
Let’s say we have a common project setup with 3 targets:
App
AppTests
AppUITests
Working with only one scheme is fine but we can do better. The setup we’ve been using recently consists of three schemes:
App
Builds only the app on cmd-B. Runs only unit tests. Useful for short iterations, e.g. on a UI code, as only the needed code gets built.
<img src="assets/app-scheme@2x.png" width="600">App - Unit Test Flow
Builds both the app and unit test target. Runs only unit tests. Useful when working on code related to unit tests, because you find about compile errors in tests immediately after building a project, not even having to run them!
This scheme is useful when your UI tests take too long to run them often.
<img src="assets/app-unit-test-flow@2x.png" width="600">App - All Tests Flow
Builds the app and all test targets. Runs all tests. Useful when working on code close to UI which impacts UI tests.
<img src="assets/app-all-tests-flow@2x.png" width="600">📖 Sources:
Use the new Xcode build system
In Xcode 9 Apple introduced a new build system. To enable it, go to Workspace or Project Settings from the File menu in Xcode. There you can switch build systems to the new build system.
<img src="assets/new_build_system@2x.png" width="536">📖 Sources:
Showing build times in Xcode
Finally, to be able to actually know whether your build times are improving, you should enable showing them in Xcode’s UI. To do that, run this from the command line:
$ defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES
Once done, after building a project (cmd-B) you should see:
<img src="assets/time@2x.png" width="348">I recommend comparing build times under same conditions each time, e.g.
- Quit Xcode.
- Clear Derived Data (
$ rm -rf ~/Library/Developer/Xcode/DerivedData
). - Open your project in Xcode.
- Start a build either immediately after Xcode opens or after indexing phase completes. The first approach seems to be more representative because starting with Xcode 9 building also performs indexing.
Alternatively, you can time builds from the command line:
$ time xcodebuild other params
📖 Sources: