Scaling iOS at Bumble (Part 1)
Article Summary
Bumble's iOS team faced a critical choice: which build system could handle hundreds of modules and future growth without crushing developer productivity?
After identifying scaling problems in their iOS codebase, Bumble's engineering team conducted a rigorous evaluation of three build systems: Swift Package Manager, Tuist, and Bazel. They built full proof-of-concepts for each, measuring performance under simulated future growth scenarios.
Key Takeaways
- SPM's graph resolution caused 10+ second waits on routine file operations
- Tuist generated projects performed equivalently to handcrafted Xcode projects
- Bazel had the steepest learning curve but showed perceptible caching benefits
- Custom converter tool automated manifest generation across all three systems
- Performance testing simulated 5 year growth by cloning median sized modules
Each tool presented distinct tradeoffs between developer experience, performance characteristics, and implementation complexity, with no clear winner emerging from technical metrics alone.
About This Article
Bumble's SPM proof-of-concept had serious performance issues. The 'Create build description' stage would hang for over 200 seconds at first, and cached graph resolution caused 10+ second delays during routine file operations as the module count grew.
Jonathan Crooke's team built a custom module converter tool using their existing XcodeProj-based tooling. The tool automatically generated manifests for SPM, Tuist, and Bazel by leveraging their strong module uniformity. This let them iterate quickly across all three systems with adapters that output Swift or Starlark code.
Tuist's explicit 'tuist generate' operation scaled linearly in the worst case, similar to SPM, but avoided continuous graph resolution during development. Bazel showed real caching benefits, though it required significantly longer onboarding than the other two tools.