Symptom: Jobs queue during busy pull request periods, Simulator runs, or release windows, but the number of developers does not explain the delay.

Fastest fix: Estimate Mac Runner capacity from peak job arrivals, task duration, queue targets, and standby needs. Keep regular builds in a base pool, isolate UI tests and releases, and add remote Mac capacity for short peaks before buying or renting permanent nodes.

This guide is for DevOps engineers maintaining GitHub Actions self-hosted macOS Runners who need a defensible expansion trigger. It also fits mobile engineering leads assigning capacity across several iOS projects and procurement teams evaluating a remote Mac build fleet.

The key distinction is simple: the number of online Runners is not the same as effective concurrency. A Runner can be online but busy, unhealthy, misrouted, waiting for a compatible label, or too overloaded to finish work reliably.

A developer count is a poor capacity input. Ten developers may produce a quiet queue, while a smaller team can create a severe burst when a shared branch receives many commits or a release candidate starts full regression testing.

Create a separate measurement set for each workflow. At minimum, record:

• Task arrival time.
• Queue start and queue end time.
• Actual execution duration.
• Workflow name and job name.
• Runner labels and Runner Group.
• Whether the task was cancelled, retried, or rerun after failure.
• CPU, memory, storage, and Simulator condition during execution.
• Whether the job had a release deadline.

GitHub Actions exposes self-hosted Runner monitoring and troubleshooting information that can help you identify busy, offline, and unhealthy Runners. Use the official self-hosted Runner monitoring guidance as the data collection reference, then combine it with your workflow run history.

Do not use only the daily average. A daily average can hide a ten-minute submission burst, a Monday morning commit cluster, or an overnight test window. Build your baseline from a verifiable busy interval and a high-percentile task duration. The percentile is your planning guardrail, not an official GitHub capacity formula.

A useful planning model is:

Required concurrency ≈ peak arrival rate × high-percentile execution duration

Then apply operational adjustments for:

• Jobs that cannot be cancelled.
• Release work that must remain available.
• Failed jobs that are likely to retry.
• A Runner that may be offline or under maintenance.
• Internal test parallelism that consumes resources on one Mac.

This model gives you a starting point. It does not prove that a specific Mac can run a fixed number of workloads. You must validate the result with the actual project.

Pull request workflows usually combine code checks, unit tests, and incremental Xcode builds. These jobs arrive continuously during working hours. Their main value is fast feedback, not maximum overnight throughput.

Treat the PR pool as your baseline service. For each workflow, calculate how many jobs arrive in the busiest observed interval and how long they occupy a Runner. Then compare the result with the queue time your team accepts for code review.

For example, if a short lint job waits behind a long archive job, adding a general-purpose Mac may improve the queue. But adding another node is not the first move if the queue contains obsolete work. Review these causes first:

• Cancel older runs when a newer commit supersedes them.
• Merge checks that repeat the same setup and dependency work.
• Move platform-independent linting or unit checks away from macOS where the project permits it.
• Use workflow concurrency controls for jobs where only the newest revision matters.
• Avoid running a full archive for every change if a lighter validation path gives sufficient feedback.

GitHub documents the concurrency mechanism for controlling workflow and job overlap. Review the GitHub Actions concurrency documentation before treating cancellation as a capacity strategy. Cancellation can free Mac capacity, but it must not remove required verification or interrupt a release artifact.

The route itself also matters. GitHub selects a compatible self-hosted Runner using labels and group settings. A machine that is online but lacks the requested label is not useful capacity for that job. The workflow syntax reference explains how runs-on requirements interact with job routing.

PR capacity decision conditions

• If PR jobs miss the queue target only during short commit bursts, then remove obsolete runs and add temporary capacity for the burst.
• If the queue remains high throughout normal working hours, then increase the base pool after checking task duration and routing.
• If short checks wait behind long builds, then split labels or Runner Groups before buying another identical node.
• If most jobs do not require macOS, then move those steps elsewhere and recalculate Mac demand.
• If queue time improves but build duration worsens under higher local parallelism, then add another Mac instead of increasing work inside one job.

UI tests are not just longer PR builds. They may boot Simulators, install applications, reset state, capture artifacts, and run several test workers. A single Mac can become a contention point even when GitHub sees only one active job.

Separate three quantities:

1. GitHub workflow concurrency.
2. The number of test workers inside one xcodebuild job.
3. The number of independent Mac nodes available to the workflow.

Do not add these numbers together. For example, four test workers inside one job do not create four independent Runner slots. They create internal load on one Mac. Increasing workers can reduce wall-clock time in some projects, but it can also increase memory pressure, Simulator contention, I/O wait, or test flakiness.

Apple documents parallel testing behavior and the relevant xcodebuild options in its Xcode release notes. Use that documentation to confirm the mechanism, then test the actual application and test suite. The setting that works for one project may be unstable for another.

Collect these observations during a controlled run:

• Total wall-clock duration.
• Per-worker test duration.
• Simulator boot and reset time.
• Failed tests that pass on a rerun.
• CPU and memory pressure.
• Disk usage and derived-data growth.
• Whether parallel workers access shared state.
• Whether the Mac remains responsive for other services.

If raising the worker count makes the job slower or less reliable, cap internal parallelism. Add an independent UI-test node instead. This increases true machine-level concurrency without pretending that one overloaded Mac has gained capacity.

Keep UI testing separate from compilation when either workload can block the other. A shared pool is reasonable when demand is light, the tests are stable, and a release job cannot be delayed. It is a poor design when Simulator boot storms make PR builds unpredictable.

A release workflow can be infrequent and still require reserved capacity. Its impact is not measured only by average utilization. A blocked archive can delay delivery, while a contaminated signing environment can turn a routine deployment into incident work.

Assess release jobs against four risks:

• Keychain and certificate access.
• Workspace and derived-data contamination.
• Credentials or provisioning profile exposure.
• Recovery time after a failed archive or interrupted job.

Use dedicated labels or Runner Groups for controlled release nodes. GitHub provides Runner Group management documentation for organizing which workflows can access specific self-hosted Runners. Your routing policy should make it impossible for ordinary PR work to consume the only node reserved for signing and publishing.

Run one complete archive and publishing rehearsal through the intended route. Measure how long the job waits, how long it executes, and how recovery works after a deliberate interruption or failed step. The goal is not to create a benchmark number. The goal is to confirm that the right Runner receives the job and that the release path has usable spare capacity.

A release pool can share hardware with PR work only when all of these conditions hold:

• The release job has a clear priority or protected route.
• Credentials are isolated from untrusted pull request code.
• The shared workload cannot occupy every compatible Runner.
• Recovery steps are documented and tested.
• The release window has enough scheduling margin.

Otherwise, reserve a release node or keep a controlled fallback Runner available.

Not every workload deserves a permanent Mac. Separate your demand into three planning bands:

• Stable daily load: PR validation and routine builds.
• Scheduled load: nightly regression and periodic device or UI coverage.
• Short peak load: release candidates, deadline-driven archives, or a large merge window.

Stable daily load belongs in the base pool. Scheduled work can use a queue and a defined time window. Short peaks are candidates for temporary remote Mac capacity.

Choose fixed nodes when demand is persistent, queue targets are regularly missed, and the jobs cannot be moved or consolidated. Choose scheduling changes when the workload is deferrable and its completion deadline is flexible. Choose short-cycle expansion when the extra demand has a known start and end, such as a release validation period.

Do not size the permanent fleet for the highest observed peak unless that peak is now a normal operating condition. That approach leaves expensive capacity idle after the event. Instead, preserve the base pool for feedback and add capacity only when the measured peak cannot fit inside the release or test window.

A remote Mac can be useful here because you can run a controlled trial without committing immediately to a permanent hardware purchase. KVMNODE offers remote Mac build environments that can be evaluated as additional Runner capacity. The technical question remains the same: does the node meet your labels, access, security, build, and recovery requirements?

Use a staged capacity test rather than adding several machines at once. This produces evidence that procurement and platform teams can defend.

Step 1: Group jobs by operational role

Create separate groups for PR builds, Simulator/UI tests, release signing, and scheduled regression. Record the labels required by each group. Do not combine workloads merely because they use the same operating system.

Step 2: Export a representative run history

Capture arrival time, queue time, execution time, cancellation status, retry status, and final result. Include a busy PR period, a normal working period, and a release or regression window if available.

Step 3: Remove avoidable Mac demand

Cancel superseded jobs where safe. Merge duplicate checks. Move non-macOS steps away from the Mac pool. Re-run the measurement after these changes. Otherwise, you may buy capacity for waste created by workflow design.

Step 4: Test one workload class at a time

Start with PR builds. Then test UI workflows. Finally test the release route. Increasing all workloads together makes it difficult to identify whether the bottleneck is routing, CPU, memory, storage, signing access, or Simulator behavior.

Step 5: Increase concurrency in controlled increments

Add one compatible execution slot or one independent Mac at a time. Watch queue time, effective completion time, failure rate, and node resource pressure. A shorter queue is not an improvement if execution becomes slower or retries increase.

Step 6: Test failure and recovery

Take one Runner offline during a non-production test. Confirm that jobs queue or route to the intended fallback. Check whether a stuck Simulator, expired session, or interrupted archive leaves the workspace usable for the next job.

Step 7: Set expansion triggers

Write the trigger in operational terms. For example: expand the PR pool when the high-percentile queue repeatedly exceeds the team target during normal working hours. Add a UI node when extra test workers increase instability. Reserve release capacity when ordinary jobs have consumed the available signing route during a release rehearsal.

The final result should contain four separate conclusions:

• Base nodes: capacity for normal PR feedback.
• Test nodes: isolated capacity for Simulator and UI workloads.
• Release reserve: protected signing and archive availability.
• Failure standby: capacity for maintenance, restart, or node loss.

Some roles can share a Mac. PR linting and a low-volume build may share a general pool. UI tests and signing jobs should not share by default when they compete for resources or credentials.

Use the following branches before committing to a longer rental period or a larger permanent fleet:

• If peak queue time is acceptable and failures are stable, choose the current Runner count and continue collecting data.
• If queue time is high but many jobs are obsolete, choose workflow optimization before adding Mac nodes.
• If demand exceeds capacity only during a defined release or regression window, choose short-term remote Mac expansion.
• If demand exceeds capacity across normal workdays for repeated measurement periods, choose a larger long-term base pool.
• If UI worker increases create resource pressure or flaky tests, choose more isolated test nodes rather than more workers per Mac.
• If release rehearsal shows that PR jobs can block signing work, choose a protected release Runner or reserved capacity.
• If one node failure breaks the delivery deadline, choose explicit standby capacity and validate recovery before scaling routine workloads.

Capacity planning table

A self-managed physical Mac fleet gives you direct hardware control, but it also leaves you responsible for procurement delays, idle capacity between peaks, repairs, macOS maintenance, and the physical machine’s availability. A single Mac mini server can also become a hidden dependency when PR, Simulator, and release jobs all compete for it.

A Linux cloud server avoids much of that hardware work, but it cannot replace macOS-only tooling, Apple signing workflows, or Xcode execution. Virtualized or unsupported macOS arrangements add their own compatibility, licensing, and performance uncertainty.

If your measurements show a short-lived capacity gap, renting remote Mac capacity through KVMNODE is often a cleaner trial than permanently expanding the fleet. You can select a rental period around the measured workload, connect the machine to your self-hosted Runner design, and decide later whether the extra node belongs in the long-term pool. Review the available Mac build node options only after confirming your required labels, access model, secrets policy, and recovery procedure.

The procurement decision should follow the queue evidence. Rent for a peak when the shortage is temporary. Keep long-term capacity when the base workload repeatedly exceeds its target. Do not rent at all if your real problem is duplicate jobs, incorrect labels, or unsafe workflow concurrency.

Start by recording one representative cycle of PR, UI test, and release activity. Use the measured task windows to choose a short remote Mac expansion trial, then retain permanent nodes only when the data shows that the demand is recurring.