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

The problem Build Time Analyzer for Xcode targets

Swift compile times grow quietly. A single expression with heavy type inference can add seconds to every incremental build, and the Xcode build log does not rank functions by how long they took to type-check. Build Time Analyzer for Xcode is a macOS app that, in the README's words, "shows you a break down of Swift build times". That is the whole scope.

The audience is narrow and specific: Swift developers on macOS who own a codebase that has become slow to compile and who want to know which functions are responsible. It is not a CI dashboard, not a team metrics service, and not a profiler for runtime performance. The README links to two Medium posts for context, which is where the author put the explanation of why the tool exists. The repository itself is a single Xcode project with an app target, a test target, and a screenshots folder.

How the app reads Swift build times

The repository layout tells you most of what is verifiable here. BuildTimeAnalyzer.xcodeproj is the project file, BuildTimeAnalyzer/ holds the app sources, and BuildTimeAnalyzerTests/ holds the tests. The README does not document the parsing logic, the input format, or which compiler flags it depends on, so anything beyond the app's stated purpose is an assumption.

What the README does commit to is the interaction model: "Open up the app and follow the instructions." The screenshot in Screenshots/ is the only visual reference in the repository. Practically, that means the app expects you to hand it build output or a build log and then presents a ranked breakdown of compile times by function. If you want to know exactly which file it reads or which environment it needs, the README is silent, and you would have to read the Swift sources in BuildTimeAnalyzer/ to find out. That is a real cost for a tool whose value depends on trusting the numbers it prints.

Installing Build Time Analyzer for Xcode from source

There is no Homebrew formula, no release binary, and no package manager entry documented in the README. The installation instructions are one sentence: "Download the code and open it in Xcode, archive the project and export the build. Easy, right?" So the first step is cloning the repository.

git clone https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode.git
cd BuildTimeAnalyzer-for-Xcode

From there, open the Xcode project that sits at the repository root.

open BuildTimeAnalyzer.xcodeproj

In Xcode, select the BuildTimeAnalyzer scheme, archive it, and export the build as the README describes. What you should end up with is a macOS app you can launch. The README gives no minimum Xcode version, no macOS version, and no signing guidance, so expect to resolve code signing for your own machine yourself. Once the app is running, the README's only instruction is to follow the on-screen steps and read the breakdown it produces.

Where Build Time Analyzer for Xcode falls short

The repository is not archived, and the last push was on 2026-03-08, so the code has seen activity recently. The releases tell a different story: v1.0.12 shipped on 2019-06-26, v1.0.11 on 2018-09-23, and v1.0.10 on 2017-12-02. If you install from a tagged release, you are installing something from 2019. If you build from master, you are building untagged code. Neither path is described in the README, which does not mention releases at all.

The bigger limitation is scope. The app gives you a snapshot of one build. It does not store history, it does not compare builds over time, and the README documents no export format, no CLI, and no CI integration. If your question is "did this refactor make the build slower than last month", this tool cannot answer it. It also cannot help with non-Swift targets, since the README frames it entirely around Swift build times. And because installation means archiving an Xcode project by hand, distributing it to a team is a manual exercise the README does not address.

Build Time Analyzer for Xcode compared with XCMetrics

XCMetrics is the other name that comes up when people search around this project, and the two solve the same underlying problem from opposite directions. Build Time Analyzer for Xcode is a local macOS app you build from source and run on your own machine to inspect a single build. XCMetrics is a service-oriented approach: it collects build metrics from Xcode and other tooling and aggregates them, which is what you want if the question is about a team or a trend rather than one developer's current build.

The trade-off is setup cost against persistence. The app here asks for almost nothing beyond Xcode and a clone, and gives you an immediate ranked list. A metrics pipeline asks for infrastructure and ongoing operation, and gives you history you can query later. If you only need to find the three functions wrecking your incremental builds this afternoon, the app is the shorter path. If you need to prove that build times improved after a change, the app has no mechanism for that, and the README does not pretend otherwise.

Maintenance cost and the MIT licence

The licence in the README is the MIT text, with a copyright line covering 2016 to 2026, Robert Gummesson. That permits redistribution and modification provided the copyright notice and permission notice are retained, and it disclaims warranty. The README's licence block is the standard MIT body; the repository's LICENSE file is the authoritative copy if the two ever diverge.

The maintenance picture is mixed in a way worth stating plainly. The repository is not archived and the last push was on 2026-03-08, so someone is still touching it. But the most recent release, v1.0.12, is from 2019-06-26, and the README's contribution section says only that the author is "open to code contributions". There is no changelog, no deprecation notice, and no stated support policy. If you build from master, budget for the possibility that you are the one who fixes it when a future Xcode changes the build output format. That is the real upgrade cost here: not a version bump, but a possible parsing fix you write yourself.

Editorial conclusion

Adopt it if you work on a Swift codebase with slow incremental builds and you want per-function compile times without wiring up a CI metrics pipeline. Do not adopt it if you need continuous measurement across a team, long-term trend data, or anything you can install from a package manager, because the README documents none of those. Before relying on it, verify that the app builds and archives cleanly under your current Xcode, since the last release, v1.0.12, dates from 2019-06-26, and the README's installation path assumes you archive and export the project yourself.

Frequently asked questions

Official sources

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