How the Medium iOS team works effectively with legacy code
Article Summary
Medium's iOS codebase is over 10 years old with code from 2013 still running in production. Instead of rewriting, they wear it as a badge of honor.
Zouhair Mahieddine from Medium's iOS team shares how they effectively work with legacy code using techniques from Michael Feathers' classic book. The team manages a decade-old codebase while continuously shipping new features without massive rewrites.
Key Takeaways
- Use Sprout methods to add SwiftUI features without touching legacy UIKit code
- Sketch diagrams when confused: they refactored Dark mode by mapping the system first
- Preserve signatures and lean on compiler errors to safely remove dependencies
- Modularize incrementally: SPM modules naturally discourage writing in the monolith
- Extract responsibilities before refactoring: identify what code does, then restructure step by step
Medium ships features faster by strategically working around legacy code rather than rewriting it, using discrete refactoring steps guided by clear techniques.
About This Article
Medium's story renderer was built in 2013-2014 and partially rewritten in 2019. They needed to add recommendation sections to the footer, but couldn't modify the legacy UIKit rendering engine that was tied to their content modeling system.
The team built the new 'More from this list' recommendation carousel in SwiftUI as a separate SPM module. They embedded it as a footer element using the Sprout method, which kept the new code isolated from the legacy systems.
Engineers shipped the new recommendation feature without touching the core story renderer. This reduced the risk of breaking a 10+ year old codebase. The approach also showed how modularization can naturally push teams away from adding to the legacy monolith.