A practical guide to configuring Xcode Cloud test actions, choosing device destinations, and using test plans so your iOS unit and UI tests run automatically on every build.
Running tests locally is fine for quick checks, but it depends on each developer remembering to do it. Automated testing in CI enforces a consistent quality gate.
Xcode Cloud runs your tests on Apple-managed environments, so results are reproducible and not affected by one machine's quirks.
It can run across multiple simulated devices and OS versions in parallel, which catches issues that only appear on specific configurations.
Because results surface inside Xcode and App Store Connect, the whole team sees failures immediately rather than discovering them after a release.
First, confirm your app has a test target with actual tests. Xcode Cloud runs the tests defined in your scheme or test plan, so empty targets do nothing.
Your scheme must be shared, and its Test action should include the test targets you want to run. Verify this locally before configuring the cloud.
Run your test suite locally at least once to make sure it passes. Debugging a flaky suite is far easier on your own machine than in CI logs.
If you use a test plan, make sure it is committed to source control so Xcode Cloud can read the same configuration you use locally.
Open your workflow in the Xcode Cloud tab and add a Test action, or edit an existing one. The Test action is what actually executes your suite.
Select the scheme that contains your tests. Xcode Cloud uses that scheme's test configuration to determine what runs.
If your project has multiple schemes, be deliberate about which one you pick, since each may include different targets or test plans.
Save and confirm the action appears in your workflow. It will run whenever the workflow's start conditions are met.
Destinations are the simulated devices and OS versions your tests run against. This is one of the most valuable features, because it lets you validate across configurations.
Start small. One or two destinations keep build times and compute usage reasonable while you confirm everything works.
Expand coverage deliberately. Adding an older OS version and a different device family often catches layout and compatibility bugs.
Remember that each destination multiplies work. A large matrix is thorough but consumes compute faster, so balance coverage against your budget.
Test plans let you group tests, set configurations, and control options like localization or runtime sanitizers. They give you far more control than a plain scheme.
Create a test plan in Xcode, add it to your scheme, and commit it. Xcode Cloud will honor the plan when it runs the Test action.
You might keep a fast plan for pull requests and a fuller plan for release branches. This keeps everyday feedback quick while still getting deep coverage before shipping.
Test plans also make it easy to enable or disable specific tests without editing code, which is handy for quarantining a flaky test temporarily.
Decide when tests should run. Running the full suite on every pull request gives strong protection before code merges.
Many teams run a quick suite on pull requests and a broader suite on the main branch. This matches feedback speed to the situation.
Avoid running an enormous device matrix on every single commit if you are watching compute. Reserve heavy runs for branches that matter.
Clear start conditions keep your pipeline both fast and cost-aware, which matters because parallel device testing is one of the bigger compute consumers.
After a run, open the Xcode Cloud tab to see test results. Passing and failing tests are listed per destination, so you can spot configuration-specific failures.
Drill into a failure to view logs, assertion messages, and any captured attachments such as screenshots from UI tests.
UI tests are more prone to flakiness than unit tests. If a test fails intermittently, investigate timing and waits before blaming the infrastructure.
Use the per-destination breakdown to your advantage. A test that passes everywhere except one OS version is a strong clue about the root cause.
As a project grows, the shape of your test suite matters as much as the tooling that runs it.
Lean on a broad base of fast unit tests. They are cheap to run, quick to diagnose, and rarely flaky, which makes them the backbone of a trustworthy pipeline.
Add a smaller layer of integration and UI tests for the flows that genuinely matter to users. These catch problems units cannot, but they are slower and more fragile, so keep them focused.
Name and organize tests so a failure points clearly at a feature. When the report reads like a map of your app, triage becomes far faster for the whole team.
Revisit the suite periodically and prune tests that no longer earn their keep. A lean, reliable suite that people trust is more valuable than an exhaustive one that everyone learns to ignore.
Flaky tests are the single biggest threat to a trustworthy CI pipeline, and UI tests are the usual offenders.
A flaky test passes and fails without any code change, which trains people to shrug at red builds. That erosion of trust is far more damaging than the individual failure.
When you spot flakiness, investigate the timing first. Many UI test failures come from asserting on an element before it has appeared, so replacing fixed sleeps with proper expectations and waits often fixes them.
If you cannot fix a flaky test immediately, quarantine it. A test plan lets you disable a specific test temporarily so it stops blocking everyone while you work on a real fix.
Treat quarantine as a short-term measure, not a graveyard. Track disabled tests and bring them back once stabilized, because a suite full of skipped tests slowly stops protecting you at all.
Keep your suite fast and reliable. Slow or flaky tests erode trust in CI and tempt people to ignore red builds.
Favor a layered strategy: many quick unit tests, fewer focused UI tests, and a sensible device matrix rather than every possible combination.
Monitor compute usage in App Store Connect so a growing test matrix does not quietly consume your included hours.
Finally, keep expectations grounded. Xcode Cloud runs the tests you write against the code you write. It does not generate tests or a native Swift app for you, and shipping still requires Xcode and the Apple Developer Program.
Yes. You choose destinations, meaning simulated devices and OS versions, and tests can run across them in parallel to catch configuration-specific issues.
Not strictly. A shared scheme with a Test action is enough to start. Test plans add finer control, such as separate fast and full configurations.
UI tests are timing-sensitive and prone to flakiness. Review waits and expectations, and check the per-destination logs and screenshots to pinpoint the cause.
Start with a small destination matrix, run heavy suites only on important branches, and monitor compute usage in App Store Connect.
Results appear in the Xcode Cloud tab inside Xcode and in App Store Connect, broken down per destination with logs and attachments.