iOS Monorepo CI/CD Pipelines
Article Summary
Alberto De Bortoli from Just Eat Takeaway reveals how they slashed their iOS CI complexity by consolidating dozens of module repos into one. The result? One PR instead of multiple, faster iteration, and smarter pipelines.
Just Eat Takeaway's iOS team faced a painful workflow: every module change required multiple PRs and independent versioning across separate repositories. They migrated to a monorepo using CocoaPods development pods and built dynamic Jenkins pipelines that intelligently detect which modules changed and run only the necessary tests.
Key Takeaways
- Monorepo reduced module changes from 2+ PRs to just 1 PR
- Dynamic pipelines detect changed modules and run targeted tests automatically
- Smart dependency tracking runs tests for consuming modules when dependencies change
- Agent pool reduced from 10 to 5 nodes through aggressive optimization
- Custom version pinning rules balance stability with update flexibility
Just Eat Takeaway's monorepo approach eliminated multi-repo overhead while maintaining modular architecture benefits through intelligent CI pipelines that scale automatically as new modules are added.
About This Article
Just Eat Takeaway's iOS architecture was split into six pod categories: open-source, open-source shared, internal domain, internal core, internal shared, and external. Developers had to maintain strict version pinning rules across all of them, which made dependency management across podspecs and Podfiles complicated.
Alberto De Bortoli's team took a different approach for each category. They used optimistic operators (~>) for open-source shared pods, pinned external pods strictly, and loosened constraints on internal shared pods. This reduced the overhead of updating podspecs.
The versioning framework let the team scale the monorepo while keeping semantic versioning in place. New patch versions of open-source shared pods could be adopted automatically without breaking the modules that used them.