Splitting a monolithic iOS build into parallel CI jobs

The GitHub iOS team has long used GitHub Actions macOS runners as part of its development workflow, testing new runner images and hardware ahead of public release. Recently the team set out to cut the time spent waiting on CI for the GitHub for iOS codebase — a project built from roughly 60 first-party modules spanning dynamic frameworks, static libraries, app extensions, and the main application itself.

Previously, the entire codebase was built and tested in a single workflow job on the prior generation of runners, with a total runtime of 38 minutes. The team replaced that monolithic pipeline with a modular approach: each module now gets its own job on Apple silicon macos-14-xlarge runners. This let each target build and test independently, so developers received feedback on pull requests much sooner.

The payoff in practice

The smallest modules finish their tests in as little as 2–3 minutes on M1 macOS runners. Overall, splitting the work across parallel jobs cut testing time by about 60%, bringing the full CI run down from 38 minutes to 15. The parallel setup also made failures easier to isolate: a broken module can be identified and fixed without waiting for a complete monolithic build to finish.

Image demonstrates the monolith build on tip with the total CI time. The Image below it demonstrates how per-module builds are crafted and the reduction in CI time with the new approach.

From the repository side, every pull request triggers up to 50 concurrent jobs. GitHub Actions provisions fresh reimaged virtual machines for each job, handling machine preparation and distribution in the background.

Image displays the relationship between the request for workflow to run and how a machine is assigned to a job. From left to right, the flow starts at GitHub.com, then the request is sent to Actions. Actions then finds the available macOS VM to execute the workflow.

Build and test as separate signals

To dig deeper into CI performance, the team separated each module's pipeline into distinct build and test phases, using xcodebuild's build-without-testing and test-without-building actions. That split made it possible to distinguish long-running unit tests from fast ones that complete in seconds, which in turn helped target optimization efforts at the right steps.

Architecture parity with local development

Because the runners and the developers' laptops now share the same Apple silicon architecture, CI no longer behaves differently from local builds. Engineers could reproduce slow compiles or architecture-specific test failures on their own machines with confidence, rather than debugging against an environment that emulated or cross-compiled for a different platform.

What Apple silicon changes for iOS CI

Beyond raw speed, the architectural match brings practical benefits across the development lifecycle:

  • Builds avoid the pitfalls of cross-compilation or emulation.
  • Tests run natively against the latest iOS, iPadOS, watchOS, and tvOS simulators included in the GitHub Actions runner image.
  • Apple platform teams can validate against current OS versions without maintaining separate CI hardware.

GitHub Actions offers 50 concurrent runners for enterprise accounts and five for free and Team plans, and the GitHub for iOS workflow takes full advantage of that capacity — spinning up 50 jobs per pull request for parallel modular testing.

Moving your workflow to macOS runners

GitHub-hosted macOS runners are configured through YAML, so adoption is just a matter of changing the runs on: key in the workflow file. Relevant documentation covers standard runners for public and private repositories as well as the larger macOS runner options: