Modularising the Badoo iOS app: dealing with knock-on effects
Article Summary
Alexander Kulabukhov from Bumble Tech reveals the hidden costs of iOS modularization that nobody warns you about. Spoiler: visualizing 50+ module dependencies looks like a tangled mess, and your CI will cry for help.
After successfully modularizing Badoo's chat feature, the team scaled to 78% of their 2M lines of code split into modules. But growth exposed critical problems: complex dependency graphs became unmanageable, CI queues exploded, and app launch times degraded with each new module added.
Key Takeaways
- Built custom 'deps' utility to automate dependency graph management and catch errors pre-commit
- Reduced CI queue times dramatically by testing only affected modules, not everything
- Switched to static linking: cut app size 30%, reduced crashes 3x from faster launches
- Created monitoring tool tracking build times across 43 developers to measure real impact
- E2E test filtering slashed infrastructure load while maintaining quality coverage
Modularizing a large iOS app requires custom tooling, smart CI filtering, and constant monitoring to avoid drowning in complexity and infrastructure costs.
About This Article
Once Badoo hit 50 modules, their dependency graph became too complex to visualize or debug. Managing intermediate dependencies turned into a resource drain, with developers spending time on manual linking work instead of building product features.
Alexander Kulabukhov's team created 'deps', a Swift console app built on the XcodeProj framework. It has three main commands: Doctor checks dependencies, Fix corrects problems, and Add handles module linking. The tool runs in pre-commit hooks to catch issues automatically.
The system stopped manual dependency errors from slipping through. Creating new modules became a single command instead of a manual process. The 50+ module dependency graph stayed stable without developers needing to understand the entire structure.