Modularising an iOS app: why and how we have been breaking Badoo app up into modules
Article Summary
Alexander Kulabukhov from Bumble reveals how his team scaled from a monolithic iOS app to 110+ modules across Badoo and Bumble. The journey wasn't just about splitting code—it was about building a sustainable process that transformed how their entire engineering org ships features.
The Bumble Inc iOS team spent years breaking their dating apps into reusable modules. This detailed case study walks through their experiment-driven approach: starting with a single chat module migration, documenting every mistake, and building tooling to make modularization sustainable at scale.
Key Takeaways
- Three-layer module structure: separate Logic, UI, and Interface submodules for testability
- UIGallery app with Visual Regression Tests catches design breaks automatically
- xcconfig files and explicit dependencies prevent hidden linking errors at scale
- Custom Swift script generates new modules in minutes instead of hours
- Chat module integration took 3 days for third app, under 24 hours for prototype
Bumble's modularization enabled horizontal team scaling and cross-app code reuse, but required upfront investment in tooling, explicit dependency management, and treating modularization as an ongoing process rather than a one-time refactor.
About This Article
Badoo's iOS team struggled with build configuration drift across 50+ modules. They couldn't quickly apply compiler flags or verify Swift versions consistently, which made updates risky and error-prone.
Alexander Kulabukhov's team set up xcconfig files with nested includes to centralize build settings. They stored generalized configurations in a separate repository and used Git pre-commit hooks to prevent direct Build Settings changes.
The standardized settings reduced configuration errors and made it easier to run experiments quickly. One team could now manage project parameters instead of manually updating settings across dozens of modules.