Here are some of the visualizations we built out of the data we collected. The post_actions.sh script internally uses XCLogParser, & at the end of the script makes sure the script executes in the background and doesn’t add any extra overhead on the build times. Xcode’s build post-actions run script phase, the above run script can be found by going into Scheme editor > Expand Build action. The below image shows Xcode’s post_build actions script. So we were able to parse build data using XCLogParser and push it to our in-house dashboarding system. Xcode triggers this action as soon as the build completes. We added XCLogparser in Xcode’s post-build script. XCLogparser is an open-source CLI tool by Spotify which parses xcactivitylog file (A log file created by the xcodebuild system per build and stored in DerivedData, which has all the information related to the particular build) and gives a detailed build report in json or html format. To analyze the problem better we needed to collect the data from developer machines, such as targets built part of a build, time-taken by each target, cache utilization, etc. Also, developers spend most of their time building the app incrementally hence any improvements we make to incremental build time have a direct impact on the developer productivity and the experience.īetter developer experience would mean that developers can ship features faster and this, in turn, makes the business stay ahead of the competition. Since our incremental build time was considerably high, reducing it became our priority. Incremental build time graph that shows the weekly 95th percentile trend The below trendline shows our incremental build time over a period of time. What was our incremental build time before? 🤔īefore starting this project, our 95th percentile incremental build time was ~11 mins. Here are the statistics around what was our incremental build time before. The project repository structure looks something like this:Ĭonsumer app’s main repository has Xcode workspace which includes all of the module’s Xcode projects as subprojects.Īt Gojek we are a developer experience team focused on solving build and infrastructure-related problems to provide the best possible experience for our developers and improve their productivity. We have a Multi-repo setup with 40+ git submodules. Let’s dive into the details to understand more, well before that, a little bit of background about the problem. It’s amazing how just tweaking the Xcode build settings helped us achieve such a massive reduction of 50%. The below graph shows the amazing results we achieved. Our incremental build time was reduced from 11 mins to 5 mins. All of this helped us achieve a massive 50% reduction in build time 🎉 🎊. We used XCLogparser to analyze Xcode build logs, unearthed the hidden information there, corrected misconfigurations, and also changed the way we load Cocoapods. This was affecting developer productivity and also not a good developer experience. To give you an idea about the problem, our 95th percentile incremental build time was ~11 mins 📈, which is quite high. To keep up with the fast-paced dev environment, improving build time was the need of the hour for us. This large setup poses its own set of challenges and the build times are one of the topmost concerns. We use the “God workspace” model for development, i.e., all the modules are added as subprojects to one single Xcode workspace.

To give you a sneak peek into our CI stats, on a busy day we run around 300–350 CI Pipelines.

We are a team of around 100 iOS Engineers pushing hundreds of commits every day to ship features to the Gojek Super App. Gojek’s iOS consumer app is a multi-repo setup with 40+ git submodules.

Xcode project build settings