Build time in iOS
Hi there! My name is Yura and I’m an iOS-developer at hh.ru. In this article, we’ll touch on one of the most important metrics for iOS developers — build time. I’ll speak on how and why we collect build time metrics and what we do with them later.
Watch the video version here.
What’s the problem with a long build?
Long builds take you out of the task context that we’re working on. Knowing that the project will take a long time to build, you can afford to get distracted, go get a cup of coffee, and get caught up in chatting, and scrolling through social networks. And then 30 minutes later you remember that you were supposed to check on that bug instead of flipping through your Twitter feed or reading another Wikipedia article about anemones.
So first, we’re going to figure out how to measure build time. After all, if we don’t know how bad it is, how will we know if it got better?
How long does it take to build?
There are two very simple ways to measure the time spent on the build directly in the Xcode interface. These are turning on the private setting ShowBuildOperationDuration and running the build through the menu Product -> Perform Action -> Build With Timing Summary.
In the first case, the final build time will be displayed in the Xcode status bar, and in the second case, we will get a mini-report on the different stages of the build, which can be viewed in Report Navigator. It displays the most interesting and complete build report available to us, but can we get it out of Xcode?
Going into xcactivitylog
The most detailed report on the build has the .xcactivitylog format. It’s in DerivedData, in the Logs folder. And it’s pretty complicated, but we have a video that explains how this format works. But don’t rush to roll up your sleeves and parse everything with your own hands, because it’s already been done for us.
There is XCLogParser to parse these reports, which parses the reports and provides them to us in a convenient form for further work. For example, in the form of json, which is convenient to parse, or in html, which is convenient to view. The full list of formats is available here.
Let’s take a closer look at the html report. Among other things, it gives us access to the build timeline of the whole project, as well as individual targets. And we can delve into each target and see the details. These timelines are incredibly cool because they let us see what project parts are holding up the entire build.
For example, in this part of the report, you can see that for a while we have been building only one target, the UI, on which all our product features depend. And at the same time, nothing else is build in parallel. In short, we are just wasting time.
This report also allows us to see in detail the process of compiling individual targets, files, build phases, and other phases of the project’s build.
And yeah, everything we see in such a report will also be available in json format, from which you can manually get everything you need.
What are we collecting?
We are currently collecting the following information on CI builds:
- Date
- Build duration
- Duration of individual phases
- Application schema
- Build configuration (debug, release, adHoc)
- Clean build
- Xcode version
- Device model
- User name
- CI agent ID
We receive most of this information from the report generated by XCLogParser, but we add little information about the system to understand in what environment the build took place in.
Where and how do we store it?
In our case, we use influxdb to store data and Grafana to display graphs and reports.
Let’s work out what we can see in Grafana. We have a table with complete information on all the latest builds, where we can see all the data we were able to collect.
There is a separate schedule where we keep track of the duration of certain build phases, which we keep a special track of. For example, we keep track of the time spent on code linting and code generation, because we already had problems with them, and we spotted them through monitoring.
And we also have graphs of the build time of our projects on different CI machines. For example, this graph shows how long it takes to build our application for employers on each of the CI agents. And you can clearly see that builds on the M1 mac mini are about a third faster than on older intel macs.
But when we opened this graph before preparing this article, we were very surprised. It turns out that project build time has slowed down quite a bit lately, and we missed it.
It turned out we accidentally integrated an unnecessary feature — that caused a sudden jump in build time. After disabling them the time has stabilized. Graphs like this allow you to notice build time issues earlier.
Let’s summarize
Measure the build time. It’s a good idea to start doing this as early as possible before you make any changes to your project. There are many different tools for measuring build time today, you just need to choose the one that is right for you. And if you have already set up a collection of metrics, don’t forget to keep track of them, so as not to accidentally overlook major changes.
Sounds fun? Subscribe to our news channel on telegram and “HHella cool stories” channel so you won’t miss new videos, articles, and other news. And you can ask our engineers any questions on any topic in the comments or in hh developers’ telegram-chat.
