What To Back Up When Migrating An iOS Build Machine? 2026 Xcode 27 Checklist

The winning approach is metric-based migration: back up and verify source inputs, the Xcode 27 toolchain, signing identities, release credentials, archives, and automation before the old Mac is cleaned or returned. This applies when the replacement Mac must independently build, Archive, sign, upload, and recover after the previous host goes offline.

This article is for:

• Independent developers preparing to return a remote Mac without losing release capability.
• CI maintainers moving Xcode 27 jobs to another Mac.
• Small teams taking over an outsourced project or rebuilding a failed iOS build machine.

A project folder is not a complete migration. If the old host contains the only private key, archive, API credential, or Runner configuration, copying the repository creates a new machine that looks ready but cannot ship.

The migration baseline: release recovery, not file transfer

Start with the last successful release. Save its relevant facts before touching the old environment:

• Xcode version and macOS version.
• Workspace or project entry point.
• Scheme and build configuration.
• Dependency resolution result.
• Signing method.
• Archive version and build number.
• Distribution destination.
• Upload method.
• Runner label and job path.

Xcode 27 system compatibility must be checked against Apple's current Xcode system requirements. Do not infer compatibility from the old Mac. A replacement host may have the same project files but a different macOS requirement, SDK availability, command-line tool path, or installed Xcode selection.

The migration passes only when the new environment can perform all of these actions without reading a directory that exists only on the old machine:

1. Obtain a clean checkout.
2. Resolve the same dependency graph.
3. Run the intended build configuration.
4. Create an Archive.
5. Sign the Archive with the required distribution identity.
6. Export or upload through the intended release route.
7. Repeat the critical task while the old host is disconnected.

A visible certificate in Keychain Access is not enough. A copied IPA is not enough. A successful local build that never reaches Archive is not enough.

Migration stop condition: If the new Mac still needs the old host's private key, workspace cache, shell variable, shared folder, or Runner registration, the migration is incomplete.

Compare migration targets by recovery value

The following comparison separates material that can usually be regenerated from material that can block a release if lost.

The important distinction is reversibility. A dependency package may be downloaded again. A release Archive may not be reproducible after source, signing, or build configuration changes. A certificate file may be public. Its private key is the part that allows the identity to sign.

This is why a backup inventory should use separate categories rather than one large archive of the user directory.

Source inputs must rebuild without the old Mac

A replacement host should begin from a clean checkout. Do not use DerivedData as proof that the environment is portable. DerivedData is a build output cache, not a substitute for dependency declarations, scripts, source files, or a documented toolchain.

Record and preserve:

• The exact repository commit used for the last successful release.
• Git submodule references and access method.
• Swift Package Manager resolution files.
• CocoaPods lock files, if the project uses CocoaPods.
• Any package manager configuration required by private dependencies.
• Build scripts and release scripts.
• Workspace and project files.
• Scheme files where they are shared or required by CI.
• Configuration templates for values intentionally supplied by CI.
• Non-secret build inputs that are not tracked in version control.
• The clean-checkout command and dependency resolution command.

Private repository access needs its own ownership record. A new Mac may have valid source credentials but still fail when a package manager accesses a private repository. Keep repository permissions separate from signing permissions. A developer who can clone source code does not automatically have the right to upload an App Store release.

A simple clean-checkout test can expose hidden dependencies:

git clone --recurse-submodules "$REPOSITORY_URL" ios-release-check
cd ios-release-check

xcodebuild -resolvePackageDependencies \
  -workspace "ExampleApp.xcworkspace" \
  -scheme "ExampleApp"

Expected output should show the intended workspace and a successful dependency-resolution result. It should not reference /Users/old-builder, a mounted volume, or an obsolete shared directory.

The evidence should include the commit identifier, dependency lock state, and the path used by the new host. If the build needs a local configuration file, store a redacted template and document how the secret value is injected. Do not place production secrets in a repository merely because the old Mac used a local file.

Toolchain identity is a separate migration metric

Xcode 27 is not just an application bundle. The release process also depends on the selected developer directory, command-line tools, SDK selection, schemes, export settings, and scripts.

Capture the active toolchain before migration:

xcode-select -p
xcodebuild -version
xcodebuild -showsdks

Example output format:

/Applications/Xcode.app/Contents/Developer
Xcode 27.x
Build version ...
iOS SDK ...

The exact version and SDK output must be copied from the real source machine. The example above is a format illustration, not a claim about a particular Xcode 27 build. Apple remains the authority for Xcode 27 system requirements and supported combinations, so confirm the current state in Apple's Xcode requirements documentation.

Also record:

• The Xcode application path.
• The active DEVELOPER_DIR, if CI sets it.
• The scheme used for Archive.
• Release configuration names.
• Export method and export options.
• Required command-line tools.
• Any custom build settings supplied by the Runner.

A new host passes this metric when the same clean checkout uses the intended Xcode path and creates the intended Archive. Installing Xcode 27 without reproducing the build invocation leaves the most important part untested.

Signing assets need identity-level verification

Signing migration fails most often when the public certificate is copied but the private key is not.

Separate these objects:

• Apple Distribution certificate.
• Matching private key.
• Provisioning Profile.
• Keychain access behavior.
• Automatic signing state.
• Bundle ID and entitlements.
• App Store Connect upload credential.

Apple documents identity import through a PKCS #12 package in its identity import guidance. The practical implication is direct: export and protect the complete identity. A .cer file alone does not recreate the signing identity held by the old Keychain.

Before exporting or rotating anything, write down:

• What release flow uses the identity.
• Where the protected backup will be stored.
• Who can access it.
• What happens if import fails.
• Whether revocation would affect another machine or product.
• How the old state will be restored.

Do not revoke a certificate just because a new Mac is being prepared. First import the identity into a controlled Keychain on the new host, then test the target Archive. Certificate revocation and key rotation are operational changes, not ordinary file-copy steps.

Inspect the identity without exposing private material:

security find-identity -v -p codesigning

The output should show the expected signing identity on the new host. That is only an intermediate check. The passing evidence is a correctly signed Archive created with the same distribution intent as the last successful release.

Provisioning Profiles are a different asset. They may be downloaded or managed again under the appropriate Apple Developer account. Apple describes the available profile actions in its Provisioning Profile management documentation. Record the profile name, Bundle ID relationship, entitlements, and expiration state without assuming that a downloaded profile fixes a missing private key.

Rollback rule: Never revoke the only working distribution identity before the replacement Mac has imported a protected copy and completed a representative signed Archive.

Archives, dSYM files, and IPA files have different recovery roles

Keep release artifacts by recovery value, not by file size.

A useful retention set includes:

• The xcarchive for each important release.
• Matching dSYM files.
• xcresult bundles from release validation or troubleshooting.
• Export options used to create the distribution package.
• The final IPA when it is part of the release record.
• Version and build number.
• Archive UUID.
• Upload or TestFlight record.
• Commit identifier.
• Xcode and SDK record.

An IPA is a delivery package. It does not replace the full Archive or the matching debug symbols. Apple explains how to locate a missing debug symbol file in its dSYM troubleshooting documentation. This is why dSYM files should be tied to the exact release build rather than stored in an undifferentiated folder.

Use a manifest to make the backup auditable:

find "ReleaseArchives/ExampleApp.xcarchive" -type f -print0 \
  | shasum -a 256

dwarfdump --uuid "ReleaseArchives/ExampleApp.xcarchive/dSYMs/ExampleApp.app.dSYM"

Example output format:

UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (arm64)

The UUID shown here is a placeholder. The real value must be recorded from the actual Archive. Match it with the crash-report symbolication record or release manifest.

Restore the backup into a test directory. Open the Archive in Xcode or use the intended export command. Confirm that the restored object is readable and that its UUID, version, and build number match the release record. A file that copied successfully can still be incomplete, inaccessible, or unusable after transfer.

API credentials and automation must be handed over separately

App Store Connect API access is not the same as Apple Distribution signing. Treat these as separate control planes:

• Repository access.
• Host login access.
• Keychain and private-key access.
• App Store Connect API access.
• Runner registration.
• Notification and log access.

For API uploads, record the Key ID, issuer information, account scope, and protected private key according to the project’s access policy. Apple documents API key management in its App Store Connect API guidance. Do not paste the private key into a shell command, issue tracker, or repository.

Fastlane or another automation layer may also depend on:

• Environment variable names.
• Secret-store references.
• Working directories.
• Temporary keychain creation.
• Export options.
• App Store Connect provider settings.
• Notification destinations.
• Artifact upload paths.
• Background service configuration.

Use redacted placeholders in migration records:

TEAM_ID=REDACTED_TEAM_ID
BUNDLE_ID=com.example.app
APP_STORE_CONNECT_KEY_ID=REDACTED_KEY_ID
RUNNER_LABEL=ios-release-mac
REPOSITORY=REDACTED_REPOSITORY

The Bundle ID and runner label may be operationally necessary, but credentials must not be copied into documentation in usable form.

Register the new self-hosted Runner first. Run an isolated validation job that checks checkout, dependency resolution, Xcode selection, signing access, Archive creation, artifact storage, and upload authentication. Only after that job passes should the old Runner stop accepting work.

The official self-hosted Runner removal procedure should be followed for the relevant automation platform. Removing a Runner is not equivalent to deleting a folder. The registration must be removed, background services must stop, and any replacement label must be confirmed.

FAQ: migration decisions that can block a release

Which files should be copied when replacing an iOS build machine?

Copy the source repository, submodules, lock files, scripts, required configuration templates, signing assets, release Archives, dSYM files, xcresult bundles, export settings, and automation configuration. Do not copy the entire user directory as the default plan. A clean checkout and a new-host build must prove that no old-machine path is required.

How should signing certificates and private keys be backed up before leaving a remote Mac?

Export the complete signing identity, including its matching private key, in a protected PKCS #12 package. A public certificate file alone cannot reproduce the identity. Record the backup location, access control, import procedure, and rollback plan. Import the protected identity on the new Mac and verify it with a signed Archive before revoking or rotating anything.

Should xcarchive and dSYM files be retained?

Retain the xcarchive and matching dSYM files for releases that may need crash symbolication, historical verification, or re-export. Keep the IPA as a delivery artifact, but do not treat it as a replacement for the Archive and symbols. Record the Archive UUID, version, and build number, then restore and inspect a copy.

How should a self-hosted Runner move to a new Mac?

Set up the new Runner with the required repository access, labels, secrets, paths, and signing permissions. Run an isolated job first. After it creates and validates the expected Archive, stop the old Runner from accepting jobs and remove it using the platform's documented procedure. Check logs and notification routes before production use.

When can the old build machine be safely cleaned?

Only after the new host completes a real Archive, the intended signing operation, and an upload or equivalent release verification. Disconnect the old host and repeat the critical job. Then remove the old Runner, stop services, rotate temporary credentials, and inspect shared folders and shell history. Keep the old host available if any unique signing asset remains unverified.

The final acceptance card

Use this decision sequence before returning a remote Mac or deleting its disk.

Source reproducibility

• Clean checkout succeeds.
• Submodules and private dependencies resolve.
• Lock files match the release baseline.
• Build scripts do not reference old paths.
• Required non-secret configuration is documented.

Toolchain reproducibility

• Xcode 27 path is recorded.
• xcode-select points to the intended developer directory.
• The expected scheme and Release configuration are selected.
• The new host uses the supported macOS and Xcode combination documented by Apple.
• Archive invocation is recorded.

Signing availability

• Apple Distribution certificate is present.
• Matching private key is present.
• Provisioning Profile matches the intended Bundle ID and entitlements.
• Keychain access works under the automation account.
• A signed Archive passes without the old host.

Artifact recovery

• Release xcarchive files are backed up.
• Matching dSYM files are present.
• xcresult and export settings are retained where needed.
• Archive UUID, version, and build number are recorded.
• A restored copy opens or exports successfully.

Automation takeover

• New Runner is registered.
• Labels and repository permissions are correct.
• API upload credentials work within their intended scope.
• Secrets are injected without appearing in logs.
• A validation job completes before production jobs are enabled.

Old-host cleanup

• A real release task succeeds on the new host.
• The old host is disconnected during a repeat test.
• Old Runner registration is removed.
• Background services are stopped.
• Temporary credentials are rotated or revoked with a rollback record.
• Shared directories and shell history contain no remaining secrets.

If any category fails, choose short-term parallel retention rather than immediate cleanup. The cost of keeping the old host briefly is easier to evaluate than recovering a lost private key or an unreproducible release.

Choosing the next Mac environment

A local Mac is a strong fit when the team needs permanent hardware, physical devices, direct USB access, or heavy daily workloads. A remote Mac is more suitable when the immediate need is a dedicated Xcode 27 build host, a replacement for a failing machine, or a continuously available CI environment without buying another Mac.

The current setup may be a poor long-term choice if it depends on one developer's laptop, a shared desktop session, undocumented Keychain state, or a rented host that expires before the migration test is complete. Those weaknesses create release risk even when the build itself is fast.

For teams moving from a temporary or unstable host, SFTPMAC's remote Mac access options can be evaluated against the required Xcode path, root access, remote connection method, and automation workload. Before committing, compare the available Mac rental pricing with the cost of keeping a local machine available for the same release role.

The better choice is the environment that passes the acceptance card. A remote Mac is not a substitute for migration discipline, but it can provide a clean, always-available target for Xcode 27 builds when the current machine is ending, unstable, or too tightly coupled to one person's desktop. First complete one release without the old host. Then decide whether the old machine still has a justified recovery role.