Keep your build jobs running

Check the current developer directory and version, and make sure the target Xcode version is installed. The example below switches the system-wide default to /Applications/Xcode.app. To use another version, replace it with the actual application path.

xcode-select -p
xcodebuild -version
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version
xcrun --find swift

A system-wide switch affects other jobs launched afterward. If different pipelines need different versions, set DEVELOPER_DIRin each job's environment instead of having jobs repeatedly change the global directory.

DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
xcodebuild -list -workspace MyApp.xcworkspace

After switching, list the schemes and run an Archive. If platform components are missing or first-run setup is required, initialize the toolchain in the macOS graphical interface before resuming automation.

Prepare a certificate export that includes the private key, its password, and a provisioning profile that matches the app identifier and distribution method. A certificate without its corresponding private key usually can't sign code.

1. On the macOS account that runs the build, open Keychain Access and import the certificate into that user's keychain.
2. Expand the certificate and confirm its private key is listed beneath it. Use the command below to check for valid code-signing identities.
3. Install the provisioning profile as required by your Xcode version. In the project signing settings, verify the Team, Bundle Identifier, and distribution method.
4. Check signing settings for the app, widgets, and extensions individually, then validate the Archive and export.

security find-identity -v -p codesigning

The CI execution user's keychain environment may differ from that of the remote desktop user. For unattended builds, unlock the keychain in the job and configure the required access permissions. Read passwords from protected CI variables; don't store them in your repository, command output, or support ticket.

If a manual build succeeds but CI fails, first compare the execution user and keychain state. For signing errors, provide only the certificate type, validity period, and redacted error lines. Never upload private keys or certificate passwords.

Don't treat reinstallation as a way to preserve files. It may erase the system and working directories. Before submitting a request, confirm the scope of work through a console ticket and back up data outside the node. At the end of the rental term, the node's disks are erased, so it can't be used to recover data afterward.

Back up at least any unpushed source code, build configuration, essential artifacts, provisioning profiles, and protected key material. Caches such as DerivedData and dependency downloads can be regenerated, but they may slow the first build after restoration.

A completed backup isn't necessarily restorable. Extract it to a separate directory, check the file count and key settings, and make sure you can retrieve the latest artifact before stopping jobs on the original node. After reinstallation, reinstall the toolchain, restore the signing environment, and register the runner again.

Sign in to the account used for the order. In the console, check the instance, expiry date, and available renewal periods, then pay the invoice shown on the page. Use the live result in the console to confirm the renewal and new rental term—not a payment screenshot or the page shown before you closed your browser.

We accept USDT-TRC20 and Visa, Mastercard, and Amex via Stripe. All payments are charged in USD; actual payment options depend on the gateways returned by the backend. Before an on-chain payment, verify the network, amount, and recipient details. After a card payment, return to the console and check the invoice.

If the invoice and instance status don't match, submit the order number, invoice number, and transaction reference. Don't make another payment to try to fix the status, and never send your full card number in a ticket. Back up artifacts and essential files before expiry; renewal isn't a data backup method.

First check the node address, port, username, and instance status in the console. Distinguish a connection timeout from an authentication failure: for a timeout, check network reachability; for an authentication failure, check the username, password, or key. SSH and VNC have separate connection details—don't mix up their ports.

ssh -v -p PORT USER@HOST

Replace PORT,USER, andHOST with the actual details. If the logs show a changed host fingerprint, confirm the reason using trusted console information or a support ticket. Don't disable host identity verification.

Use remote desktop to check the macOS graphical interface, Keychain, and Xcode settings; use SSH for command-line work and CI. Before sharing logs, remove sensitive information from usernames, addresses, and local paths. Keep only the error type and sequence of events.

Check four things: whether the runner is online, whether the job's labels match, whether the project is allowed to use the runner, and whether the process runs as the correct user. Successful registration only establishes an association—it doesn't mean every job will be assigned to that node.

Start with a test job that only prints toolchain information. Confirm the execution user, directory, and Xcode version before adding dependency installation and signing steps.

whoami
pwd
xcode-select -p
xcodebuild -version
security find-identity -v -p codesigning

Include the macOS version, chip architecture, and purpose in the labels, then select them explicitly in the project settings. For the initial setup, limit execution to one job. Check that caches, keychains, and artifact directories don't overlap before increasing concurrency. Treat registration tokens as credentials—never include them in tickets or build logs.

First confirm that you're using the correct workspace, shared scheme, and Release configuration. Archive and simulator builds follow different paths; check signing, architecture, and export settings for the device target separately.

xcodebuild -list -workspace MyApp.xcworkspace
xcodebuild archive \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/MyApp.xcarchive

Keep the first substantive error and its context instead of just the final failure message. Check dependency installation, script phases, signing, and disk writes separately. After Archive succeeds, validate the exported artifact too; a completed archive doesn't mean a distributable package has been created.

First check disk usage and job status, then distinguish rebuildable caches from artifacts you need to keep. Don't delete a directory that a running job depends on, or treat source code, signing materials, or an Archive that hasn't been uploaded as cache.

df -h
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

Set separate retention rules for caches and artifacts. The first compile and dependency resolution after cleanup may take longer, so treat that build as a cold-start test. If you regularly run short on space, measure project and artifact growth before choosing a more suitable machine or SSD add-on.