Catch Memory Bugs with AddressSanitizer Remotely

Published November 11, 2026 • Figment editorial team

For an ASan-instrumented iOS test run on a rented Mac, start with a Figment M-series Mac from $95/month when you need Xcode 27 or Apple-silicon-only simulator runtimes; use the $29 virtual Intel macOS VM (2 vCPU, 8 GiB RAM, 80 GiB disk) when your project still builds on Xcode 26 or earlier, which Apple's porting guide confirms is the last Intel-compatible line (developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon). The $29 VM is a real macOS environment, not an SSH tunnel to another machine, and runs Intel Xcode toolchains with the simulator; it has no GPU acceleration and no audio. The i3 Mac at $49 and physical M-series machines are request-based until supply is confirmed. Begin at /mac-hosting/start.

AddressSanitizer (ASan) is compile-time instrumentation from Clang, not a separate download. Enable it, run your test suite, and the runtime inserts checks around every memory operation. On the first illegal access — a heap overflow, a use-after-free, a stack smash — ASan prints a report and terminates the process at the violation, before the corruption propagates. The upstream reference lists the full detection set and suppression semantics (clang.llvm.org/docs/AddressSanitizer.html); Apple's Xcode docs cover enabling it inside a scheme (developer.apple.com/documentation/xcode/using-the-address-sanitizer-to-find-memory-corruptions).

What AddressSanitizer Detects

Violation	What it finds
Heap buffer overflow	Read or write past the end of a heap allocation
Use-after-free	Access to memory already deallocated
Stack buffer overflow	Write past the end of a local array
Global buffer overflow	Write past a global's allocation
Use-after-return	Access to a local after its function returned
Use-after-scope	Access to a local outside its lexical scope

ASan does not catch every leak (use the Memory Graph Debugger or LeakSanitizer) and does not catch data races (use ThreadSanitizer). For the use-after-free or buffer overflow that only triggers in a few test paths, it is the right first tool.

Picking the Right Figment Mac for the Run

ASan instruments every load and store, so CPU use and RSS rise under test. Expected overhead is workload-dependent; the Clang manual states the slowdown is roughly 2x on typical C/C++ code but can vary. Time your own suite rather than quote a generic figure.

If your project still targets an Xcode 26 or earlier toolchain, the $29 Intel macOS VM will build and run Simulator tests with ASan; keep expectations modest for simulator startup on a GPU-less host. For Xcode 27, Apple-silicon-only simulator runtimes, or concurrent CI, choose an M-series Mac from $95/month — the specific chip, RAM and disk are set in the quote, not implied by the entry price. The Managed Build Mac at $249/month adds CI setup, backups, monitoring, and 30 minutes of monthly support on one M-series Mac if you want the ASan job wired into a scheduled pipeline rather than a manual run.

Worked monthly cost sketch (two providers, one buyer)

A solo iOS developer who needs ASan runs in Simulator, a daily full-suite run, and the ability to log in from Windows. Using published monthly rates on 2026-11-10:

Figment virtual Intel macOS $29/month, Xcode 26 path, no dedicated M-series hardware. Twelve monthly payments total $348 (Figment plans).
Figment M-series from $95/month, exact chip quoted. Twelve months at the monthly rate: $1,140.
CloudMac M4/16 GB/256 GB $99.99/month, or $999/year on the annual plan (cloudmac.org/pricing). The annual plan is $141 cheaper than 12 × $95 — but $95 is an unspecified M-series entry, not a verified M4/16 GB match. Confirm the Figment configuration in a quote before using that number.

The point is not that one price beats the other everywhere. If you need ASan on Intel Xcode 26 occasionally, $29 is the cheapest entry; if you need a dedicated M4 for a year at a published fixed rate, CloudMac's annual offer is lower than Figment's entry monthly stacked twelve times and Figment's equivalent spec is quote-only.

Enabling ASan

Pick one of three methods. Nothing here invents a build flag beyond the documented Xcode options.

1. Scheme toggle, persistent: Edit Scheme → Test → Diagnostics → check "Address Sanitizer". The scheme file carries the setting; every subsequent xcodebuild test -scheme <that scheme> uses it. This is Apple's documented path.

2. Build-setting override, one run:

xcodebuild test \
  -workspace "$WORKSPACE" \
  -scheme    "$SCHEME" \
  -destination "platform=iOS Simulator,name=iPhone 16 Pro" \
  ENABLE_ADDRESS_SANITIZER=YES \
  2>&1 | tee asan-raw.log

ENABLE_ADDRESS_SANITIZER=YES is the build-setting form recognised by current Xcode. Pass your own workspace and scheme values — do not run this against a scheme that does not exist in your project.

3. xcconfig for CI: add ENABLE_ADDRESS_SANITIZER = YES to a dedicated Test xcconfig and reference it from the test configuration. This keeps the production Release xcconfig untouched.

Running the Suite and Reading the Report

The example below is an unexecuted template, not a benchmark. Substitute real values and check xcodebuild -help on your installed Xcode for the exact flag set before using it in CI.

#!/usr/bin/env bash
# asan-test.sh SCHEME WORKSPACE "iPhone 16 Pro"
set -euo pipefail

SCHEME="${1:?scheme required}"
WORKSPACE="${2:?workspace required}"
DEVICE="${3:-iPhone 16 Pro}"
LOG="asan-$(date +%Y%m%d%H%M).log"

# ASan violations make tests fail; keep the exit non-zero but inspect the log.
set +e
xcodebuild test \
  -workspace "$WORKSPACE" \
  -scheme    "$SCHEME" \
  -destination "platform=iOS Simulator,name=$DEVICE" \
  ENABLE_ADDRESS_SANITIZER=YES \
  2>&1 | tee "$LOG"
BUILD_STATUS=${PIPESTATUS[0]}
set -e

echo "==> xcodebuild exit: $BUILD_STATUS"
echo "==> AddressSanitizer findings:"
grep -E "ERROR: AddressSanitizer|READ of size|WRITE of size|heap-use-after-free|heap-buffer-overflow|stack-buffer-overflow|SUMMARY: AddressSanitizer" "$LOG" \
  || echo "No ASan findings in log."

exit "$BUILD_STATUS"

The script preserves the real xcodebuild exit code — a failed build stays failed, so CI never records a crash as a passing run. A use-after-free report lays out four things worth reading in order: the violation type and address, the access stack (where you touched the memory), the free stack (where it was released), and the allocation stack (where it came from). Start at the top frame of the access stack — that is your line.

False Positives and Suppressions

Some ARC bridging and Objective-C runtime frames trigger ASan complaints unrelated to your code. Clang's upstream docs describe the suppression file format and the ASAN_OPTIONS=suppressions=… entry point. Keep suppressions tight: interceptor_via_fun:objc_msgSend is a library interceptor, while a suppression in your own code hides the bug you came for. Store the suppression file in the repo so the rented Mac and your laptop see identical behaviour.

Pair ASan with the Memory Graph Debugger once corruption is out of the way, add realistic network conditions via the Network Link Conditioner guide, and wire the run into CI with the GitHub Actions self-hosted runner guide.

Ready to provision: pricing and plan details at /mac-hosting; start the configuration at /mac-hosting/start.