An interview with Glovo's iOS platform team explores how the company structures its engineering org, tooling, and release process at scale. Topics include a flat modular architecture with strict module type rules, dependency vetting after painful experiences with Quick/Nimble API breakage, a custom build-metrics tool inspired by Spotify's XCMetrics, weekly release cycles built on Jenkins transitioning to GitHub Actions, and a 'selective test running' system that cut CI time by 40%.
Table of contents
Organizational OverviewDevelopment Environment: Balancing Freedom and ConsistencyModular Project ArchitectureCode ManagementProcesses and Tools: Optimizing Release Cycles and Feature DistributionClosing ThoughtsQuestions this post answers
How did Glovo reduce CI testing time for their modularized iOS app?
Glovo built an internal 'selective test running' tool that identifies which modules changed, analyzes the dependency tree for related modules, and runs tests only for those, instead of running the full suite. Combined with precompiling dependencies, this approach delivered a 40% reduction in CI time for their modularized iOS codebase. Teams tuning CI pipelines for large modular codebases can find similar engineering writeups on daily.dev.
Why did Glovo stop using Quick and Nimble for iOS testing?
Glovo moved away from Quick and Nimble because significant breaking changes in their APIs forced the team to spend substantial engineering time keeping test suites up to date. After this experience, Glovo shifted to using XCTest directly to streamline testing and reduce dependency risk. Developers weighing testing framework churn against stability can track similar trade-offs on daily.dev.
What module size does Glovo recommend avoiding when modularizing an iOS app?
Glovo avoids creating very small modules, generally steering clear of modules with fewer than 1,000 lines of code, because their research showed that adding modules carries real costs to app launch time, local storage, and developer tooling performance like Android Studio Sync. Every new module addition is weighed against these trade-offs before approval. Engineers planning a modularization strategy can compare real-world thresholds like this on daily.dev.