Build Time Analyzer for Xcode: reading Swift compile time from a macOS app

A build times breakdown for Swift, not a general Xcode profiler

Xcode tells you a build took forty seconds. It does not tell you that one file in Models.swift took nine of them. Build Time Analyzer exists to fill that gap. It is a macOS app, written in Swift, whose job is a break down of Swift build times, so the answer to "why is this build slow" has a name attached to it.

The audience is narrow and self-selecting: developers on a Mac, working in Swift, whose build has become slow enough to notice and slow enough that they have started guessing. The guess is usually wrong, because compilation cost is uneven across a codebase. A handful of large files with many generic specialisations, or a file that pulls in a deep chain of extensions, can dominate a build that otherwise looks fine in aggregate.

It is not an instrument for profiling your app at runtime, and it is not a general build system monitor. The repository says nothing about either. What sits in the project directory is small: BuildTimeAnalyzer.xcodeproj, the BuildTimeAnalyzer app target, BuildTimeAnalyzerTests, a README, and a Screenshots folder. There is no server component, no configuration file, no CLI.

What the repository actually contains, and what it does not

Worth knowing before you start: this is a small repository. The top-level entries are .gitignore, .travis.yml, BuildTimeAnalyzer.xcodeproj, BuildTimeAnalyzer, BuildTimeAnalyzerTests, LICENSE, README.md, and Screenshots. The primary language is Swift and the default branch is master.

Two things stand out. First, .travis.yml means continuous integration was configured for the project itself, not that BuildTimeAnalyzer monitors your CI. Second, there is no configuration schema, no environment variable, and no command line surface anywhere in the layout. If you were expecting a tool you can point at a build log from a script, this is not it. There is nothing here to point.

The consequence for an evaluation is that the surface area you are adopting is small, and so is the evidence available about how the app behaves. The README does not document which Xcode log formats it reads, whether it handles the newer build system output, or how it behaves on a build that failed part way through.

Installing it means building it yourself from the Xcode project

The README documents no Homebrew formula or installer, and there is no package manifest in the repository. The README gives the whole procedure in one sentence: download the code, open it in Xcode, archive the project and export the build. The "Easy, right?" at the end of that line is the author's own.

In practice the path is: clone the repository, open BuildTimeAnalyzer.xcodeproj in Xcode, use the Archive action, and export the resulting app from the Organizer. Then launch the exported app and follow the instructions it shows. Every one of those steps is standard Xcode procedure rather than something specific to this project.

One practical cost comes with that: you need a Mac with Xcode installed, which is obvious but worth stating because it rules out any CI runner or remote build machine that has no GUI session.

First run: open the app and follow the instructions it displays

The usage section of the README is one sentence long. Open up the app and follow the instructions. That is the entire documented workflow, and the app is expected to teach itself.

What that means in practice is that the app is self-explanatory once launched: it presents itself, and you act on what it shows. For a project this small, in-app guidance is a defensible choice, since there is no flag to misremember and no configuration to get wrong. It is also a documentation gap for anyone trying to answer a colleague's question over chat, because there is no command line equivalent to paste.

The screenshots directory at the repository root is the closest thing to a visual reference. Between that and the two Medium posts linked from the overview, you can see what the output looks like before you install anything. The author, Robert Gummesson, points at both posts for context.

Building from source is the only install path, and that is the first limitation

Because the README's only install instruction is to build from source and there is no package manager entry, every user following it compiles the analyzer themselves. That is fine for a developer with a Mac and an hour to spare. It is a problem for a team that wants one copy on a build server, or for anyone who wants the tool available before deciding whether they like it.

The licence is MIT, so redistribution in source or binary form is permitted with the copyright notice retained. That removes any legal obstacle to shipping an internally built copy. It does nothing about the engineering cost of a binary you have to rebuild by hand.

Where xcodebuild and xcresult differ from reading the app's report

Xcode ships its own instrumentation, and it is the sensible comparison point. Two common comparison points are the Xcode build Timeline and XCMetrics, neither of which is part of this repository.

The difference in approach is real. Xcode's Timeline lives inside the IDE, attached to the current build, and shows the phases of that build as Xcode understood them. XCMetrics parses the xcresult bundle that Xcode emits, which means it can run headless and its data can be collected in a pipeline. Build Time Analyzer takes neither route: it is a separate macOS app that a developer launches and reads, with no log file, no result bundle, and no integration point in the repository layout.

So the choice is not really about accuracy. If you want build data collected automatically on every CI run, XCMetrics is the tool shaped for that. If you want to look at one slow local build and see where the Swift build time went, this app does that and stops there. Running both is pointless; they answer different questions.

It reads local builds only, so it cannot live in your pipeline

The clearest failure mode is that there is no non-interactive mode. Nothing in the repository exposes a command line entry point, an output format, or a way to feed a build log in from elsewhere.

That rules out the case that matters most for a growing team: tracking whether a change made the build slower. Without a scriptable path, the only way to catch a regression is for a developer to notice, open the app, and remember to run it. Build time regressions are exactly the kind of problem that gets missed, because every individual build still finishes and nobody is timing it.

A second limit is narrower and more annoying. The README's only install path is a local build, so each installation following it is a one-off build on that developer's own machine, and two people can end up running binaries built from different commits. Before trusting a result, check which commit you actually built from.

Editorial conclusion

Adopt it if your Swift build has slowed to the point where you no longer know which file to blame, and you are willing to archive the Xcode project yourself before every upgrade. Skip it if you need a measurement tool that runs headless in continuous integration, because no command line entry point is documented. Verify first that the exported app still launches on your current macOS and Xcode version, and record which commit you built the app from, because two developers can otherwise end up comparing results from different sources.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. RobertGummesson/BuildTimeAnalyzer-for-Xcode on GitHub