What is Rosetta 2? Apple’s “magical” compatibility software explained

With the transition from Intel Macs to ones that use Apple’s own Arm-based processors, there was the specter of how software written for one type of processor would run on this new hardware. Rosetta 2 quickly put to rest any concerns early adopters of Apple Silicon might have had, but what exactly is Rosetta 2, and how does it work?

Why do we need Rosetta 2?

Rosetta 2 is what’s known as a dynamic binary translator, and we’ll unpack that a little for it to make more sense.

First, it’s “dynamic” because Rosetta 2 does its job at runtime. That is, it begins working when you actually run the program, as opposed to a static translator, which tries to work its magic on all the code for a program upfront instead of dynamically as needed. Translating all the code preemptively using a static approach isn’t always the best, since not only is it time-consuming, but a static translator may simply find it impossible due to a number of factors.

For example, many modern applications use JIT (Just-in-Time) compilation, where the code is generated at runtime. Because this code doesn’t exist until the application is running, it has to be translated dynamically.

Additionally, applications often call up libraries or external modules as needed during execution. Since these components are only loaded under specific conditions, they also require dynamic translation. Rosetta 2 is designed to handle these situations, translating code on-the-fly to ensure its compatibility with Apple Silicon.

A “binary” is a finished program that can be executed, i.e. it can actually be run by a processor. It’s called a binary because inside it’s all raw binary machine code (all ones and zeros). This is notable because software isn’t written by people in raw binary code. Instead, it’s written in a high level programming language which somewhat resembles a human language such as English. Languages like C or Python are examples of these, but there are countless programming languages out there.

This human-readable code is then turned into an executable binary by a program called a compiler. A compiler then, well, compiles the binary code for a specific type of processor. Intel processors found in the previous generation of Macs use the x86_64 instruction set while Apple Silicon uses the Arm instruction set.

The instruction set of a processor is the list of instructions, in binary or machine code, that tell it to perform certain tasks. An instruction could be something like “multiply x by y” or “move information from this part of memory to that part of memory.” Both Intel and Arm CPUs can do the same sort of work, but their instructions are different. So, if an Arm CPU tried to execute code meant for an Intel CPU, it either wouldn’t understand the instruction or might perform a different operation because the same binary code represents different instructions on each CPU.

It’s not just that the specific instructions differ, but the way these processors execute instructions is very different. The “R” in Arm is short for “RISC” or Reduced Instruction Set Computer, versus the “CISC” or Complex Instruction Set Computer architecture used by Intel CPUs. RISC CPUs complete short instructions with every clock cycle, while CISC CPUs may take multiple clock cycles to complete one complex instruction.

This is why we need Rosetta 2 as a “translator” to bridge the gap between these two different processor languages.

How Rosetta 2 works

When you try to run a macOS application that’s been written for Intel-based Macs, Rosetta 2 steps in and dynamically translates the binary code of the program. In simple terms, it interprets the x86_64 instructions and converts them into instructions that the Apple Silicon processor can understand. This process is more sophisticated than a simple one-to-one translation, involving complex real-time optimization to ensure the translated application runs smoothly on Apple Silicon.

While Rosetta 2 is highly capable, the Arm binary code it generates generally isn’t as efficient as code from a native Arm application specifically written for Apple Silicon. These translated apps may not fully utilize all the advanced features of Apple Silicon CPUs. Therefore, in the long run, it’s preferable for developers to create native versions of their apps to fully leverage the performance and capabilities of Apple’s new platform.

How to use Rosetta 2

For you as a user of an Apple Silicon Mac, there’s nothing special you have to do or know in order to make use of Rosetta 2. The first time that you run a program that requires Rosetta 2, you’ll be prompted to install the software. You’ll also have to wait a while for the first time you run an Intel Mac application, since the initial translation process can take some time. The next time you run that particular app, it should launch as quickly as a native Apple Silicon app.

Rosetta 2 has its downsides

While Rosetta 2 is pretty amazing in my experience, it’s not a magic bullet. It’s not meant to be a permanent solution to software compatibility, and software developers are expected to create native Apple Silicon software eventually. Of course, some apps that are no longer in development and currently work using Rosetta will continue to rely on Rosetta 2. However, in the long term, most of the software running on your Mac will be native without the need for Rosetta 2 to translate anything.

For applications running under Rosetta 2, performance will never be quite as good as a native application. How big the difference is depends on the specific type of application. For example, you’re unlikely to notice any difference in an application like a word processor, but for apps that really push your hardware like video games or video editors, there could be a noticeable performance gap.

I’ve personally never experienced this, but it is worth noting that while Rosetta 2 is highly-compatible and effective, some applications simply won’t work correctly after translation. As per Apple’s developer documentation, there are some types of instructions that Rosetta 2 won’t touch, such as AVX, AVX2, and AVX512. It also won’t work with Intel-based Mac apps that use kernel extensions, where software is allowed to load code into the operating system kernel. “Virtual Machine apps that virtualize x86_64 computer platforms” are also a no-go for Rosetta 2.

Hopefully, software developers who have apps that are buggy or don’t work at all under Rosetta 2 have ported them to Apple Silicon by now, but there will always be a few legacy apps that are no longer under development and are unlikely to ever work under Rosetta 2 unless Apple updates their translator to address these specific issues. With an understanding of how the translation process works, at least we can appreciate why that may happen.