How We Decomposed Tinder's Monolith
Article Summary
Maxwell Elliott and Connor Wybranowski from Tinder turned what seemed like a 12-year project into a 6-month sprint. Their secret? Letting the compiler do the heavy lifting instead of manually untangling 150,000 lines of code.
Tinder's iOS monolith had become a productivity killer—slow builds, no clear ownership, and constant conflicts. The team needed a systematic way to break apart over 1,000 entangled files without causing production incidents. They developed an automation-first approach using compiler insights to map dependencies and extract code in strategic phases.
Key Takeaways
- Reduced monolith build time by 78% while extracting 1,000+ files
- Automation cut decomposition time from 12 years to 6 months
- Each moved file required edits to 15 other files on average
- Used directed graphs to identify leaf nodes and extract in phases
- Code review consumed 50% of effort; automation handled the rest
Tinder decomposed their entire iOS monolith in under 6 months with zero P0 incidents by automating dependency analysis and extraction instead of manual refactoring.
About This Article
Tinder's iOS app was built as a single monolith with over 1,000 files and 150,000+ lines of code in one build target. The dependencies were so tangled that removing one file often meant manually pulling out half the codebase.
Maxwell Elliott and Connor Wybranowski created automation to map Swift compiler declarations and references into a directed graph. They then extracted files systematically, starting with leaf nodes that had no incoming dependencies, working through sequential phases instead of doing it by hand.
The team cut monolith build time by 78% and finished the full decomposition in under 6 months without any P0 incidents. Manual extraction would have taken about 12 years.