Mobile CI/CD build times have degraded to over 45 minutes. How would you diagnose the bottlenecks and architect advanced caching, modular parallelisation, and test sharding to reduce the feedback loop by 50%?

Short answer

Evaluate the candidate's expertise in profiling build systems, configuring distributed caching, and optimising CI/CD pipelines for large-scale mobile projects.

Hardware cannot fix architectural rot

The naive engineer looks at a 45-minute mobile build and immediately throws more expensive hardware at the problem. They provision CI runners with massive core counts, assuming raw compute will brute-force the compilation times down. When that inevitably fails to yield a proportional improvement, they resort to blindly tweaking compiler flags without empirical data. They fail to realise that throwing hardware at a monolithic, tightly coupled codebase with rampant cache misses is a profound waste of capital that does nothing to solve the underlying architectural rot.

Profiling and distributed caching

The build system must be treated as a production environment, demanding rigorous profiling and telemetry. Diagnosing the bottleneck requires deploying tools like the Gradle Profiler or Xcode's Build Timing Summary (parsed via XCLogParser) to generate granular build scans. The root cause is almost always a combination of massive legacy modules compiling sequentially, redundant annotation processors, and cache invalidation caused by non-deterministic inputs.

Resolving compilation bottlenecks requires a robust distributed build cache strategy. For Android, a remote Gradle Build Cache node must be provisioned, with strict enforcement of deterministic task inputs to prevent cache misses from dynamic timestamps or absolute file paths. For iOS, tools like Tuist or Bazel are required to enable remote caching of pre-compiled binaries. The CI pipeline must be configured so the main branch continually warms the remote cache, allowing pull request builds to simply pull down pre-compiled artifacts for unmodified modules, instantly bypassing vast swathes of the compilation phase.

Modular parallelisation and intelligent execution

A monolithic architecture fundamentally restricts parallelisation. The codebase must be aggressively refactored to break down massive legacy modules into smaller, independent targets, flattening the dependency graph. Only then can build systems fully exploit concurrent execution across multiple CPU cores on high-performance CI runners.

flowchart TD
  A["Pull Request Trigger"] --> B["CI Runner Provisioning"]
  B --> C{"Check Remote Cache"}
  C -->|Cache Hit| D["Download Pre-compiled Artifacts"]
  C -->|Cache Miss| E["Parallel Compilation of Modified Modules"]
  D --> F["Link and Assemble Binary"]
  E --> F
  F --> G["Intelligent Test Sharding"]
  G -->|Execute Impacted Tests| H["Report Status to PR"]

Furthermore, build configurations during pull request verification are often bloated with release-only tasks. Optimising debug variants is mandatory: disabling ProGuard/R8 obfuscation, limiting packaged ABIs, disabling resource maps for Android, and skipping dSYM generation and unnecessary code signing for iOS.

Finally, the automated testing phase—often accounting for half the pipeline duration—must be heavily optimised. Test sharding must distribute unit and UI tests across multiple parallel emulators. An intelligent test impact analysis tool is required to map code changes to specific modules, executing only the tests relevant to the modified code rather than needlessly running the entire suite.

Optimising mobile build times requires a holistic approach that treats the build infrastructure as a critical product. By leveraging distributed caching, modular parallelisation, and intelligent test execution, you can drastically reduce CI durations and empower developers with rapid, reliable feedback.

© 2026 Preptima. Originally published at preptima.com.