
Run lipo -archs on every plugin in the session before you book a Mac. Ten minutes of binary inspection prevents renting a machine that cannot load the one reverb the client signed off on, and it tells you whether you need a physical Intel i3 ($49), an M-series Mac (from $95), or just the virtual Intel macOS plan ($29) for an offline binary audit.
Every macOS audio plugin binary falls into one of four categories, and each one changes the rental decision.
32-bit (i386): Apple dropped 32-bit application support in macOS Catalina, so a plugin that ships only i386 slices will not load on any currently supported macOS release on any rental. You need the developer's 64-bit build or a replacement plugin; no Mac rental fixes this.
Intel 64-bit (x86_64 only): Runs natively on Intel Macs. On Apple silicon it runs through Rosetta 2 translation, with the whole-process rule described below.
Universal Binary (x86_64 + arm64): Contains both slices. macOS picks the native slice for the host process at launch. The safest architecture for any Figment plan.
ARM-native (arm64 only): Will not load on Intel hardware at all. Common for modern plugins rebuilt exclusively for Apple silicon.
lipo and filePlugin executables live inside the bundle. For Audio Units: PluginName.component/Contents/MacOS/PluginName. For VST3: PluginName.vst3/Contents/MacOS/PluginName. For AAX: PluginName.aaxplugin/Contents/MacOS/PluginName.
# Architecture(s) of a VST3 plugin (quote the path because it contains spaces)
lipo -archs "/Library/Audio/Plug-Ins/VST3/FabFilter Pro-Q 3.vst3/Contents/MacOS/FabFilter Pro-Q 3"
# Example outputs:
# x86_64 -> Intel 64-bit only
# arm64 -> ARM-native only
# x86_64 arm64 -> Universal Binary
# file cross-checks bundles that lipo rejects (older fat formats, wrappers)
file "/Library/Audio/Plug-Ins/Components/SomeOldReverb.component/Contents/MacOS/SomeOldReverb"
# "Mach-O 64-bit bundle x86_64" confirms Intel 64-bit
# "Mach-O universal binary with 2 architectures: [x86_64] [arm64]" confirms Universal
To sweep a whole folder without tripping over spaces in plugin names:
find "/Library/Audio/Plug-Ins/VST3" -type f -perm -u+x -print0 \
| while IFS= read -r -d '' bin; do
printf '%s\t' "$bin"
lipo -archs "$bin" 2>/dev/null || echo "lipo-rejected"
done
Run the checks on the production machine where the session already lives, not on the rental. Export the plugin list from the DAW's own plugin manager first, so you know which binaries the session actually loads rather than every plugin installed on the machine. Keep a save-copy of the project before any migration — architecture changes also expose plugin-version and license-seat differences.
On Apple silicon, macOS launches Rosetta 2 automatically when it encounters an Intel-only binary. Apple's About the Rosetta translation environment documents three limits that matter for an audio session:
arm64 and x86_64 code in the same process; Rosetta translation applies to the whole process, including every module the process loads dynamically.Apple's Porting your macOS apps to Apple silicon adds the plug-in rule: code loaded directly into an app's process space must share the host's architecture, while plug-ins run out-of-process through an XPC service may run under a different architecture than the host. That page also notes that a single XPC service can manage either native or translated plug-ins, but not both at the same time. In practice: on an Apple silicon DAW, in-process VST2, VST3, and AAX plug-ins force the host itself to launch under Rosetta if any Intel-only plug-in in the session must load. Intel Audio Units can run alongside an arm64 DAW only when the host actually provides a separate XPC component host for x86_64 AUs — that capability is DAW- and version-specific, so check your DAW's current release notes rather than assuming it.
The Rosetta page also states that Rosetta remains available through macOS 27 as a general-purpose tool for Intel apps, with a narrower subset retained afterward for unmaintained gaming titles. Audio plugins are not in that retained subset. If a studio's billable work still depends on Intel-only VST or AAX plugins, start the replacement audit now rather than at the next macOS jump.
$29 virtual Intel macOS (2 vCPU, 8 GiB RAM, 80 GiB disk, Intel on Linux/KVM) is a real macOS runtime: it loads x86_64 binaries, runs compatible Intel Xcode toolchains (use Xcode 26 or earlier when running Xcode on an Intel-based processor, per Apple's porting guide linked above), and can cross-compile and sign supported targets. Access is through the Figment browser console. The VM has no GPU acceleration and no Core Audio device, so a DAW on the VM cannot play back real-time audio. Good uses: plugin binary auditing at scale, scripted offline rendering with command-line tools you install, headless build jobs for plugin code, and signing workflows for Intel targets. It is not the right machine for an interactive mixing session, and color/audio preview over a remote desktop is not a calibrated or live-hardware guarantee on any plan.
i3 Mac ($49) physical loads every x86_64 plugin natively, with no translation layer and no process-architecture negotiation. Pick it when the session contains Intel-only VST, VST3, or AAX plugins that your host does not sandbox out-of-process. Confirm the exact chip, RAM, disk and installed macOS image in the configuration quote. Physical i3 inventory is request-based.
M-series Mac (from $95) is the right call when the plugin list is Universal, ARM-native, or a mix of Universal plus Intel AUs that your DAW explicitly sandboxes through XPC. Current builds from FabFilter, iZotope, Arturia, and most Waves products ship Universal. M-series also loads ARM-native plugins the i3 cannot, and it is better positioned for the post-Rosetta timeline. The $95 entry is a starting price for an M-series configuration; the specific chip, RAM, and disk are confirmed in the quote. Physical M-series inventory is also request-based.
Send the configuration request with the plugin audit attached so delivery can be scheduled against the session date. See Figment Mac hosting plans for the current list.
Find the row that matches your lipo -archs output, then read across. Treat the matrix as a session-level check: a single Intel-only in-process plugin forces an Intel-only or Rosetta-hosted DAW for that entire session.
| Plugin type | lipo output | $29 virtual Intel macOS | i3 Mac ($49) | M-series (from $95) |
|---|---|---|---|---|
| 32-bit only | i386 or error | Will not load | Will not load | Will not load |
| Intel 64-bit AU | x86_64 | Loads, no live audio I/O | Native | Native if the DAW hosts AUs out-of-process via XPC; otherwise host must launch under Rosetta |
| Intel 64-bit VST / VST3 / AAX | x86_64 | Loads, no live audio I/O | Native | Host must launch under Rosetta |
| Universal Binary | x86_64 arm64 | Loads x86_64 slice, no live audio I/O | Native x86_64 | Native arm64 |
| ARM-native | arm64 | Will not load | Will not load | Native |
"No live audio I/O" on the $29 VM means the plugin binary loads and can respond to offline processing calls from a host you install, but there is no Core Audio device for real-time playback. For Intel VST / AAX on M-series, the whole-process rule applies: the entire DAW runs under Rosetta, which rules out loading any arm64-only plugin in the same session.
If a session mixes ARM-native plugins with in-process Intel-only VST plugins, no single Mac loads both in one process. Split the signal chain across two sessions, convert the Intel plugins to AU versions where the developer ships them and the DAW provides an XPC AU host, or bounce the Intel-only chains to audio before moving the project to Apple silicon.
lipo -archs captured for every plugin in that list; i386-only entries flagged for replacement.x86_64 Audio Units (check the DAW release notes).Ready to send a configuration request with the checklist attached? Start a Figment Mac rental.