From Order to First Archive

Connect a Cloud Mac to Your Xcode Build Workflow

This guide covers selection, ordering, connection, environment setup, your first archive, and self-hosted runner integration. Follow the steps in order: get one reproducible release path working first, then add concurrency and caching.

Rent a Cloud Mac Now View Configurations & Pricing

3 tiers: Fixed configurations
4: Available regions
$20.7/day: Starting price

BUILD RUN SHEET First iOS Archive

Ready to Run

Code Repository Dedicated Node Archive Artifact

01
Confirm the plan and nodeKeep the configuration, term, region, and storage expansion aligned
02
Initialize the Xcode environmentCheck the version, command-line tools, Git, and dependency managers
03
Run the first archiveFix the scheme, signing settings, and export parameters
04
Register the CI runnerIsolate the work directory and configure post-build cleanup

SG Singapore JP Tokyo KR Seoul HK Hong Kong

STEP 01

Lock down five inputs before you start

Delivery speed depends less on how many tools you install than on confirming account permissions, repository access, Xcode version, node, and rental term before ordering.

Developer permissions

Confirm that the Apple Developer account has access to the target team, certificates, provisioning profiles, and distribution permissions. Do not wait until the archive is complete to check signing access.

Repository access

Prepare deployment credentials with the minimum required permissions, and confirm access to the main repository, private dependencies, submodules, and large-file storage. Do not reuse personal long-lived credentials for CI.

Xcode version

Specify the required major and build versions precisely, then verify Swift, SDK, and command-line tool compatibility. Pin the runner version instead of relying on temporary switching.

Node location

Choose among Singapore, Tokyo, Seoul, and Hong Kong, prioritizing the node closest to your main developers, repository, and dependency sources. Then validate the choice with a real connection.

Rental term

For temporary signing verification, start with a daily or weekly term; ongoing development and fixed runners are better suited to monthly or quarterly terms. Choose based on your actual build plan rather than assumed utilization.

STEP 02

Choose by workload, not project name

All three tiers are dedicated Apple Silicon physical machines, not virtual machines. Focus on parallel job count, dependency size, cache volume, and unified memory requirements.

Light builds

Go M4 Core

Ideal for single-project validation, temporary signing, lower-concurrency Xcode builds, and short-term tasks that require a dedicated environment.

Chip: M4
Memory: 16GB
Storage: 256GB

Choose Go M4 Core

Everyday development

Go M4 Plus

Ideal for multiple daily projects, React Native or Flutter dependency installation, and continuous integration queues with moderate parallelism.

Chip: M4
Memory: 24GB
Storage: 512GB

Choose Go M4 Plus

Memory-intensive workloads

Go M4 Pro

Ideal for higher-concurrency builds, large dependency caches, and AI inference experiments requiring more unified memory and local storage.

Chip: M4 Pro
Memory: 64GB
Storage: 2TB

Choose Go M4 Pro

STEP 03

Confirm four parameter groups when placing your order

The configurator combines the host, term, region, and add-ons in one order. Review each line before submitting to avoid migrating data after the environment is provisioned.

Order Parameter Checklist Pre-submission check

HOST

Choose one of the three main configurations

Use the configuration card as the source of truth for chip, memory, and system-disk specifications.

TERM

Choose a day, week, month, or quarter

The add-on term must match the host term.

NODE

Choose one of the four available regions

Singapore, Tokyo, Seoul, and Hong Kong are all available in the configurator.

ADD

Add expansions for your workload

Choose +1TB SSD, +2TB SSD, or Thunderbolt 5 for each machine.

Node selection

Start with the node closest to your main workflow

Remote desktop performance depends heavily on the network path between developers and the node; dependency download speed is also affected by repository and source locations. Choose a candidate node first, then test it with a real project.

View Node Details

Availability

Use the console’s real-time response as the source of truth

All combinations listed in the directory can be ordered, while actual availability at order creation is returned in real time by the console. Do not infer current status from page screenshots.

Configure Your Order

STEP 04

Validate through the GUI first, then automate

After receiving the delivery details, use VNC to check the desktop, keyboard, network, and system status. Once the base environment is confirmed, use SSH for scripts and runner jobs.

CONNECTION 01

Complete desktop validation with VNC

Check the resolution, keyboard layout, clipboard, time zone, and network access. During the first validation, avoid changing many system settings at once so variables remain easy to isolate.

Record the node address and connection time
Confirm that the desktop session remains usable
Check basic downloads and repository access

CONNECTION 02

Use SSH for repeatable tasks

Turn code checkout, dependency installation, cache cleanup, and builds into repeatable scripts. Use least-privilege credentials and store them separately from logs and build artifacts.

Limit the projects accessible by the key
Pin the script entry point and work directory
Preserve exit codes and logs for failed commands

STEP 05

Initialize the development environment reproducibly

Verify the system and Xcode first, then install project tools. Record version output at every step so the runner can later distinguish code differences from host differences.

Environment Check Commands ENV-CHECK

$ sw_vers Confirm the macOS version

$ xcodebuild -version Confirm the Xcode and build versions

$ xcode-select -p Confirm the command-line tools path

$ git --version Confirm Git is available

$ fastlane --version Confirm the automation tool version

01
Check the system account
Confirm the current user, home directory, administrator privileges, and mounted disk locations. Do not scatter project directories across the desktop or temporary download folders.
02
Complete the first Xcode launch
Open the target Xcode version, accept the required component installation, and confirm that the command-line tools point to the same version.
03
Install the project dependency chain
Install package managers and dependencies according to the project lockfiles. Do not blindly upgrade locked versions during the first build.
04
Pin Fastlane and script entry points
Use the versions required by the project, and split build, test, archive, and distribution into independently retryable tasks.

STEP 06

Use the first Xcode cloud build to validate one main path

The first pass is not about maximum speed; it is about producing a verifiable artifact from a clean directory. Pin the repository revision, scheme, signing, and export method, then optimize caching later.

Check out a known revision

Use an explicit branch, tag, or commit. Sync submodules and dependency lockfiles, and record the commit associated with this build.

Confirm the scheme

First run xcodebuild -list to check the available schemes and confirm that the target scheme is shared and suitable for command-line builds.

Check signing materials

Verify certificates, provisioning profiles, Bundle Identifier, and team permissions. Never store signing passwords in the repository or ordinary build logs.

Run the archive

Specify the workspace or project, scheme, configuration, and archive path. Preserve the complete exit code and logs when a build fails.

Validate the exported artifact

Check the artifact name, version, build number, signing result, and file size, and confirm that the TestFlight distribution path can receive it.

Success criteria The same commit produces a valid archive again with the same command

Do not optimize yet Concurrency, cache hit rate, and incremental build speed

STEP 07

Put the self-hosted runner in controlled charge of builds

Register the runner only after the first archive succeeds. The key is not simply being online, but isolating work directories, keeping labels clear, restricting project permissions, and restoring the environment after every job.

Work directory

Give each runner a dedicated path

Manage source code, DerivedData, dependency caches, and exported artifacts in separate directories. Never let concurrent jobs write to the same archive path.

Label design

Use labels to describe capabilities, not temporary tasks

Labels can express region, Xcode major version, and workload tier. Avoid putting project names, people’s names, or short-lived branches in permanent labels.

Access scope

Authorize only the projects that need to run

Limit the repositories and variables the runner can read. Separate production signing materials and test-build permissions by workflow.

Cleanup rules

Remove sensitive residue after each job

Remove temporary credentials, export configurations, and artifacts no longer needed. Manage caches by directory, size, and update time instead of clearing everything indiscriminately.

STEP 08

Complete the final delivery check before going live

Add the items below to your team runbook. Once they pass, the runner is ready for continuous builds and TestFlight distribution tasks.

Certificates and provisioning profiles

Confirm validity, team ownership, Bundle Identifier, and usage scope, and record who is responsible for updates.

Free disk space

Check usage from source code, DerivedData, dependency caches, archives, and exported artifacts, and reserve room for consecutive builds.

Cache strategy

Define which directories can be reused, when they expire, capacity limits, and cleanup conditions. Never cache signing passwords or temporary tokens.

TestFlight pipeline

Perform one end-to-end validation from archive export through upload, and confirm that the version number, build number, and release log match.

Sensitive information cleanup

Check the repository, environment files, command history, and build logs, and remove keys, tokens, and signing passwords that should not be retained.

Failure escalation path

Record the order number, node, reproduction time, error logs, and steps already taken. If assistance is needed, submit a ticket through the console.

READY The first build is reproducible, runner permissions are controlled, and sensitive information has been removed

Open the Console to Submit a Ticket

When ready, start with one dedicated node

Choose the configuration, term, and region, get the first Xcode archive working, then connect the stable command to your CI queue.

Rent a Cloud Mac Now Compare the Three Tiers