The same problem happens every year with the first developer release of the new macOS. In addition to those who want to install it on one of their Macs designated for betas, many of us want to install it into a virtual machine. The latter requires a Device Support enabler, or trying to build its VM is doomed to fail, and each year that crucial package is omitted at first. But it comes with another beta released at the same time, for the new version of Xcode.

This year, Apple added another hurdle for those wanting to create Golden Gate VMs, perhaps best explained by its brief entry in the beta release notes:
“If you installed Xcode 27 beta on macOS Tahoe 26.5.1 and earlier, macOS virtual machine installation will fail due to a known bug. To restore virtual machine installation functionality, follow the How to reinstall macOS guide.”

So I had done just that: as there was no separate enabler provided, I had installed Xcode 27 beta on macOS Tahoe 26.5.1, the latest version available at the time, and my Mac was now unable to create any new macOS VMs, of Golden Gate or any other version of macOS. At least I had my MacBook Pro with Golden Gate beta installed, where I could still build new VMs. I declined Apple’s kind invitation to reinstall macOS Tahoe on my production Mac mini, hoping the upgrade to Golden Gate would spare me the pain, when it’s released in a couple of months.

The good news is that updating to Tahoe 26.6 did the trick, and I can now build VMs, including Golden Gate betas, once again.

If you’ve been struggling to get this to work, the recipe is simple:

• The host requires macOS 26.5.2 or later, preferably 26.6.
• Either install and configure Xcode 27 beta 4, or install the current DeviceSupport_macOS_27_beta.dmg available from Apple for beta-testers.
• Download your chosen Golden Gate beta IPSW through Mr Macintosh’s list or Apple, and build it into a VM using your favourite virtualiser, including Viable.

I remain mystified as to what that first beta of Xcode 27 could have installed that required a full macOS reinstall to fix. The current enabler consists of a MobileDeviceOnDemandPackage Installer package, which installs various components into /Library/Apple/System/Library/, from where they’re firmlinked into /System/Library/. Among those are some private frameworks and a single kernel extension AppleMobileDevice.kext. If the latter had been flawed, then surely it could have been replaced by another Installer package, rather than requiring replacement of the whole SSV as well. I hope that Apple doesn’t have any surprises like that for next year.