Hate to Wait: How Skyscanner Used Module Caching to Cut App Build Speed in Half
Article Summary
Skyscanner's iOS developers were waiting hours for builds to complete. Their CI/CD team cut that time in half with a clever caching strategy.
Aron Pammer, Skyscanner's CI/CD specialist, shares how the team tackled their biggest developer pain point: build speed. Working with a modular architecture of ~150 module targets, they implemented external pod caching and internal module caching to dramatically reduce wait times.
Key Takeaways
- External pod caching reduced build time by 25% without rebuilding unchanged dependencies
- Internal module caching cut clean builds from 40 minutes to under 20 minutes
- Swift compiler quirks required caching swiftmodule files with absolute path workarounds
- Cache invalidation strategy rebuilds dependent modules when signatures change
- Team uses git hashes for cache keys on CI for instant, accurate lookups
By caching both external pods and internal modules, Skyscanner reduced iOS build times from 40 minutes to under 20 minutes with high cache hit rates.
About This Article
Building Skyscanner's iOS app was painfully slow. Clean builds on an 8-core Mac Pro took 40 minutes, though ccache helped cut that down to 15 minutes.
Aron Pammer's team built a two-tier caching system. They zipped up built CocoaPods artifacts and cached them based on Podfile hashes. For internal modules, they stored .a files and Swift swiftmodule/swiftdoc files using git-based cache keys.
The approach worked well. With good hit rates on both ccache and the internal module cache, Skyscanner got clean builds down from 40 minutes to under 20 minutes. That's a 50% improvement for their roughly 150 module targets.