VirtualBuddy: a macOS VM GUI for Apple Silicon developers

The problem VirtualBuddy solves for Apple Silicon developers

Testing a Mac app against several macOS versions used to mean keeping old hardware around or partitioning a disk. On Apple Silicon that changed: the platform can run macOS in a virtual machine through Apple's own virtualization stack, but the tooling around it was thin. VirtualBuddy fills that gap with a native GUI. The README states the goal plainly: offering features that are useful to developers who need to test their apps on multiple versions of macOS, especially betas.

The audience is narrow on purpose. System requirements are an Apple Silicon Mac and macOS 13 or later. There is no Intel build and no Windows guest support. If your test matrix includes Windows, this is not the project for you. If your test matrix is macOS 12, 13, 14, 15 and whatever beta is current, that is exactly the shape VirtualBuddy was built for.

How the installation wizard and restore images fit together

The mechanism is a wizard that drives Apple's restore image pipeline. According to the README, you select from a list of macOS versions provided by VirtualBuddy, and the app downloads and installs the selected version automatically. Alternatively you supply your own IPSW link, or pick an IPSW you already downloaded. The same wizard handles Linux: install from a local .iso, from a curated list of distros, or from a URL.

One constraint is worth stating before you start. Running a beta guest that is newer than your host requires the latest device support package from Apple. The README says these are sometimes published directly by Apple but are always included with the latest Xcode beta, and they can be obtained from the Apple Developer portal. For macOS Golden Gate beta on a macOS 26 host, the README requires VirtualBuddy 2.2 beta 2 or later plus the latest device support files, unless Xcode 27 beta is already installed. That is a real coupling: the app is not self-sufficient for beta guests.

The repository layout backs the feature list up. VirtualCore, VirtualInstallation, VirtualInstallationService, VirtualUI and VirtualWormhole are separate modules, with VirtualWormholeTests alongside them. The guest side lives in VirtualBuddyGuest and VirtualBuddyGuestHelper. That separation is why the guest app can be versioned independently of the host app.

Installing VirtualBuddy and booting a first VM

The README points to GitHub releases for the latest version. The project is free and open source; the README also mentions purchasing it on Gumroad or sponsoring the author, which are optional support paths rather than licence terms. There is no Homebrew formula documented in the README, so treat any brew command you see elsewhere as unverified.

Building from source requires Xcode 16 on main. The README gives this sequence: open VirtualBuddy/Config/Signing.xcconfig, set VB_BUNDLE_ID_PREFIX to something unique, select the VirtualBuddy target, pick your development team under Signing & Capabilities, repeat for the VirtualBuddyGuest target, then build the VirtualBuddy scheme, the one that does not have (Managed) in its name.

Once a VM is running, sharing folders between host and guest has two paths. Plain macOS file sharing works in both directions. When both sides run macOS 13 or later, you can configure shared folders in the VM settings inside VirtualBuddy before booting, then mount them in the guest Terminal:

mkdir -p ~/Desktop/VirtualBuddyShared && mount -t virtiofs VirtualBuddyShared ~/Desktop/VirtualBuddyShared

You should see the shared folder appear on the guest desktop. For the guest app, VirtualBuddy mounts a disk image automatically when you boot a supported macOS VM with the guest app enabled. Select the Guest disk in Finder's sidebar and double-click VirtualBuddyGuest to install it.

Where the guest app stops, and other limits

The VirtualBuddyGuest app is the clearest limitation in the README. The latest version requires macOS 14 or later and supports clipboard sharing plus automatic mounting of shared folders. On macOS 13, the legacy guest app only mounts shared folders automatically and clipboard sharing is unavailable. On macOS 12 or earlier, VirtualBuddyGuest is not supported at all. So if your reason for running a macOS 12 VM is clipboard-based testing, the guest app cannot help you.

Linux support carries a hedge of its own. The feature checklist says the ability to boot some ARM-based Linux distros, tested with Ubuntu Server and Ubuntu Desktop. Some is doing real work in that sentence. Do not read the distro list in the wizard as a compatibility guarantee.

The guest app is also not the same as a full integration stack. There is no documented GPU passthrough, no snapshot tree beyond saving and restoring macOS VM state, and no remote display protocol mentioned. State save and restore is listed as a feature, not a snapshot manager.

Finally, the release channel is beta-shaped. The recent releases are 2.2 beta builds, and the README itself directs Golden Gate users to a specific beta. If you need a frozen, long-supported binary, the project does not currently present one in the README or the release list.

VirtualBuddy compared with UTM

UTM is the obvious alternative and appears repeatedly in the related searches. The difference is in the approach. UTM is built on QEMU and targets a wider matrix: it can emulate architectures and run guests that Apple's virtualization framework cannot, including on Intel Macs. VirtualBuddy uses Apple's native virtualization on Apple Silicon and does not emulate other architectures. That trade is the whole story. VirtualBuddy gives up breadth to stay close to the platform, which is why its install wizard can lean on Apple's restore images and why beta guests need Apple's device support packages. UTM's breadth is also why it carries QEMU's configuration surface.

If your requirement is a macOS guest on an M-series Mac with the least possible setup friction, VirtualBuddy is the more direct route. If your requirement is a Windows or x86 Linux guest, or an Intel host, UTM is the tool that covers it and VirtualBuddy simply does not.

Maintenance, licence and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-17. The release cadence in the release list is beta-heavy: 2.2-b5 on 2026-09-14, 2.2-b4 on 2026-08-27, 2.2-b3 on 2026-08-04. That suggests steady work, but it also means the newest published artifacts are betas, and the README ties at least one guest configuration to a specific beta build.

The licence is BSD-2-Clause. That is a permissive licence, and the practical implication is that you can build and redistribute the code under its terms. The README's Gumroad and GitHub Sponsors links are support options, not licence conditions. Nothing here is legal advice; if you plan to ship a modified build, read the LICENSE file in the repository root.

Upgrade cost is dominated by Apple, not by VirtualBuddy. Each macOS beta cycle can require a fresh device support package, and the README says these ship with the latest Xcode beta. Teams that pin Xcode versions will feel that. The build itself needs Xcode 16 on main, so an Xcode upgrade is part of the maintenance bill.

Copying a VM with APFS instead of snapshots

The README offers a workflow tip that is easy to miss: because APFS clones are copy-on-write, duplicating a virtual machine inside your library folder with Command + D in Finder takes almost no additional disk space. The suggested pattern is to keep a clean copy of a VM, run experiments in a duplicate, and re-duplicate the clean version when the experimental one breaks.

This is a practical substitute for a snapshot UI, and it has a boundary. The clone shares blocks with the original until either side changes, so a long-lived duplicate that diverges heavily stops being cheap. It also lives outside the app: Finder does the copying, not VirtualBuddy. If you want snapshot management inside the GUI, the README does not describe one.

Editorial conclusion

Adopt VirtualBuddy if you are on an Apple Silicon Mac running macOS 13 or later and your job is checking an app against several macOS releases, including betas. Skip it if you need Windows guests, Intel hosts, or a supported configuration for macOS 12 guests with the guest app. Before committing, verify three things: that your host meets the macOS 13 floor, that the guest macOS version you need is covered by a device support package, and that your workflow can live with the beta channel, since the newest releases listed are 2.2-b5, 2.2-b4 and 2.2-b3.

Frequently asked questions

Official sources

1. insidegui/VirtualBuddy on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases