Build Time Analysis

Long build times have plagued Swift projects since the first introduction of the language and there has been little improvement since. An often cited cause is Swift’s type inference, another one the fact that Swift code is first compiled into dylibs which are later linked into the app bundle. And of course there are no pre-compiled headers – everything gets compiled every time. Xcode finally has become seriously bloated and is bug-ridden. With a rating of 2 out of five stars in the app store it is not hard to deduce what developers really think.

Enter the BuildTimeAnalyzer for Xcode. London-based developer Robert Gummesson wanted to know where all that time went and wrote a tool to analyze the build process. His results were a huge surprise not only to the Swift community but also to Apple and the Swift team. Turns out that a bunch of language features (i.e. the nil coalescing operator, the ternary operator) could cause huge build time increases. Differences also became apparent between the versions of Swift used. And no – things did not necessarily get better with Swift 3.x.

There are no golden rules and every project is different, but if compile times become an issue, the BuildTimeAnalyzer is a great way to identify potential bottlenecks. The tool needs to be enabled in Xcode via compiler flag (Xcode 8) and runs as its own application. A plugin for Xcode 7 is also available from the project’s GitHub page.

Swift compilation times will not get better any time soon. So as developers we might want to reevaluate our habits. Frequent compiles carry a high penalty these days. It seems we have come full circle, but like in the olden times of punch cards it pays to check and double-check our code before running it. The paradigm of “letting the compiler do the work” many of us have adopted in the fast days of Obj-C programming is clearly no longer feasible.