Emulation, Virtualization, and Rosetta 2: A Blend of Old, New, and Yet To Come

Over the decades, Apple has managed several successful processor and operating system migrations with a combination of emulation and virtualization. Emulation lets a computer run code intended for a different CPU, like a Mac with an Intel processor running code written for a Motorola chip. Virtualization lets Apple (and other companies) keep older operating systems alive for a while, or even indefinitely, by creating a bubble in which older code can run natively, without realizing it’s not controlling a hardware computer.

Apple’s latest entrant in the emulation field is Rosetta 2, which enables Intel-based apps to run on Apple’s M1 chips. But there’s more to come that could improve the transition from Intel to Apple silicon for Mac users—like a virtualization app that would let us launch 10.15 Catalina or previous Intel-only versions of macOS, or Intel flavors of Windows, Linux, and other operating systems. What stands in the way?

Though they may seem to carry out a very similar function, there’s a wide gulf between emulation and virtualization. Apple’s limited Rosetta 2 emulator provides one of those Indiana Jones rope bridges across the chasm. Will someone build a trestle highway? Let’s explore the concepts first.

Crossing the Chasm: Emulation and Virtualization

Both emulation and virtualization let you run one or more apps or entire operating systems within a distinctly separate operating system from the one that manages the host computer—the actual computing hardware. Such an approach can give you the best of both worlds, where you can use the latest hardware and operating system while still having access to previously purchased apps that run only in unavailable machine configurations. It’s also incredibly useful for app developers and technical support staff, who often need an array of operating system versions for testing and troubleshooting.

Emulation generally works at an instruction level. Emulators usually simulate most or all of the functions of a computer processor, although they may handle only a subset of all possible instructions the real CPU can execute. When an app or operating system loads within an emulator, the emulator transforms its instructions into a version that works natively on the processor on which the emulator is running. (There are even emulators nested inside other emulators, notably in the telephone network and other long-running systems. And there are hardware emulators, including chips that can be programmed to reconfigure themselves to emulate other chips!)

Because emulation works at such a fundamental level, it can be quite slow if its host processor isn’t significantly faster than the one it imitates. Rosetta 2 has the advantage of converting Intel processor code to Apple silicon instructions on the M1 chip, which is both optimized to macOS’s needs and substantially faster than previous Intel CPUs.

Emulation can be used for serious purposes, such as allowing vital business software to keep running even as the hardware it requires becomes obsolete and unavailable. It can preserve an investment in software for individuals or globe-spanning corporations that continues to meet a need, especially when nothing newer is available at all or for a reasonable upgrade fee. It’s also a boon for computer archivists and people who love historic machines and games. The Internet Archive has early Mac emulators that let you, for example, launch the Mac version of the Oregon Trail game, and even emulators that keep Adobe Flash alive for preserved animations and interactive games. All of these emulators run in a Web browser, remarkably.

In contrast, virtualization works at a higher level. A virtualization app creates virtual machines that provide a framework to execute app or operating system code natively with the same processor that runs the host computer’s operating system. These apps or operating systems believe they are running on a bare-metal processor—they’re the proverbial “brain in a jar”—and there’s only a modest bit of overhead that makes them run more slowly in that environment.

Parallels Desktop and VMware Fusion for Intel-based Macs, for instance, are virtualization apps that rely on a hypervisor to run other Intel-based operating systems inside their virtual machines. (Parallels even offers a choice of its own hypervisor or one built by Apple, and recommends Apple’s with Big Sur.) Virtualization allows you to keep old versions of macOS alive, as well as versions of Windows, Linux, and other operating systems that use Intel x86 code, and 32-bit applications that predates the Catalina requirement for 64-bit apps in macOS. You can set up multiple virtual machines with a single app and run them side by side.

(Boot Camp, by the way, is not virtualization. Instead, it’s a way to install and boot natively into Windows on an Intel-based Mac, where Windows is the host computer’s controlling operating system.)

Hypervisors are also used in data centers and by businesses to extract the maximum value from hardware by running multiple virtual machines simultaneously in a single high-performance server. I run a virtual private server, a slice of a machine running under a hypervisor, that is nearly the same as—but far cheaper than—having my own server in a rack somewhere. If the host hardware were to die, my provider could migrate a disk-image backup onto a new host in minutes. And, realistically, many data center hardware components are designed to be hot-swappable, reducing the likelihood of downtime even further.

Apple’s solution for the transition from Intel processors to Apple silicon is to leverage emulation, albeit in a way that doesn’t offer virtualization on top. Rosetta 2 is a 64-bit Intel x86 emulator for Apple’s M-series Macs, but it’s not a full emulation environment and doesn’t support 32-bit apps. Virtualization app makers will eventually offer their apps for Apple silicon to run operating systems designed for ARM chips that are compatible with Apple’s ARM-based M1 (and putative later M-series chips). Parallels already has a Parallels Desktop beta out for M1-based Macs that allows Microsoft’s ARM-native Windows preview to run natively, as it’s compatible with Apple’s ARM implementation. (You can sign up for both the Parallels Desktop beta and the Windows Insider program that lets you download the Windows preview for free.)

To make your head explode slightly, if you run Windows for ARM within Parallels Desktop for M1, Microsoft provides an Intel emulator that can run both 32-bit and 64-bit apps written for Intel versions of Windows! (Microsoft released the 64-bit update in December 2020; the 32-bit version has been around since 2017.)

With those differences between emulation and virtualization in mind, let’s look at Apple’s path to the present and where the future might still lead in its transition to Apple silicon for all Macs.

Apple’s Emulation and Virtualization Journey

I’ve long been impressed by how effectively Apple has provided transitions across generations of its hardware and operating systems. Under Michael Spindler, Steve Jobs, and Tim Cook, Apple has been unsentimental and forward-thinking.

Apple’s timeline of emulation and virtualization looks like this, although there are a few tiny steps and extra nuances that could (and do) fill Wikipedia pages:

• Motorola 68040 to PowerPC: Apple built a “68K” emulator to allow software written for the late-generation 68040 processor to run on PowerPC-based Macs starting in 1994 and lasting through Mac OS 9.2 in 2001.
• Mac OS 9 to Mac OS X: Classic Mac software from Mac OS 9.04 and later ran within a virtual machine provided with Mac OS X. The “Classic environment” was available from the public beta of Mac OS X around 2000 through 10.4.11 Tiger in 2007.
• PowerPC to Intel: The original Rosetta emulator allowed most PowerPC software to function on Intel-based Macs. It was available from 10.4.4 Tiger through 10.6.8 Snow Leopard.
• Intel to M-series: The Rosetta 2 emulator allows most 64-bit Intel software to work on the M-series processors. Its end date hasn’t been announced, although it will likely be available for at least 3–5 years.
• iOS/iPadOS within M-series: Arguably, the ability to run iOS and iPadOS apps within macOS on an M1-based Mac is a kind of virtualization, even though these apps seemingly run like regular macOS apps. But because they don’t use the same operating system, it’s fair to label it that way.

Rosetta 2 launches automatically behind the scenes whenever you run a 64-bit Intel Mac app. (The very first time you run such an app, you may be prompted to download and install Rosetta 2, though some people say they didn’t see that prompt.) The first time an app launches, the emulator performs a one-time translation process and caches native converted code. Subsequent launches happen faster, though the translation caching occurs again whenever you update an Intel app.

Developers can also release universal apps that contain both Intel and M1-native code in one bundle, and you can use Get Info in the Finder to force a universal app to launch with Rosetta 2. That option is useful because some developers have released universal apps that lack feature parity with their Intel versions. For instance, Adobe’s initial Photoshop for M1 release omits a few features found in the Intel implementation. You might also have apps with an extensible architecture, and plug-ins you own for those apps may not yet be M1-native.

Some companies are releasing separate Intel and M1-native versions of their apps; I noticed Zoom and Cisco WebEx automatically downloaded M1 versions of their apps on my M1-based MacBook Air, while Google Chrome lets you pick.

Parallels Desktop, and ostensibly VMware Fusion in the future, will be able to run other ARM-based operating systems natively, just as they can run Intel-based operating systems on Intel-based Macs now. That includes variants of Unix and Linux and Windows. But you won’t be able to virtualize Catalina or earlier versions of macOS because there’s no way yet to both emulate and virtualize Intel operating systems on M1-based Macs. That might change.

Beyond Rosetta 2 to Full Emulation?

By Apple’s design, Rosetta 2 doesn’t handle every feature and operation on an Intel processor: it supports only those tasks that Mac software executes within macOS. Because Apple controls the entire environment in which Mac software is designed and compiled, the company built Rosetta 2 to emulate just what it allows developers to do within that environment, which relies on a limited set of Intel CPU instructions.

In order to emulate versions of macOS prior to Big Sur, any Intel version of Windows, or other operating systems designed to run on Intel x86 chips, some group or company will have to build a processor emulator that’s resilient and complete.

That appears to be the rub. There’s no technical reason a company couldn’t create a full x86 emulator for an ARM chip. Both Apple and Microsoft have created partial ones for their respective operating systems already. Ironically, once one has created a general x86 emulator, it wouldn’t be much harder to allow pre-Catalina versions of macOS so you could run 32-bit apps, letting you carry on using these older apps in a combination of emulation and virtualization on an M-series Mac.

We don’t know Apple’s exact motivation for not creating a full processor emulator. We can surmise that Apple chose to cut off 32-bit compatibility with Catalina, likely because of the performance and testing burden it would add to Rosetta 2 running on M-series Macs, all without providing a significant benefit to most of its customers. Apple has spent years trying to wean developers and Mac users off 32-bit apps. Plus, the company’s transitions usually aim to shift everyone to the latest technologies as quickly as possible.

There could also be legal concerns. Intel made some digs at Microsoft and Qualcomm in 2017 that seemed to imply that any ARM-based version of Windows for Qualcomm chips that emulated some x86 instructions could face legal action. Because Intel has developed instruction sets over many decades and generations of chips, some x86 instructions remain under patent protection, while others are no longer covered. The particulars would have to be litigated in what would undoubtedly be extremely tedious and drawn-out civil suits. (As an example, Oracle recently lost an 11-year-long intellectual property lawsuit against Google over Google’s use of a compatible version of Java in Android. It went all the way to the Supreme Court.)

But no lawsuit followed Intel’s throat-clearing. Microsoft released its 32-bit x86 emulator with Windows for ARM and then added a 64-bit x86 emulator in December 2020. Intel’s implied threats might deter smaller companies or open-source efforts that don’t want to run afoul of a multibillion-dollar firm, but there’s no evidence of that, either. Open-source developers are not shy about sounding alarms if they face these kinds of threats, so I expect we will hear about them if they arise.

For now, if you need an Intel-only operating system, you have to keep Intel hardware running, which might include virtualization software that powers operating systems other than the host operating system. In the past, wherever there’s been an interest in reviving older hardware, there has been sufficient will to make an emulator happen, whether commercial, open-source, or both. We’ll see if that happens again.

Glenn recently wrote a book specifically about Apple silicon Macs, Take Control of Your M-Series Mac, to explain the substantial differences in macOS, recovery mode, and running non-Mac apps within macOS.