A queue is not proof that you need more Mac hardware. It is a symptom. The cause may be one of several different constraints:

• Runnable-node shortage: jobs are ready, but no eligible Apple Silicon node is free.
• Single-task saturation: one archive or simulator workload consumes CPU, memory, disk, or I/O for too long.
• Signing serialization: several jobs wait for one protected keychain, certificate, provisioning profile, or release lock.
• Cache or network delay: nodes are available, but dependency downloads, artifact transfer, or private network access extends service time.
• Retry amplification: flaky tests or environment failures create extra jobs during the same peak window.
• Routing mismatch: the workflow requests a label or capability that only a small subset of nodes provides.

Xcode 27 is not a simple chip-refresh decision. Apple’s release notes confirm that Xcode 27 installs and runs only on Apple silicon Mac hardware. That means Intel capacity cannot be counted as valid production capacity for an Xcode 27 build fleet. Check the current Xcode 27 release notes before finalizing the hardware plan.

A common enterprise pattern looks like this: job volume rises, but CPU graphs remain moderate. The real bottleneck is a protected signing step, a private dependency endpoint, or a queue restricted to one runner label. Adding a larger general-purpose node may improve one archive while leaving release jobs blocked.

The capacity unit is not “one developer.” It is one runnable task of a defined class during a defined peak window.

Start with separate workload classes. Do not combine them into one average build time.

Step 1: Split the workload before counting nodes

Track at least these classes:

1. Pull request builds.
2. Incremental builds for developer feedback.
3. Clean builds.
4. Parallel simulator tests.
5. Archive and signing jobs.
6. Formal release and distribution jobs.
7. Nightly or scheduled regression work.

Each class has a different scheduling profile. Pull request jobs may arrive in bursts. Nightly tests may create a predictable batch. Signing work may be intentionally serialized. Release jobs may have the highest business priority but the lowest arrival frequency.

For GitHub Actions, inspect the runner selection and label behavior in the official runner selection documentation. The documentation lists the xcode-27 label. Do not assume that a label alone proves image availability, capacity, or a specific billing treatment.

Step 2: Record the queue variables

For every job class, capture:

• Jobs arriving during the busiest observation window.
• Time from queued to started.
• Time from started to completed.
• Retry count and retry cause.
• Percentage of jobs requiring signing.
• Percentage requiring a clean workspace.
• Cache hit or miss state.
• Required private network access.
• Failure recovery time after node restart.
• Maximum acceptable queue time.

Use a consistent measurement period that includes a normal day, a release window, and a known regression run. The measurement period itself is an enterprise record, not a universal industry constant.

Step 3: Convert observations into formulas

Use variables instead of unsupported hardware promises:

• Baseline concurrency: the number of simultaneously running jobs needed to keep ordinary work within its queue target.
• Peak concurrency: the maximum number of simultaneously runnable jobs during the selected peak window.
• Safety allowance: extra capacity for retries, delayed cleanup, cache misses, and node recovery.
• Protected concurrency: capacity reserved for signing and release work.
• Elastic concurrency: peak capacity that does not need to remain online during normal demand.

A useful first model is:

Required concurrency = peak arrival rate × average service time + safety allowance

Then calculate each task class separately. If ten jobs arrive during a window and each job occupies a node for a different duration, do not replace those values with one team-wide average. An average can hide a long archive task that blocks a release lane.

For queueing work, define:

Peak node requirement = peak runnable jobs ÷ effective utilization

Effective utilization must be measured from your own workflow. It should account for setup, teardown, cache restore, artifact transfer, and time when a node is technically online but cannot accept the next job.

Do not treat 100% utilization as the target. A pool with no spare capacity has no room for retries, node cleanup, or release priority. The correct margin depends on your queue service target and business cost of delay.

Step 4: Separate queue wait from execution time

A shorter build is not always the same as greater capacity.

• A faster single task improves feedback time.
• More independent nodes increase throughput.
• Lower queue time improves developer and release responsiveness.
• Better caching can reduce service time without adding nodes.
• Signing isolation can protect releases without improving ordinary build throughput.

Measure all three timestamps:

queued_at → started_at → completed_at

If queued-to-started time is high while started-to-completed time is stable, add runnable capacity or correct routing. If execution time is high on every node, benchmark the project, cache, dependency path, and task shape before purchasing more nodes.

GitHub documents workflow and platform limits separately from runner selection. Review the current GitHub Actions limits reference when a queue appears larger than the physical fleet would suggest. An organization-level or workflow-level limit can make extra Mac nodes ineffective.

The answer depends on the metric that is failing.

Add Apple Silicon nodes when:

• Runnable jobs are waiting for an eligible node.
• Several independent jobs can run without sharing a signing resource.
• Queue wait is the dominant part of total lead time.
• The workload has a short, measurable peak.
• A second node can use the same required toolchain and private network path.

Upgrade or optimize the single-node workflow when:

• One clean build or archive dominates service time.
• All nodes show the same compilation or test bottleneck.
• Dependency and artifact transfer consume a large share of job time.
• Cache misses are caused by unstable keys or excessive workspace cleanup.
• The project cannot safely run parallel tasks.

Create a dedicated signing pool when:

• Signing credentials cannot be exposed to ordinary build jobs.
• Release jobs are blocked by a shared keychain lock.
• The approval process requires a distinct audit trail.
• A failed cleanup could affect subsequent release artifacts.
• Signing failures are business-critical but relatively infrequent.

A metric-based baseline test

Run the same project and commit set through a controlled matrix:

• Incremental build.
• Clean build.
• Parallel simulator test.
• Archive without distribution.
• Archive with signing.
• Release preparation.

Keep the Xcode version, dependency lockfile, workflow revision, cache policy, and runner labels constant. Record concurrency, queue time, execution time, cache status, failure reason, and recovery result. A benchmark without those fields cannot support a procurement decision.

The purpose is not to publish a universal build-time claim. It is to discover whether another Apple Silicon node increases throughput, whether a larger node shortens service time, or whether neither option addresses the constraint.

A single shared pool is easy to start and difficult to govern. A better design assigns each pool a clear responsibility.

Shared build pool

Use this pool for pull request validation, ordinary incremental builds, and non-release tests.

Controls should include:

• Ephemeral or cleaned workspaces.
• A fixed toolchain image or documented provisioning script.
• No production signing credentials.
• A queue target based on developer feedback requirements.
• Failure routing to a replacement node rather than manual repair.

Protected signing pool

Use this pool for archives, signing, distribution preparation, and release operations.

Controls should include:

• Separate runner labels and access rules.
• Restricted keychain and certificate access.
• Explicit release locks.
• Strong workspace cleanup after every job.
• Audit records for credentials, workflow revision, and artifact output.
• A documented fallback when the primary signing node is unavailable.

Elastic peak pool

Use this pool for release spikes, migration pilots, scheduled regression bursts, and temporary capacity gaps.

Before counting an elastic node as usable capacity, test:

• Provisioning or access delay.
• Xcode and dependency delivery.
• Cache warm-up and cache reuse.
• Private network connectivity.
• Secret injection and cleanup.
• Runner registration and deregistration.
• Recovery after interruption.
• Whether the CI scheduler can route the correct jobs to it.

GitHub’s documentation for larger runners describes capabilities and configuration boundaries that may affect this model. Hosted capacity is not automatically equivalent to a dedicated Mac node. Review labels, architecture, image state, network access, storage behavior, and billing together.

For self-hosted or remote Mac capacity, the physical host may be persistent while the runner environment is rebuilt per job. That can improve control, but it does not remove startup, cleanup, or private-network dependencies.

Compare unit task cost, not the number of devices alone.

For a purchased fleet, include hardware acquisition, deployment, spare capacity, repairs, replacement cycle, power, rack or office requirements, monitoring, patching, and engineer time. For remote Mac capacity, include subscription or rental spend, active and idle time, provisioning, data transfer, private connectivity, and supplier recovery terms. For hosted runners, include runner minutes or other billable units, larger-runner charges, storage, artifact transfer, and concurrency constraints.

GitHub publishes the current Actions runner pricing documentation and billing and usage guidance. Use those pages for the current billing model rather than copying an old rate into a budget spreadsheet.

Decision conditions: choose the next capacity path

• If baseline demand is stable, queue targets are predictable, and the team needs persistent private connectivity, choose a fixed Mac pool.
• If demand is stable but release peaks are temporary, choose fixed baseline nodes plus elastic remote Mac capacity.
• If the team is migrating to Xcode 27 and lacks trustworthy workload records, start with a measured pilot instead of committing to the final fleet size.
• If signing is the main blocker, create a protected signing pool before adding general build nodes.
• If cache misses or network access dominate execution time, optimize those dependencies before expanding capacity.
• If the workflow requires physical devices, local peripherals, or uninterrupted on-site access, do not assume remote Mac capacity is a complete replacement.
• If the vendor cannot provide evidence for startup, environment rebuild, recovery, and network boundaries, treat the capacity as unproven.

This approach answers how many Apple Silicon CI nodes you need without pretending that one number works for every repository.

The following table is a decision framework. It does not assign unsupported prices or machine counts. Fill the variables with your recorded workload and current vendor or GitHub terms.

For a remote Mac pilot, you can review the KVMNODE Mac service entry point and select the region that matches your private network and data-handling requirements. Regional pages such as the US East Mac option or Singapore Mac option should be evaluated as candidate capacity, not treated as proof that your pipeline will meet its target.

Capacity acceptance should use the real workflow, not an online node indicator.

Five-step acceptance run

1. Freeze the test definition. Record the repository revision, dependency lockfile, Xcode version, runner label, workflow revision, cache policy, and signing mode.
2. Replay each task class. Run incremental builds, clean builds, simulator tests, archives, signing, and release preparation.
3. Apply peak concurrency. Reproduce the measured peak arrival pattern, including retries and release locks.
4. Test failure and recovery. Restart or remove a node, rebuild its environment, reroute the job, and confirm that credentials and workspace data are cleaned.
5. Compare evidence with targets. Evaluate queue time, completion rate, execution time, signing isolation, cache reuse, and expansion behavior.

Use four possible outcomes:

• Pass: queue and reliability targets are met, signing is isolated, and recovery is repeatable.
• Time-limited remediation: the design works, but a defined issue such as cache setup or network access needs correction before broad rollout.
• Add elastic capacity: baseline works, but measured peak demand exceeds the fixed pool.
• Pause procurement: the bottleneck is unclear, the runner boundary is unproven, or the supplier cannot demonstrate recovery.

A green runner status is not acceptance evidence. GitHub’s concurrency documentation is relevant when jobs must be grouped, cancelled, or serialized. Those workflow rules can change effective capacity even when more runners are available.

Cost and capacity worksheet

Use the current GitHub billing reference for hosted-runner calculations. Do not copy a public rate into a total-cost model without checking runner class, included usage, organization limits, storage, and artifact charges.

How many Mac build machines does an enterprise need for Xcode 27?

Headcount is not a sufficient input. Measure the busiest runnable jobs, service time, retry volume, signing locks, and queue target. Then reserve protected capacity for release work and model elastic capacity separately. The result may be fewer or more machines than the developer count suggests because task duration and peak timing determine concurrency.

How do you calculate concurrent iOS CI build capacity?

Calculate each workload class separately. Multiply the peak arrival rate by its measured service time, then add a documented safety allowance. Check whether the result is limited by nodes, signing, cache, network, or workflow concurrency. Validate the formula by replaying the real project at the observed peak rather than relying on a synthetic benchmark.

How should a Mac packaging server scale for peak concurrency?

Use queue wait and runnable-job count as the expansion signals. Keep ordinary builds in a shared pool, protect signing work, and add elastic Apple Silicon nodes for temporary peaks. Confirm that the new node can receive the correct toolchain, secrets, dependencies, and private network access. Otherwise, extra nodes may increase inventory without reducing the queue.

How many Apple Silicon CI nodes should a team plan for?

Plan by baseline, protected signing, and peak concurrency. Xcode 27’s Apple silicon requirement makes architecture eligibility a hard boundary, as documented by Apple. Count only nodes that can run the required workflow and access its dependencies. Recalculate after major changes to project structure, simulator coverage, release frequency, cache policy, or runner limits.

Can remote Mac capacity eliminate Xcode 27 build queues?

It can remove queues caused by a shortage of runnable nodes. It cannot automatically solve signing locks, slow dependency downloads, cache misses, or private network restrictions. Test startup time, environment delivery, cache reuse, job routing, and failure recovery during a real peak. Keep a fixed baseline when the team needs predictable capacity every day.

Buying a large permanent fleet can leave expensive capacity idle outside release windows. A fully hosted approach can introduce runner, network, billing, and concurrency boundaries that your team does not control. A single shared signing machine creates a security and availability bottleneck, even if general builds are fast.

For most teams with stable daily work and irregular release peaks, a fixed Mac pool plus elastic remote capacity is easier to justify than one oversized node. It separates predictable spend from burst demand and gives procurement a measurable exit condition.

Before requesting a quote, document baseline concurrency, peak concurrency, queue tolerance, signing isolation, private network needs, cache behavior, recovery evidence, and the maximum acceptable provisioning delay. Then use a KVMNODE remote Mac trial as a capacity test only when those acceptance criteria are written down. That produces a better purchasing decision than committing to a fixed node count based on developer headcount.