Can you open an .xcresult bundle without Xcode?

Not directly — it is a macOS bundle that Xcode's Report Navigator understands. Anyone without a Mac and a copy of the project cannot read it, which is why iOS test results usually reach the rest of the team as a screenshot of Xcode.

How do I turn an .xcresult into HTML?

Use a converter over the bundle: `xcresulttool` (bundled with Xcode) exports JSON you can template, and community tools like xchtmlreport read the bundle directly and write a self-contained HTML report with the failures, durations and attached screenshots.

How do I share it with the team?

Publish the generated HTML to a URL from your CI job. A designer, a PM or a backend engineer opens a page — no Mac, no Xcode, no project checkout, no artifact download.

What about failure screenshots?

Attach them as report assets — 25 MB per file, 250 MB and 500 files per report. A UI test failure is nearly unreadable without the screenshot, and it lives next to the report and the discussion instead of expiring with the CI artifact.

Can I keep the same link across runs?

Yes. Save the report id as a CI variable and PATCH it every run. Each run appends a revision at the same URL, so the link in your PR template never goes stale and two runs can be diffed to see which tests changed state.

Share an Xcode test report

xcodebuild test produces an .xcresult bundle: genuinely rich, with per-test timing, attachments, and video of UI test failures. It is also a macOS bundle that only Xcode can read.

So iOS test results reach everyone else the way they always have — as a screenshot of the Report Navigator, cropped to the red row.

Convert the bundle to HTML

xcodebuild test \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 15' \
  -resultBundlePath TestResults.xcresult || true

# community converter: reads the bundle, writes a self-contained report
xchtmlreport -r TestResults.xcresult
# → TestResults.xcresult/index.html

Apple's own xcresulttool exports the bundle's JSON if you'd rather template it yourself:

xcrun xcresulttool get --path TestResults.xcresult --format json

Note the || true — a failing test fails xcodebuild, and everything after it has to survive that. That's the run you most want published.

Publish it

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html index.html \
        --arg title "iOS tests — $(git rev-parse --short HEAD)" \
        '{title: $title, html: $html}')"

Use a scoped token (reports:write) from CI secrets and PATCH a saved report id, so one URL accumulates a revision per run rather than a new orphan link every build. In GitHub Actions mark the step if: always(). See publishing from CI.

For a one-off, drag the generated report folder into the app — the entry HTML becomes the report body and the screenshots upload alongside it with relative references rewritten.

Attach the screenshots

A failed UI test assertion is close to unreadable as text. XCTAttachment screenshots are the actual evidence, and in the normal flow they expire with the CI artifact retention window.

Upload them as report assets and they live next to the report and the discussion permanently — 25 MB per file, 250 MB and 500 files per report. See the API reference.

Who the audience actually is

This is the part that makes iOS reports worth publishing more than most. The people who need to see a failing UI test are frequently not iOS engineers:

The designer who wants to know whether the layout regression is real.
The PM triaging whether to ship.
The backend engineer whose API change broke the integration test.

None of them have Xcode open. All of them can open a URL, and all of them can leave a comment anchored to the specific failure — which then stays attached across runs, so a chronically flaky UI test carries its own history rather than being re-litigated every sprint. See commenting on HTML.

Who can see it

Per report: private, your team, any signed-in user with the link, or public. Test reports name internal screens and API paths, so team is the usual default. Domain-gating, password gates and expiring links are Enterprise. See sharing & access control.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total — UI test video can hit the per-file limit, so prefer screenshots or trim the recording.
Scripts run, sandboxed (allow-scripts, no allow-same-origin), so the report's filtering and collapsible sections keep working.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a test report →