Reducing Our Build Time by 50%
Article Summary
Gojek's iOS team was bleeding 11 minutes per build. 100 engineers, 350 daily CI pipelines, and a productivity crisis that demanded action.
The Gojek engineering team tackled their massive iOS build time problem using XCLogParser to analyze build logs, a custom Slack workflow for real-time developer feedback, and deep debugging of Xcode's build system. Their multi-repo setup with 40+ submodules made the challenge even harder.
Key Takeaways
- Cut build time from 11 minutes to 5 minutes (50% reduction) by fixing Xcode settings
- Recursive FRAMEWORK_SEARCH_PATHS caused double clean builds and wasted 15 minutes each time
- Switching simulators triggered full rebuilds until they changed CocoaPods to static frameworks
- Custom Slack bot collected micro-feedback from developers immediately after slow builds
- Saved 60 hours of developer time per week across the team
Three Xcode configuration fixes (recursive search paths, inconsistent scheme settings, and CocoaPods loading) delivered a 50% build time reduction and 60 hours saved weekly.
About This Article
Gojek's iOS codebase has over 40 submodules with inconsistent build settings across schemes. When developers switched between the main Gojek-Integration scheme and module-specific ones like Launchpad, it triggered unnecessary rebuilds.
Sanju Naik's team analyzed ModuleName_vers.c files to debug compiler inputs. They found that the Launchpad scheme was missing code coverage flags. After syncing build settings across all Xcode projects in the workspace, the inconsistencies were resolved.
Switching between schemes now takes 2 minutes instead of 13 minutes, an 80% improvement. Enabling gather coverage for all schemes also stopped redundant recompilation across dependent modules.