Optimizing Slow iOS CI Build Times

WHAT THIS TESTS Whether you diagnose before optimizing and know where React Native iOS builds actually spend time.

A GOOD ANSWER COVERS Start by measuring. Enable Xcode build timing summaries and the build timeline to see whether time goes to CocoaPods install, native compilation, the Metro JS bundle, or linking. Once the bottleneck is known, attack it. Cache aggressively: persist the CocoaPods spec repo, the Pods directory keyed on the Podfile.lock hash, and DerivedData between CI runs so unchanged native code is not recompiled. Adopt precompiled dependencies where possible, using prebuilt pod binaries or frameworks so heavy native libraries compile once. Trim what CI builds, for example limiting to the active architecture and avoiding building unused simulator slices on release jobs. Parallelize the iOS and Android jobs and split test stages. Keep the JS bundling step fast with Metro caching. Consider build acceleration tools or a remote cache if the team is large.

COMMON WRONG ANSWERS Immediately upgrading to a more expensive runner without profiling, which can mask but not fix the real cost. Disabling debug symbols on release builds you still need to symbolicate crashes from. Caching nothing and reinstalling pods from scratch every run.

LIKELY FOLLOW-UPS How to key a CocoaPods cache so it invalidates correctly when the lockfile changes. The risk of stale DerivedData causing flaky builds and how to bust it. Whether the New Architecture's codegen step adds measurable build cost.

ONE CONCRETE EXAMPLE Profiling shows ten minutes spent on pod install and native compilation each run. You add a cache keyed on Podfile.lock for Pods and DerivedData; subsequent builds restore them and skip recompiling unchanged pods, cutting the build from twenty minutes to eight without changing runner size.