Since late 2018, I’ve been developing on Apple Silicon. You can read about it in an earlier article. But that’s using an iPad, and the only native builds I can do rely on an app that’s no longer available. What most people think of developing on Apple Silicon, they’re thinking of M1 Macs. And I’ve been doing that since May 2021.
When Apple ditched 32-bit support in macOS, I had a feeling ARM Macs wouldn’t be far behind, on the basis that unlike Intel, Apple’s chips didn’t have a 32-bit mode. This is the fourth time Apple has changed architecture in its computer lines. When it went from 6502 to 65C816 with the Apple IIGS, it developed a partial system-on-a-chip (SoC) implementation of the Apple II. It later created a card based on this for the Mac, which had an MC68000 CPU.
When Macs moved to PowerPC CPUs, they were fast enough to emulate the MC68000 instruction set. The move from PowerPC to Intel depended on just-in-time (JIT) instruction translation software licensed from Transitive (a company spun out of a research project at Manchester University in England). Transitive used to support a plethora of architectures, until IBM bought the company to add support for running Linux Intel binaries on its Linux PowerPC machines. As an aside, I briefly used Transitive to run the SPARC version of FrameMaker on the x64 version of Solaris.
Apple branded the technology Rosetta, and it kept it around for quite a while, but eventually it dropped support for running PowerPC binaries on macOS. Now we have Rosetta 2, and I wonder if it has licensed the technology from IBM. This enables macOS Intel binaries to run on Apple’s ARM CPUs. The catch is that I’m fairly sure that one day, just like it did with Rosetta, Apple will release a version of macOS that drops Rosetta 2 support. More on that later.
Development isn’t all coding. Sometimes you need to run an application, for example to create an asset. As it’s still early days for macOS on ARM CPUs, native apps aren’t always available, but for now Rosetta 2 lets you run most of your old 64-bit Intel macOS apps. But what if you needed to run Linux or Windows apps? You can virtualize ARM Linux and ARM Windows on an ARM Mac with commercial offerings Parallels or VMware Fusion (at the time of writing, there is no native version of VirtualBox).
If there’s an ARM version of the app you want, then great. If not? Well, Windows 11 on ARM has X64 emulation. But you can’t buy Windows 11 ARM from Microsoft. It’s only available to OEMs. So you’ll have to use the preview edition. And that can’t be upgraded, so if you need an upgrade, you’ll have to reinstall. Microsoft has no intentions to license Windows on ARM. It’s not clear that it will always be possible to install the preview version. Maybe you’d prefer to stick with Windows 10. And what if you need to run an Intel Linux binary? The answer is QEMU, a “generic and open source machine emulator and virtualizer.”
QEMU is notoriously difficult to configure, but on Macs there is a packaged version called UTM (Universal Turing Machine?). It’s available as a free download from the website or as a paid download with automatic updates from the app store. It comes with a gallery of pre-configured machines, which at time of writing include ArchLinux/ARM, Debian 10/ARM, macOS 9/PPC, ReactOS/x64, Solaris 9/SPARC, Ubuntu 14.04/x64, Ubuntu 20.04/ARM, Windows XP/x64, Windows 7/x64, Windows 10/ARM and Windows 11/ARM.
You’ll note that the x64 version of Ubuntu is much older than the ARM version. And the reason for that is that x64 emulation is slow. I used to run SoftWindows 95, emulating an x86 CPU on a PowerPC Mac, and this can be slower. For that reason, if you’re virtualizing a non-ARM OS, then you’ll want the most lightweight version available.
I have a few tools that I used to run under WINE on macOS (until Apple dropped 32-bit support). Codweavers is working tirelessly to get 32-bit and 64-bit Windows apps running on macOS with Crossover, its commercial version of WINE, but it’s early days at the moment. That led me to trying out ReactOS with UTM. It’s a project to create a completely open source Windows-binary compatible OS. But in its current state I’d consider it pre-alpha. So I had to find a different solution.
After trying a few different options, I settled on Lubuntu 18.04 (because 19.04 drops 32-bit support). This is essentially a lightweight version of Ubuntu. I went with the 32-bit version because the Windows apps I need to run are all 32-bit, and it simplifies installing WINE. It
As with any VM, the critical step to make it usable is installing the guest tools, in this case SPICE. With that installed and configured, you can set up shared folders and you no longer need to capture the mouse. I got away with just installing
apt. After enabling directory sharing in the settings for the VM, you can click the folder icon in the running VM to set the shared directory.
The other VM that I use quite often is the latest Ubuntu/ARM release. I typically use this for running command line tools that haven’t made it into macOS or homebrew yet. But I have the full desktop environment installed, and it doesn’t feel laggy. The one missing app is Chrome, but Chromium is available and works just as well for syncing with your Google account.
When I originally wrote this, network support was somewhat flaky in QEMU. This now appears to have been fixed. I’m still using Parallels Desktop 17, but the annual refresh charge means that I’m running it on the previous version of macOS. VMware has released Fusion 13, with equivalent functionality. It also offers a Fusion 13 player. If I could migrate my Parallels VM to Fusion, that might be the best solution to not paying an annual fee to use Windows 11. But Fusion 13 can’t import ARM VMs. I also found out that you can activate Windows 11 ARM in a VM if you have a developer license key.
In macOS Ventura, it’s now possible to use Rosetta 2 with UTM. But it’s complicated, so I wrote a separate article on it.