Scaling iOS at Bumble (Part 3)
Article Summary
Bumble's iOS team hit a wall: dozens of engineers, hundreds of modules, and Xcode was buckling under the pressure. Sound familiar?
Bumble Inc.'s iOS Core Team shares how they tackled the classic 'medium-scale' problem: too big for Apple's out-of-the-box tools, too small to justify building everything in-house. This is Part 1 of their journey evaluating Swift Package Manager, Tuist, and Bazel.
Key Takeaways
- Managing hundreds of modules with custom tooling became unsustainable
- Xcode project files caused constant merge conflicts across growing teams
- Three solutions evaluated: SPM, Tuist, and Bazel for different reasons
- Goal: eliminate custom tooling while improving build speeds and modularity
- Medium-scale teams face unique challenges neither startups nor tech giants experience
Bumble's iOS team outgrew Xcode's native workflow and set out to find a scalable solution that wouldn't require massive infrastructure investment.
About This Article
Bumble Inc.'s iOS codebase grew to hundreds of modules with millions of lines of Swift code. This caused Xcode to slow down noticeably. Engineers across the team experienced longer workspace opening times, slower file operations, and longer build times.
Jonathan Crooke's team looked at three build tools to replace their custom XcodeProj-based tooling. They evaluated Swift Package Manager, Tuist, and Bazel. The goal was to eliminate the friction of managing .pbxproj files in a monorepo that had over 100 feature workspaces.
The investigation aimed to reduce the maintenance burden of custom tooling and decrease friction around modularity. They wanted to improve build speeds and remove .xcodeproj from the repository. The team also needed to keep the codebase maintainable as it continued to scale.