The fastest way to make UI testing slower is to split it before you know what is slow. A full-suite run usually contains several different costs:

• workflow queue time before a Runner starts;
• source checkout and dependency resolution;
• compilation or build-for-testing;
• simulator boot and data preparation;
• actual XCTest execution;
• result packaging and artifact upload;
• retries caused by shared state or infrastructure failures.

Record these phases separately. Do not call the full workflow duration “test time.” Apple’s documentation distinguishes running tests, interpreting results, and organizing tests to improve feedback. Use the Apple guidance on running tests and interpreting results as the basis for your baseline fields.

Capture at least:

• the commit or pull request identifier;
• the scheme and Test Plan used;
• the complete test selection;
• the order in which suites execute;
• the start and finish time for each meaningful phase;
• the first failing test and its screenshot;
• the simulator destination;
• the path of the .xcresult bundle;
• queue time and Runner labels;
• whether the failure can be reproduced on a clean simulator.

You are measuring three different concurrency layers:

1. GitHub Actions Job concurrency: how many matrix jobs GitHub schedules.
2. Remote Mac node concurrency: how many eligible machines can accept those jobs.
3. Xcode and simulator concurrency: how many test processes or simulator destinations one Mac runs at the same time.

These layers are not interchangeable. Increasing the matrix size does not add hardware. Adding a second simulator on one Mac does not equal adding a second independent Runner. Swift Testing process-level parallelism also does not remove shared-state problems in an XCTest UI suite.

GitHub explains that workflow jobs are scheduled through Runner availability and workflow configuration. Review the official GitHub Actions workflow model before treating a larger matrix as capacity.

Before creating shard names, inspect dependencies. A file-based split looks balanced but often produces weak isolation. One shard may contain fast smoke tests while another contains long onboarding and account-reset flows. Equal file counts do not mean equal runtime.

Use this decision list:

• If tests can run with independent accounts, data, simulators, and destinations, create separate shards with stable ownership.
• If tests depend on a login state or shared backend record, keep them together first. Remove the dependency in a later refactor.
• If tests must follow a business sequence, preserve that sequence in one shard. Do not distribute its steps across matrix jobs.
• If a test needs push state, a local service, a fixed port, or special credentials, give it an explicit shard contract.
• If failures cannot be reproduced from one test selection, stop splitting and improve the reproduction command first.
• If only the files are evenly distributed but execution time is not, group by historical duration and dependency boundaries instead.
• If a shard needs a different Xcode or simulator capability, route it to a dedicated Runner label rather than silently letting any Mac accept it.

Apple recommends organizing tests to improve feedback, but organization must preserve diagnostic meaning. Consult the Apple documentation on test organization when deciding whether a group belongs in a Test Plan, target, suite, or selected test scope.

Define a shard contract

Every shard needs a short, fixed contract. For example:

• ui-auth
• ui-checkout
• ui-settings
• ui-critical-release

The identifiers are placeholders. Replace them with names that match your repository and ownership model.

For each shard, document:

• its test selection;
• required account and input data;
• simulator destination;
• expected output path;
• owning team;
• standalone local reproduction command;
• whether it is required for pull requests or release validation;
• its fallback serial command.

Use Xcode Test Plans where selection and configuration belong together. Use only-testing when you need a precise command-line scope. Confirm the exact flags supported by the Xcode installed on the target node with:

xcodebuild -help

Do not assume that a flag, result option, or parallel behavior is identical across Xcode releases.

The first GitHub Actions matrix should prove routing, not maximize concurrency. Put the shard identifier, Runner label, scheme, Test Plan, and destination in explicit configuration. Use placeholders in the workflow until the repository contract is settled.

A conceptual structure looks like this:

strategy:
  fail-fast: false
  matrix:
    shard:
      - ui-auth
      - ui-checkout
      - ui-settings

runs-on: [self-hosted, macos, ios-ui, shard-${{ matrix.shard }}]

The exact labels depend on your Runner registration. GitHub’s self-hosted Runner label documentation explains how labels route jobs to compatible machines.

Keep these controls separate:

The GitHub workflow syntax reference documents matrix, concurrency, and job-level controls. Treat them as scheduling controls, not performance guarantees.

Important: A matrix with several entries can still run one job at a time when only one matching Runner is online. Check queue timestamps and Runner assignment before claiming that the suite is parallel.

Compare the first operating models

Do not choose the third row merely because the YAML looks scalable. Choose it when the queue is the dominant delay and the suite can run independently.

Parallel UI testing fails at boundaries that are easy to miss. Give each job a separate:

• simulator destination or device identifier;
• DerivedData directory;
• temporary directory;
• .xcresult output path;
• log path;
• test account or data namespace;
• local service port;
• keychain or signing context where applicable.

A common error is to isolate the simulator but reuse the same result path. The last job then overwrites evidence from the first job. Another error is to use separate result paths but the same backend account. Tests appear flaky because one matrix job changes the state expected by another.

Keep the workspace contract explicit:

$RUNNER_TEMP/shards/<shard-id>/derived-data
$RUNNER_TEMP/shards/<shard-id>/results
$RUNNER_TEMP/shards/<shard-id>/logs

The paths above are examples, not required repository paths.

Use a fresh simulator or a controlled reset policy for every job. Record the runtime, device type, OS image, and boot result in the shard manifest. A screenshot without destination metadata is weak evidence.

Test one concurrency layer at a time

Start with one job on one remote Mac. Then compare:

• serial execution of all shards;
• matrix jobs queued on one Runner;
• matrix jobs on multiple independent Runners;
• internal simulator parallelism on one Mac.

Change only one layer per experiment. If you increase matrix size and simulator parallelism together, a failure cannot tell you whether the cause was scheduling, CPU pressure, storage contention, or test code.

Look at evidence rather than assumptions:

• Runner queue timestamps;
• simulator boot and shutdown logs;
• process and memory pressure;
• disk usage and I/O symptoms;
• test screenshots;
• result bundle completeness;
• repeated failure location;
• account and backend logs.

A single successful retry does not prove that a concurrency setting is safe.

Each matrix job should upload its own:

• .xcresult bundle;
• console output;
• screenshots and videos when enabled;
• shard manifest;
• simulator and environment metadata;
• failure classification;
• first-attempt status.

Apple documents the role of test results and result bundles in its test execution and result interpretation reference. Use that guidance to keep result handling tied to the actual test run rather than a summarized exit code.

Your aggregation job should perform four checks:

1. Every expected shard produced an artifact or an explicit infrastructure failure.
2. No shard ran twice under the same commit without being marked as a retry.
3. Assertion failures are separated from Runner, simulator, timeout, and artifact failures.
4. The final status preserves the first failed attempt.

A retry can answer “was this failure intermittent?” It must not erase the original failure. Store both attempts and classify the test as flaky only after repeated evidence under the same conditions.

Coverage needs the same discipline. Do not add shard percentages together. A percentage from one shard may use a different denominator from another. Only merge coverage when the project’s supported tooling and a validated workflow prove that the result is meaningful. Apple’s Xcode release documentation is useful historical context, but verify current command behavior on the Xcode version installed on your Runner.

Use the following rollout rules after the first two-shard trial:

• Choose one Mac with serial shards if queue time is small, failures involve shared state, or result ownership is still unclear.
• Choose one Mac with internal parallelism only if each simulator, result path, account, and temporary directory is isolated and resource evidence remains healthy.
• Choose multiple remote Mac nodes if eligible Runners are consistently available, shard failures are reproducible, and the queue dominates the end-to-end feedback time.
• Keep a serial release lane if the project has signing-sensitive tests, shared backend assumptions, critical business flows, or unresolved flaky cases.
• Rebalance shards if one long shard repeatedly determines total completion time.
• Add nodes instead of more matrix entries if jobs spend most of their time waiting for a matching Runner.
• Rollback to the baseline if the parallel result differs from the full suite without a known test-selection reason.

The key trade-off is not “more jobs versus fewer jobs.” It is “more independent execution capacity versus more state and evidence to govern.”

For teams evaluating a real node without buying hardware, a remote Mac for Xcode and Simulator validation can be used as a temporary test environment. Keep the acceptance scope concrete: Runner registration, required Xcode installation, simulator boot, signing access, artifact upload, and repeatable failure reproduction.

How can GitHub Actions run several iOS UI suites in parallel?

Use a matrix whose entries represent stable test scopes, not arbitrary file groups. Each matrix job must target a compatible self-hosted Runner and use isolated simulator, storage, result, and account state. If the workflow expands into several jobs but only one matching Runner is online, the jobs remain queued. Validate routing before measuring any speed improvement.

How many simulator jobs can one Mac Runner handle?

Do not set a universal capacity number. Begin with one job on the exact Mac and Xcode image used by CI. Add internal simulator concurrency only after checking CPU pressure, memory behavior, storage contention, simulator boot reliability, and shared service state. If failures appear only after the increase, revert the concurrency layer and repeat with better isolation.

How should Xcode UI tests be grouped with a Test Plan?

Use Test Plans, targets, suites, or only-testing selections to express stable responsibility and dependency boundaries. Keep authentication, push state, shared accounts, and sequential user journeys together until they are independently provisioned. A shard should have a fixed name, a clear owner, a dedicated input contract, and a command that reproduces it outside the matrix.

How should several xcresult bundles be aggregated?

Upload each bundle independently and retain the shard identifier in the artifact name. The aggregation job should check expected versus received shards, preserve first attempts, and classify infrastructure failures separately from assertion failures. A retry is diagnostic evidence, not permission to replace the original failure. Merge coverage only when the supported tooling confirms that the merged denominator is valid.

Do not make the first successful matrix run your final architecture. Observe real pull requests through the first operating period and compare:

• end-to-end feedback time;
• Runner queue time;
• longest-shard duration;
• shard duration imbalance;
• first-attempt failure rate;
• retry rate;
• simulator boot failures;
• missing artifact rate;
• remote Mac utilization;
• serial-versus-parallel result differences.

A release lane should retain a serial baseline or a scheduled full-suite validation until the parallel path proves equivalent coverage and failure visibility. The baseline is also your rollback entry point. If a new shard selection misses a test, you need a known-good command that can run the complete suite.

Stop and revert when:

• a critical test is absent from every shard;
• two shards mutate the same account or backend record;
• result bundles are overwritten or incomplete;
• failures cannot be classified;
• queue time falls but execution failures rise;
• one Runner becomes a hidden single point of failure;
• the parallel result disagrees with the serial baseline without an explained selection difference.

The most reliable rollout is usually incremental: baseline, two-shard trial, isolated multi-node run, then controlled expansion. This approach gives you a cause for every change.

A local Mac mini may be a good long-term choice when you need predictable physical access, sustained workload, fixed peripherals, or hardware you will operate for years. A Linux cloud host cannot replace macOS-specific tools, simulator behavior, Xcode signing workflows, or Apple platform validation.

The weaker options have clear costs. One overloaded local Mac creates a queue and a single failure domain. A virtualized macOS setup adds compatibility and maintenance questions. A generic cloud Runner may not provide the Xcode version, simulator image, permissions, or persistent environment your test suite requires.

If you only need a short-lived acceptance environment, a second CI node, or a controlled migration away from one overloaded Mac, renting a real Mac through KVMNODE can be more flexible than purchasing hardware before the workload is understood. You can first validate the Runner labels, Xcode and Simulator prerequisites, artifact flow, and two-shard behavior, then decide whether longer-term ownership is justified. Review the available remote Mac deployment options only after your baseline shows that node capacity, rather than test instability, is the actual bottleneck.