A month-old crash needs investigation, but the matching Xcode Cloud build artifact is no longer downloadable.

Fastest fix: download release artifacts on build day, then use App Store Connect API automation for every continuing project. Keep the archive in independent storage and test recovery instead of treating Xcode Cloud as a permanent repository.

Who should follow this timeline?

This guide is for independent developers who publish through Xcode Cloud but have never stored build artifacts separately.

It also fits maintainers who need historical symbol files for crash investigation and small teams that want a remote Mac for archiving, inspection, and recovery of xcarchive and xcresult files.

The retention deadline changes your backup decision

As of August 30, 2026, Apple’s documentation states that Xcode Cloud build information and artifacts are accessible for up to 30 days. The same documentation describes downloading artifacts through Xcode, App Store Connect, or the App Store Connect API. That makes the 30-day window an access boundary, not a long-term retention policy. Apple’s Xcode Cloud workflow documentation is the source to recheck if Apple changes the policy.

If you release occasionally, schedule a manual download immediately after each release. If you build continuously, automate the download and retain an independent recovery copy.

Do not archive every temporary build forever. First classify the files by the problem they solve:

  • Release xcarchive: useful for examining the exact release build, checking version metadata, and supporting later distribution analysis.
  • dSYM and symbol information: needed to translate crash addresses into readable functions and files. Apple’s crash report and device log guidance explains why matching symbols matter during diagnosis.
  • Build logs: useful for investigating signing, dependency, compiler, and environment failures.
  • xcresult: contains test and build result data that can support failure analysis and audit evidence. Apple explains how to run tests and interpret their results.
  • Ordinary branch builds: often have less long-term value unless they document a shipped behavior, a customer incident, or a release candidate.

The key distinction is between an artifact generated by the Xcode Cloud workflow and an extra file that your script uploads elsewhere. A file copied to external storage by a build script follows your storage policy. It should not be assumed to share the same access behavior as the Xcode Cloud artifact list.

Day 0: create a traceable archive baseline

The first backup should be manual. It gives you a reference copy before you automate anything.

Step 1: locate the exact build

Open the project in Xcode or use App Store Connect to find the successful build. Record the App, marketing version, build number, workflow name, build identifier, result status, and completion date.

Do not name a file only release.zip. That name loses the relationship between the artifact and the build record. Use a path with enough identity to search later, while keeping account IDs and internal project details out of shared screenshots or public logs.

A practical structure is:

app-slug/
  version/
    build-number/
      workflow/
        build-id/
          archive/
          symbols/
          test-results/
          logs/
          manifest.json

Replace each value with a sanitized identifier. The real App ID, team information, API key, and private paths should remain outside documentation intended for public sharing.

Step 2: download the official artifacts

Download the release archive and the associated symbol files from the build record. If test evidence is part of your release process, also save the relevant xcresult or test result package. Xcode Cloud exposes artifact information through its workflow and build records; the App Store Connect API build run documentation provides the build-level resource model.

The goal is not to collect screenshots of the interface. Save the actual downloadable files and a small manifest that records:

  • App identifier in a redacted or controlled form
  • Version and build number
  • Workflow name
  • Build ID
  • Artifact type
  • Download timestamp
  • File path
  • Checksum
  • Download result

Step 3: verify the baseline before it leaves the machine

A successful browser download is not yet a usable backup. Confirm that the archive can be opened, that the version metadata matches the intended build, and that the symbol files are present.

For a compressed artifact, inspect the archive without modifying the original. For an xcarchive, check that its bundle structure is intact. For xcresult, confirm that the result bundle can be opened or inspected with the tools available in your macOS environment.

Keep the original downloaded file unchanged. Perform inspection on a working copy and write the result to the manifest. This separation helps you distinguish “the file downloaded” from “the file can be recovered.”

Day 1 to Day 7: replace repeated downloads with API automation

The App Store Connect API can automate artifact retrieval, but the reliable design is a selection-and-recording workflow rather than a collection of isolated endpoint calls.

The sequence should be:

  1. Authenticate with an API credential stored outside the repository.
  2. Find the relevant build run.
  3. Filter for a successful Archive or release workflow.
  4. Read the available actions and artifacts.
  5. Select the artifact types your policy requires.
  6. Download each artifact.
  7. Write build identity, artifact identity, checksum, and status to a manifest.
  8. Retry or alert when an expected artifact is missing.

The Artifacts API reference describes the artifact resource. The endpoint for retrieving artifacts associated with a build action is documented in Apple’s build action artifacts reference. Use those resources to confirm current field names and response behavior instead of hard-coding assumptions from an old script.

A credential example should remain a placeholder:

ASC_KEY_ID="YOUR_API_KEY_ID"
ASC_ISSUER_ID="YOUR_ISSUER_ID"
ASC_PRIVATE_KEY_PATH="/secure/path/AuthKey_YOUR_KEY_ID.p8"

These values are only for API access. They are not code-signing assets, and they do not grant interactive access to a remote Mac.

Keep three permission domains separate:

  • API access credentials: used by the archive job to query and download App Store Connect resources.
  • Code-signing assets: certificates, provisioning profiles, and private keys used to sign an app. Do not place private signing keys in an ordinary artifact directory.
  • Remote Mac login permissions: SSH, VNC, or console credentials used to inspect files or run recovery commands.

This separation limits the impact of a leaked archive job credential. It also prevents a later operator from confusing a downloadable build artifact with the ability to sign a new release.

How should the backup handle a deleted Xcode Cloud build?

Treat deletion or expiration as a loss of the Xcode Cloud copy unless you have already stored an independent copy. The API can retrieve artifacts that are available through the documented build and artifact resources; it should not be treated as a recovery service for an artifact that is no longer accessible.

That is why the job should run soon after a successful release, not near the end of the access window. A scheduler can also scan recent builds and find any successful release that lacks a manifest. This compensation scan protects against a webhook outage or a temporary download failure.

Choose an event trigger or a scheduled scan

Xcode Cloud webhooks can notify an external task when a build event occurs, but a webhook is only a notification channel. It does not store your archive. Apple documents the setup in its guide to configuring Xcode Cloud webhooks.

Use this comparison before choosing the trigger:

Operating pattern Primary trigger Required fallback Main risk
Occasional release Scheduled scan after release Manual check of the release build A missed schedule delays archiving
Frequent release Build-complete webhook Scheduled compensation scan Notification or download failure
Release candidate testing Event trigger for selected workflows Review before promotion Temporary builds enter storage unnecessarily
Incident-sensitive production app Event trigger plus release checklist Periodic recovery audit A valid download may still be unreadable

For low-frequency releases, a scheduled task is easier to operate. For high-frequency releases, an event trigger reduces the delay between build completion and external archiving. In both cases, retain a scan that searches for successful builds without a completed manifest.

Make the process idempotent. Use the build ID, workflow, artifact ID, and artifact type as the logical key. If the job runs twice, it should verify the existing copy rather than create an uncontrolled duplicate. If a download stops midway, write a failed state and retry it rather than marking the artifact as complete.

Release day: prove that the archive is recoverable

Release day is the point where a backup becomes evidence. Do not finish the task when the download command returns a success code.

Step 4: compare identity

Confirm that the version and build number in the archive correspond to the App Store Connect build you intended to publish. The build record, archive metadata, and manifest should point to the same release.

A mismatch can happen when a developer downloads the latest available artifact instead of the artifact tied to the release workflow. The filename may look correct while the internal metadata identifies another build.

Step 5: inspect the archive and result bundle

Extract a working copy and check that the xcarchive is readable. Confirm that its application bundle and symbol information are present. Open or inspect the xcresult bundle and verify that the expected test or build results can be read.

The exact inspection command depends on your Xcode version and the tools installed on the recovery machine. The invariant is simpler: an operator must be able to locate the bundle, open it, and identify the release without relying on the original Xcode Cloud interface.

Step 6: test symbol availability

Take a redacted crash report or a controlled diagnostic sample and confirm that the retained symbol information can be used for analysis. Apple’s crash report guidance is the appropriate reference for the relationship between crash data and symbols, rather than an assumption that every dSYM is interchangeable.

Do not expose customer data, production tokens, device identifiers, or signing secrets in the test package. The recovery test should prove file usability without becoming a second security incident.

Step 7: record the result

Update the manifest with extraction status, metadata comparison, result-bundle readability, symbol inspection, and the location of the recovery copy. A checksum proves that bytes have not changed; it does not prove that the archive is semantically useful. Store both kinds of evidence.

Day 30 and beyond: apply retention by release value

A single universal retention period is rarely appropriate. Define policy by the role of the build:

  • Internal test builds: retain only when they explain a regression, customer report, or important test milestone.
  • Release candidates: retain through the decision period and any verification window your team requires.
  • Production releases: retain the archive, matching symbols, manifest, relevant logs, and test evidence according to your support and audit needs.
  • Failed builds: keep them when they document a recurring failure or a release-blocking incident; otherwise allow them to follow a shorter cleanup policy.

Do not mix ordinary artifacts with secrets. Certificates, provisioning profiles, API private keys, and remote login credentials require separate access controls and rotation procedures. An archive directory should be useful for diagnosis without becoming a shortcut to publish unauthorized code.

Assign storage roles deliberately:

  • Local disk: fast working space for downloads and extraction.
  • Object storage: independent retention and access control for the canonical copy.
  • A persistent remote Mac: a controlled environment for opening historical Xcode artifacts, running symbolication tools, and executing recovery scripts.

A remote Mac is not automatically a backup. It becomes part of a sound archive process only when the files are copied there through a repeatable job, permissions are controlled, and recovery is tested. If you need a continuously available macOS environment for release operations, compare the workflow with a remote Mac build server before deciding whether a short-lived machine is sufficient.

The monthly recovery checklist

Run this checklist after automation is stable and repeat it on a regular schedule:

  • [ ] Select one archived production build using only its manifest metadata.
  • [ ] Confirm that the independent copy exists outside Xcode Cloud.
  • [ ] Verify the checksum against the recorded value.
  • [ ] Extract a working copy without altering the canonical file.
  • [ ] Open or inspect the xcarchive.
  • [ ] Match the archive version and build number with App Store Connect.
  • [ ] Read the retained xcresult or test result package.
  • [ ] Confirm that symbol files are available for the selected crash-analysis case.
  • [ ] Check that no certificate private key or API private key is inside the artifact directory.
  • [ ] Record the recovery result and investigate any silent download or extraction failure.

The checklist is intentionally operational. It catches a more serious failure than a missing file: a file that exists but cannot support the investigation you saved it for.

When a remote Mac improves the recovery workflow

For a developer who only downloads one release occasionally, local storage and a scheduled script may be enough. Buying or renting a dedicated machine is harder to justify when there is no recurring macOS task.

The decision changes when you must repeatedly open old archives in Xcode, run symbolication tools, inspect test results, or keep a download worker online. A persistent remote Mac gives that recovery process a known macOS environment and avoids moving every archive to a different personal computer. You can review Mac rental options only after defining the storage, access, and recovery tasks the machine must perform.

That environment still needs independent storage. A remote Mac with one disk copy is not a substitute for a second retention layer, and a storage bucket without a tested macOS recovery path may slow down investigation when an old release matters.

Xcode Cloud is convenient for building and distributing workflows, but its documented 30-day artifact access window makes it a poor sole repository for long-lived release evidence. Your current approach may leave you searching an expired build record, downloading manually under time pressure, or keeping an unverified archive that cannot be opened when a crash appears. If you need a persistent macOS node to run the download job, inspect xcarchive and xcresult, or repeat symbolication checks, renting a Mac from VMSPIN can be a more controlled fit than dedicating a personal computer to an always-on recovery task. Review the available remote Mac access options, then choose a short-term environment for occasional releases or a longer-running node only when the workflow genuinely requires it.