Why does Xcode Cloud keep installing dependencies on every build?

Xcode Cloud uses temporary build environments, so files and services created during one run should not be assumed to exist in the next run. Check the lockfiles, repository permissions, package setup, and post-clone scripts. If the workflow repeatedly performs expensive initialization that cannot be made deterministic, move that task to a controlled Remote Mac instead of hiding the delay with retries.

Where can I see the real duration of an Xcode Cloud build?

Open the build report and action logs in Xcode or App Store Connect, then separate queueing, environment preparation, compilation, tests, and archiving. Also review Xcode Cloud usage data. Compare two runs from the same commit or an equivalent commit. The total duration alone cannot tell you whether the delay came from dependencies, the test matrix, or execution.

Should I reduce devices or split the workflow when Xcode Cloud tests are slow?

First identify whether the same workflow repeats setup and runs unrelated test groups together. Use a small pull-request validation path, a main-branch regression path, and a scheduled full matrix when those scopes have different goals. Reduce devices when coverage is duplicated; split workflows when setup, ownership, or failure handling differs. Keep release validation separate from fast feedback.

When should I move Xcode Cloud work to a Remote Mac?

Migrate a task when logs show that repeated temporary-environment setup, private network access, persistent services, shared test assets, or host-level control dominates the work. Do not move the entire pipeline immediately. Run the slowest task on a Remote Mac, verify reproducibility, logs, signing isolation, reboot recovery, and maintenance effort, then choose a partial migration or hybrid CI.

Xcode Cloud Builds Too Slow? 2026 Remote Mac Migration Decision

A useful first data point is not the total build time. It is a pair of comparable runs: one normal sample and one slow sample from the same commit or an equivalent build input. Apple provides Xcode Cloud build reports, action logs, and usage data for this kind of investigation through its Xcode Cloud workflow documentation.

This week, record two comparable builds, label every stage, then change only one workflow variable at a time.

If Xcode Cloud builds are too slow, do not migrate after one bad result. First separate dependency preparation, compilation, testing, archiving, and queueing. Optimize triggers, caching, scripts, and test scope. Move only the tasks that repeatedly require a persistent environment, private services, or host-level control to a Remote Mac. Keep Xcode Cloud for standard builds or release validation when it remains reliable.

Who should use this guide

This guide is for Apple platform developers whose Xcode Cloud feedback time keeps increasing without a clear bottleneck.

It also targets CI engineers managing complex dependencies, caches, private repositories, or long-lived services. Engineering leads can use the final decision framework when comparing continued Xcode Cloud usage, a Remote Mac, or hybrid CI.

Start with evidence, not the pipeline total

A single duration hides the part of the system that needs repair. Two builds with a similar total can have very different causes:

One may spend most of its time preparing dependencies.
Another may compile normally but run a broad simulator and UI test matrix.
A third may wait for execution capacity before any build action begins.
A fourth may stall during an external download or upload inside a custom script.

Your first task is to create a stage record for each sample. Use a stable commit, the same Scheme, the same workflow, and the same test scope. Record:

Queue or scheduling delay.
Environment preparation.
Dependency installation.
Compilation.
Unit, UI, and device testing.
Archive, export, or upload actions.
Script failures, retries, and external network calls.

Apple’s Xcode Cloud usage data documentation is the right place to verify how usage is presented in your account. Do not treat an account usage graph as a substitute for action-level logs. Usage data can tell you that execution is growing. The build report should tell you why.

A short diagnosis record

Use a simple text record for each run:

Commit: <COMMIT_ID>
Workflow: <WORKFLOW_NAME>
Scheme: <SCHEME_NAME>
Test scope: <TEST_SCOPE>
Queue: <OBSERVED_STAGE>
Preparation: <OBSERVED_STAGE>
Build: <OBSERVED_STAGE>
Tests: <OBSERVED_STAGE>
Archive or export: <OBSERVED_STAGE>
Script warnings: <SCRIPT_NAME>
Result: <SUCCESS_OR_FAILURE>

This prevents a common mistake: changing the runner or purchasing more capacity before proving that the runner is the problem.

Step 1: Remove repeated dependency work

Temporary environments are useful for clean, repeatable CI. They also expose inefficient setup scripts. If every run downloads tools, recreates package state, authenticates to a private repository, and regenerates files, the preparation phase can dominate the actual Xcode build.

Check these areas first:

Swift Package dependencies and lockfile changes.
CocoaPods or Carthage setup.
Private repository credentials.
Tool installation inside the post-clone script.
Generated source files and code-generation tools.
Large assets downloaded from an external service.
Commands that silently retry after a network failure.

Apple’s dependency guidance for Xcode Cloud explains how dependencies must be made available to the build environment. Your goal is deterministic preparation. A dependency should be selected by the repository state, authenticated through an approved mechanism, and installed by a script whose output is visible in the logs.

Avoid installing a tool on every build when the workflow already provides a supported alternative. Avoid broad package-manager commands that resolve more content than the Scheme needs. Check whether a script is rebuilding generated assets even when the relevant source files have not changed.

Stop condition for dependency optimization

Continue optimizing Xcode Cloud when dependency preparation is repeatable, failures are visible, and the remaining work is tied to legitimate source or lockfile changes.

Start a Remote Mac comparison when the slow phase remains dominated by one or more of these conditions:

A private network or internal service is required.
A local daemon must stay alive between actions.
A large toolchain must be initialized for every run.
The build depends on host files that cannot safely be recreated.
The workflow needs root-level or host-level control.
Authentication requires an interactive or persistent environment.

Do not copy the entire pipeline merely because one preparation step is expensive. Move that task first.

Step 2: Separate clean builds from reusable state

“Cache is broken” is not a diagnosis. Xcode build products, package downloads, Derived Data, generated files, and custom script outputs are different kinds of state. They have different invalidation rules and different failure risks.

Review whether the workflow forces a clean build when the validation goal does not require one. Then compare:

A fresh build with no reusable state.
A normal build with the intended cache path.
A build after a limited source change.
A build after a dependency or configuration change.

This comparison shows whether caching saves meaningful work or merely preserves an environment that is difficult to reproduce. Apple documents caching and workflow behavior in the Xcode Cloud workflow reference. Use that reference to verify the options available to your workflow instead of assuming that every local Xcode state is retained remotely.

A fast cached build is not automatically a healthy build. You also need to test invalidation. Change a package lockfile, build setting, generated source input, or signing-related configuration in a controlled branch. Confirm that the workflow rebuilds the affected output rather than reusing stale content.

Benefits and risks of retaining state

Benefits

Less repeated dependency work.
Faster incremental feedback.
Lower unnecessary execution usage.
More useful feedback for small source changes.

Risks

A stale generated file can conceal a source problem.
A cache hit can make a broken clean build look healthy.
A script may depend on a file that exists only in one environment.
Different workflows may accidentally share assumptions about state.

If you cannot explain why a file exists and when it should be invalidated, it should not be part of a production cache strategy.

Step 3: Reduce test amplification without reducing coverage blindly

Slow Xcode Cloud tests often come from multiplication rather than one slow test. Each additional device, operating system combination, UI test group, archive action, or duplicate workflow can increase the work triggered by a single change.

Inspect the workflow graph. Ask:

Does every pull request run the full device matrix?
Does a merge trigger both the pull-request workflow and the main-branch workflow?
Are UI tests running when unit-level feedback would answer the immediate question?
Is an archive being produced for a validation path that does not distribute an artifact?
Are scheduled tests duplicated by push-based workflows?
Are obsolete commits still allowed to consume execution resources?

Use different layers for different decisions:

Pull request validation: fast compilation and targeted tests.
Main branch validation: broader regression coverage.
Scheduled validation: full device, UI, or compatibility coverage.
Release validation: archive, signing, export, and distribution checks.

Apple documents workflow actions and trigger behavior in its Xcode Cloud actions reference. Use automatic cancellation for obsolete work where the workflow goal allows it. A superseded pull request build may no longer deserve the same execution priority as the latest commit, but a release archive should not be canceled casually.

Reduce devices or split the workflow?

Reduce the device matrix when several targets provide the same signal and the extra combinations add little coverage.

Split the workflow when the tasks have different purposes, ownership, setup, or failure response. For example, a lightweight compile-and-unit-test workflow should not wait behind a full UI regression workflow if developers need an early answer.

The correct choice is not “fewer tests.” It is “the smallest test scope that answers this decision, with full coverage scheduled where it belongs.”

Step 4: Find long-tail delays in scripts and network calls

Custom scripts can make a clean CI design look slow even when Xcode itself is not the bottleneck. Downloads, uploads, API calls, signing preparation, asset generation, and private repository access can all wait without producing useful log output.

Audit every script for:

Explicit command output.
Bounded retries.
Clear failure exits.
Download progress or status.
Authentication errors that stop immediately.
Temporary-file cleanup.
Network calls that can be skipped when inputs are unchanged.
Secrets that never appear in logs.

Apple’s custom build script guidance should be checked against your current script structure. Also review the environment variable reference before assuming that a local proxy, path, credential, or service variable exists in Xcode Cloud.

Do not print tokens while increasing log detail. A more verbose log is only useful if it preserves credential hygiene. Use placeholders such as <REPOSITORY_URL>, <KEYCHAIN_PATH>, and <SERVICE_NAME> in runbooks and issue reports.

A Remote Mac becomes more credible when the script needs

A service that must remain running.
A connection to an internal network.
A local simulator or test asset that must persist.
A custom daemon or host-installed tool.
A long-lived workspace shared by related tasks.
Direct control over restart, disk cleanup, and process recovery.

These are environment requirements, not ordinary build-speed problems. More retries in Xcode Cloud will not turn a temporary environment into a persistent host.

FAQ: diagnosing Xcode Cloud delays

Why does Xcode Cloud keep installing dependencies?

Xcode Cloud uses temporary build environments. Treating a previous run’s installed tools or files as permanent state creates fragile workflows. Inspect lockfiles, permissions, post-clone scripts, and package setup. If the initialization cannot become deterministic, compare that task on a Remote Mac with explicit cleanup and recovery rules.

Where can you see the actual Xcode Cloud build duration?

Use the build report and action logs in Xcode or App Store Connect. Separate queueing, preparation, compilation, tests, archiving, and uploads. Then compare equivalent runs and review account usage data. A single total duration is not enough to identify the failing stage.

Should slow tests use fewer devices or separate workflows?

Use fewer devices when the matrix contains duplicate coverage. Split workflows when pull-request validation, branch regression, scheduled testing, and release packaging have different purposes. Keep the test scope visible in the workflow name and record which signal each job is intended to provide.

When should Xcode Cloud work move to a Remote Mac?

Move a task when repeated initialization, private services, persistent assets, or host control remains the dominant cost after workflow cleanup. Start with the slowest task. Verify build reproducibility, signing separation, complete logs, reboot recovery, and maintenance effort before moving more of the pipeline.

Step 5: Make a task-level migration decision

A migration decision should compare tasks, not slogans. You may not need to replace Xcode Cloud. You may need to remove one workload that does not fit a temporary environment.

Use this sequence:

Select the slowest repeatable task from the stage records.
Freeze the commit, Scheme, test scope, and signing assumptions.
Reproduce the task on a Remote Mac with explicit setup instructions.
Record preparation, execution, failure, cleanup, and recovery behavior.
Restart the host and repeat the critical path.
Check whether logs are complete enough for remote diagnosis.
Estimate human maintenance, not just machine execution.
Choose optimization, partial migration, or hybrid CI.

The Remote Mac environment must be treated as an engineering system. Configure separate credentials, document access, isolate signing material, and define what happens after a reboot. A build that is fast once but requires manual repair after every host restart is not a production improvement.

For teams evaluating a managed environment, review the Remote Mac development environment options only after you have identified the task that needs them. If the workload is stable enough for a dedicated host, compare the available Mac rental plans against your expected maintenance and usage pattern. The relevant comparison is not just hourly execution. It includes setup ownership, access, recovery, and idle capacity.

Decision table: optimize, migrate, or run hybrid

Decision path	Keep in Xcode Cloud	Move to a Remote Mac	Best fit
Standard source build	Clean workflow, deterministic dependencies, focused tests	Not necessary	Teams needing managed standard validation
Repeated dependency initialization	Optimize scripts and lockfiles first	Move only if setup requires persistent tools or private services	Projects with heavy custom preparation
Broad test matrix	Split pull-request, regression, and scheduled coverage	Use a test pool when shared assets or host control are essential	Large device or UI test programs
Release archive	Keep when signing and export are reproducible	Move when the release process requires host-specific services or manual control	Teams with specialized release infrastructure
Persistent background service	Usually unsuitable	Preferred when the service must stay available	CI tasks with long-lived daemons
Hybrid pipeline	Standard builds and release checks	Complex tests, private integrations, or persistent jobs	Teams that need both managed and controlled execution

What the current setup may be costing you

If you stay with Xcode Cloud after the evidence points to an environment mismatch, you may keep paying in several ways:

Developers wait for feedback that is slow for reasons unrelated to compilation.
Temporary setup repeats even when the source change is small.
Full test matrices consume execution resources before a focused result arrives.
Private network or persistent-service requirements produce retries and unclear failures.

A Remote Mac is not automatically better. It adds host lifecycle work, access control, cleanup, monitoring, and recovery responsibility. It is the stronger option when you need a real, persistent macOS host with direct control over tools and services. It is a poor fit when you only need a clean standard build and do not want to maintain another CI surface.

If your logs show that the real problem is repeated initialization or temporary-environment limits, run the slowest task on a short-cycle Remote Mac first. Once the task reproduces correctly, survives restart, produces usable logs, and does not create excessive maintenance, choose a partial migration or hybrid CI. VpsMesh can provide a real Remote Mac for that controlled comparison; the right next step is to validate the workload, not to move the entire pipeline on instinct.