Audit Xcode Build Settings on a Rented Mac

When a project that built on MacinCloud fails on a new remote Mac, the cause is almost always a build setting mismatch: wrong ARCHS, a hard-coded SDKROOT, a stale VALID_ARCHS, or a deployment target that diverges across targets. The worksheet below finds those mismatches target by target, and the plan comparison tells you which hosted Mac to run it on.

If you want the short answer: use Figment's $29 virtual Intel macOS for CLI builds, signing, notarization, and cross-compiling universal/arm64 archives, and move to M-series from $95/month for the iOS simulator, SwiftUI previews, Metal, or Xcode 27. Start a configuration.

MacinCloud vs Figment: What $29 Actually Buys

MacinCloud's managed plans publish, as of 2026-11-10 on macincloud.com/pages/managed.html: M1 from $25, M2 from $26, and M4 from $29 per month, with 8/16/32 GB RAM options and a 120 GB user quota upgradable to 4 TB. Managed plans are a user account on the host: the vendor runs admin tasks on request, and root/admin is reserved for their dedicated plans. macOS versions listed range from Tahoe (26.x) back to earlier releases.

Figment's $29 tier is a different product. It is a virtual Intel macOS environment (2 vCPU, 8 GiB RAM, 80 GiB disk) reached through a browser console. It runs supported Intel macOS toolchains, including Xcode 26 or earlier per Apple's guidance on porting apps to Apple silicon, so it can cross-compile arm64 iOS archives, build universal macOS binaries, sign, and notarize. It cannot execute ARM-only binaries, run the ARM iOS simulator, drive Metal GPU work, or run Xcode 27 — those need Apple silicon.

At $29, MacinCloud's managed M4 shares a price with Figment's Intel VM, not a hardware class. That's an entry-price comparison, not equal silicon. If your work specifically needs Apple silicon, compare MacinCloud's managed M4 at $29 (shared, pre-installed Xcode, no admin) against Figment M-series from $95 — exact chip, RAM, storage, and term are confirmed in the quote. The Managed Build Mac at $249 is the right choice when you want the CI pipeline migrated, not just a login.

What Changes Between the Two Hosts

Three things usually move when you re-home an Xcode project:

• Xcode version. The matrix at developer.apple.com/support/xcode binds each Xcode release to a macOS range. Intel hosts top out at Xcode 26; Xcode 27 is Apple-silicon-only.
• Keychain contents. Signing identities are only valid with their private keys, which means a password-protected .p12, not a bare .cer.
• Build settings. Stale VALID_ARCHS, machine-specific absolute paths in OTHER_SWIFT_FLAGS, or an EXCLUDED_ARCHS = arm64 left over from Intel simulator testing all travel with the project and bite on a new host.

The audit targets the third category.

The Per-Target Build Settings Worksheet

Open the project on the remote Mac and fill this in for every app and framework target. Values come from Target → Build Settings → All; the Resolved column is what Xcode reports in the Resolved tab, which is what actually reaches the compiler.

Target: ___________________________   Config: Debug | Release

SETTING                         | Project  | Target   | xcconfig | Resolved
--------------------------------|----------|----------|----------|---------
ARCHS                           |          |          |          |
EXCLUDED_ARCHS                  |          |          |          |
VALID_ARCHS  (deprecated)       |          |          |          |
SDKROOT                         |          |          |          |
IPHONEOS_DEPLOYMENT_TARGET      |          |          |          |
SWIFT_VERSION                   |          |          |          |
CODE_SIGN_IDENTITY              |          |          |          |
PROVISIONING_PROFILE_SPECIFIER  |          |          |          |
OTHER_SWIFT_FLAGS               |          |          |          |
GCC_PREPROCESSOR_DEFINITIONS    |          |          |          |

Red flags to chase first:

• VALID_ARCHS set anywhere. It is deprecated; delete it from targets and xcconfigs.
• EXCLUDED_ARCHS = arm64 on a target, which silently blocks the ARM simulator on M-series.
• ARCHS hard-coded to "arm64 x86_64" instead of $(ARCHS_STANDARD).
• SDKROOT set to iphonesimulator on the app target — Distribution archives will fail signing.
• IPHONEOS_DEPLOYMENT_TARGET that differs between the app and an embedded framework (linker warning about embedded binary OS range).
• SWIFT_VERSION mismatched across targets.
• Absolute paths like /Users/jane/... in OTHER_SWIFT_FLAGS, OTHER_CFLAGS, or xcconfig #include lines.
• DEBUG=1 in the Release row of GCC_PREPROCESSOR_DEFINITIONS.

Reading Resolved Values From the Command Line

Both hosts expose the same xcodebuild output. Run this on each machine and diff the results:

xcodebuild -project MyApp.xcodeproj \
  -scheme "$SCHEME_FROM_YOUR_PROJECT" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -showBuildSettings \
  | grep -E '^\s+(ARCHS|EXCLUDED_ARCHS|VALID_ARCHS|SDKROOT|IPHONEOS_DEPLOYMENT_TARGET|SWIFT_VERSION|CODE_SIGN_IDENTITY|PROVISIONING_PROFILE_SPECIFIER) ='

Use your project's real scheme name. -showBuildSettings resolves the full stack (project, target, xcconfig, scheme env), so any line that differs between local and remote is a setting you need to reconcile. Common fixes:

• Delete VALID_ARCHS project-wide.
• Remove EXCLUDED_ARCHS = arm64 from any target that needs the ARM simulator.
• Set CODE_SIGN_IDENTITY = - on unit test targets that don't ship.
• Rewrite xcconfig paths to be relative to $(SRCROOT).

Migrating Signing Material Safely

Signing identities live in the keychain and travel as an encrypted .p12:

1. In Keychain Access on the source Mac, select the certificate and its private key, right-click → Export, choose .p12, set a strong password.
2. Transfer the .p12 and the password through separate channels (file via your artifact store, password via your secret manager).
3. On the destination Mac, create a dedicated keychain for CI rather than importing into login.keychain-db, and restore the search list when the job ends:

KC="build.$(uuidgen).keychain-db"
security create-keychain -p "$KC_PASSWORD" "$KC"
ORIG_LIST=$(security list-keychains -d user | tr -d '"')
security list-keychains -d user -s "$KC" $ORIG_LIST
trap 'security delete-keychain "$KC"; security list-keychains -d user -s '"$ORIG_LIST"'' EXIT
security unlock-keychain -p "$KC_PASSWORD" "$KC"
security import signing.p12 -k "$KC" -P "$P12_PASSWORD" -T /usr/bin/codesign

Provisioning profiles are plain files; copy them to ~/Library/MobileDevice/Provisioning Profiles/. Do not export the host's environment to a plaintext file during the move — it almost certainly contains API tokens. Keep secret values in your CI service's secret manager (GitHub Actions secrets, Buildkite agent hooks, etc.) and list only the required secret names in migration notes.

Which Figment Plan Fits the Work

• Virtual Intel macOS, $29/month. CLI Xcode 26-or-earlier builds, universal/arm64 cross-compile, signing, notarization, and acting as a GitHub Actions or Buildkite self-hosted runner for Intel-compatible jobs.
• M-series from $95/month. Full Xcode GUI, ARM iOS simulator, SwiftUI previews, Metal, XCUITest, and Xcode 27. Exact chip and RAM are confirmed in the quote.
• Managed Build Mac, $249/month. One M-series Mac plus CI setup, backups, monitoring, and 30 minutes of monthly support — the right tier when you want the pipeline moved for you.

Ready to pick a tier and run the audit on your own project? Start a configuration at /mac-hosting/start.

Related reading:

• Manage Keychain Certificates on a Remote Mac
• Debug Entitlements in Xcode on a Remote Mac
• Run GitHub Actions on a Self-Hosted Mac Runner