Choose by workflow, not guesswork

One Cloud Mac, Four Ways to Use It

Add a dedicated Apple Silicon physical node to your development workflow. It’s not a virtual machine: connect over SSH or use the macOS desktop. From a one-off build to a persistent CI pipeline or inference experiments on unified memory.

Rent a Cloud Mac

Three configurations, five locations. Shell M4 from $21.8/day. Start by testing your own project.

01 / BUILD

Keep your main machine.
Move Xcode to the cloud.

Write code on Windows or Linux as usual, then sync your repository to a cloud Mac when it’s time to ship and run the build over SSH. Switch to the macOS desktop when you need to check project settings, simulators, or signing configuration. There’s no need to move your entire day-to-day development setup.

Shell M4 is a good place to validate the build and archive workflow for a single project. Whether 16GB of unified memory is enough depends on project size, simulator count, and the tools you run at the same time. Track peak memory use and the time for a clean build before deciding whether to move up a tier.

  • Check the Xcode and dependency versions pinned by your project to avoid builds that pass locally but fail remotely.
  • Run an unsigned build first, then configure certificates and provisioning profiles you’re authorised to use.
  • A successful archive isn’t the same as a completed release. Check signing, distribution permissions, and the build artifact separately.
02 / AUTOMATE

A dedicated runner
for macOS builds

Register a dedicated physical node as a GitLab or GitHub self-hosted runner to bring commits, tests, archives, and artifact delivery into one pipeline. Nodes run year-round, 365 days a year; your team configures job scheduling, process supervision, and build cleanup for each project.

With 24GB of unified memory and a 512GB SSD, Shell M4 Plus gives dependency resolution, builds, and tests room to run while keeping repositories, dependency caches, and build artifacts on hand. Start with one concurrent job. Monitor CPU, memory pressure, and disk usage before increasing concurrency—logical concurrency doesn’t automatically translate to higher throughput.

  • Run CI under a dedicated macOS user rather than sharing a working directory with interactive desktop use.
  • Label runners with macOS, chip architecture, and Xcode version to keep jobs on the right runner.
  • For jobs that need a GUI session or signing keychain, verify permissions in the same user session first.
  • Only allow trusted repositories to run on a runner that holds release credentials. Isolate code from external contributors.
03 / VERIFY

Make overnight tests easy to review

Use fastlane to orchestrate jobs, XCUITest to run UI tests, and result bundles to preserve the context behind failures. Stabilise the test environment before expanding device coverage.

Start with simulator regression tests

Install the simulator runtimes your project needs and pin the target device and OS version. Run xcrun simctl list devices available to see available targets, then add the chosen device identifier to your test configuration.

Save .xcresult bundles, screenshots, and logs from overnight jobs. When a test fails, work out whether it’s a product bug, a flaky test script, or an environment issue instead of masking the cause with endless retries.

Good for: pull request checks and overnight regression

Real iOS devices need separate arrangements

Renting a physical Mac doesn’t include an iPhone or iPad. iOS devices aren’t included in the service catalogue, and device access isn’t promised by default. Before ordering, confirm who owns the device, how it will connect, and which testing tools you plan to use.

A USB device attached to your computer won’t appear on the remote Mac just because you’ve connected over SSH. Your test setup needs an accessible device, the right pairing and trust relationship, and the required signing permissions. Email us to confirm feasibility first.

Email us about device testing

Keep a result bundle for every run

Run this after configuring a fastlane test lane in your project. Give each job its own results directory, then retrieve it when testing finishes instead of letting files pile up on the node.

bundle exec fastlane scan \
  --scheme App \
  --result_bundle true \
  --output_directory build/test-results
04 / EXPERIMENT

Test your inference setup
on unified memory

Shell M4 Pro pairs an M4 Pro chip with 64GB of unified memory and a 2TB SSD. Use MLX or llama.cpp to test model loading, quantised variants, context length, and the Metal inference path. CPU and GPU share unified memory, but that doesn’t mean all of it is available for model weights.

Estimate the weight memory first, then leave room for everything else. As a rough guide, 4-bit weights need about 4GB for an 8B model and 16GB for a 32B model. That’s just parameter count multiplied by 0.5 bytes per parameter; it excludes quantisation metadata, KV cache, runtime, and system usage. It isn’t a guarantee that a particular model will load.

  • Start with a short context and one request. Measure time to first token and steady-state generation speed before increasing context or concurrency.
  • Record the model version, quantisation format, tool versions, and sampling parameters so results from different setups aren’t mixed.
  • If your workload depends on the CUDA ecosystem or multi-GPU training, this Mac isn’t a like-for-like replacement.
From local to cloud

Three migration steps, each easy to verify

Don’t copy your entire user directory. Move the project first, restore the toolchain next, then switch over your jobs. The times below are estimates for planning manual work, not provisioning times. Downloads, transfers, and builds take additional time.

01

Data: make the repository reproducible

Allow 10–30 minutes, not including transfer time

For the first migration, clone the repository and sync any uncommitted assets separately. Run the commands below locally. cloud-mac is an SSH alias you’ve already configured, and the repository URL comes from your project’s own environment variable.

ssh cloud-mac 'mkdir -p ~/work'
rsync -av --exclude '.git' \
  ./App/ cloud-mac:~/work/App/
ssh cloud-mac
git clone "$REPOSITORY_URL" ~/work/repo

Check: the commit hash matches and all required assets are present. Caches and rebuildable output directories don’t need to be migrated.

02

Toolchain: pin versions and permissions

Allow 20–60 minutes, not including downloads

Check the Xcode path and SDKs on the remote Mac. If you have a Brewfile, restore tools with Homebrew. Transfer certificates and provisioning profiles through a team-approved secure channel; don’t put them in the repository or job logs.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
brew bundle --file Brewfile
security list-keychains -d user

Check: dependency versions match and the target SDK is available. Complete a signed archive under the user account that will run the job.

03

CI: test first, then switch labels

Allow 15–45 minutes, not including build time

Connect the runner using registration details generated by your organisation. The commands below are for GitLab; for GitHub Actions, use your organisation’s setup script and verify the service on the node. Enter tokens only in a trusted session.

gitlab-runner register
gitlab-runner install
gitlab-runner start
gitlab-runner verify

Check: a test branch picks up the new label and its artifacts are downloadable. Once confirmed, switch the production pipeline and keep the old runner available as a fallback.

A successful migration means more than being able to connect over SSH: the same commit should install dependencies, build, test, and deliver artifacts. If any step fails, keep the logs and fix it before moving on.

Working across time zones

Share the schedule, not a password

Your team can take turns using the same node, but CPU, GPU, memory, and disk remain shared resources. Separate macOS users aren’t a virtual machine isolation boundary; release credentials and sensitive projects need tighter access controls.

  1. 01

    Use individual accounts

    Give each team member a separate macOS user and SSH public key rather than sharing private keys. Use a dedicated account for CI. When someone leaves the team, remove their key and review related tokens.

  2. 02

    Hand off work on schedule

    Use one time zone for scheduling. Handover notes should include the commit hash, working directory, running processes, and next task. Put long-running jobs on a runner or in a managed session instead of relying on an open desktop connection.

  3. 03

    Manage signing separately

    Verify keychain access for the user running each job, and don’t put unlock passwords in shell history. Before handing over, check for any pending interactive signing prompts. Don’t end another person’s session during a release job.

  4. 04

    Keep a second copy of your data

    Push code back to the repository, send artifacts to team storage, and store credentials separately in a secure location. Back up your data before the rental ends; don’t use the node as your only copy. Check the console for renewal and expiry details.

NEXT / RUN YOUR PROJECT

Choose a workload.
Start with one node.

Start with Shell M4 for a single project build, choose Shell M4 Plus for a team pipeline, or use Shell M4 Pro for memory-intensive inference experiments. Confirm the rental term, location, and add-ons when you place your order.

Payments are accepted only via USDT-TRC20 and Visa / Mastercard / Amex (through Stripe). All prices are in USD. Available payment options are determined by the response from the payment gateway.

Solo development · Shell M4 Team CI · Shell M4 Plus AI experiments · Shell M4 Pro