Rosetta 2 is one of the most important parts of Apple’s strategy for switching to Apple silicon Macs, as it enables their Arm processors to run code built for Intel x86 64-bit (x86_64) processors. Without it, there would still be a lot of key apps that couldn’t be run on new Macs. This is the second time Mac OS offered this type of feature: the original Rosetta enabled Intel Macs to run code built for PowerPC processors.

Rosetta isn’t a Virtual Machine (VM), which merely provides a layer to work between different operating systems, and can’t run across different processor architectures. Neither is it a normal emulator, which provides a virtual processor and is usually painfully slow, as we experienced with PC emulators on PowerMacs in the past.

What it does is take the Intel code to be run on an M-series Mac and translates it from Intel to Arm code, before the code is run, known as ahead-of-time translation, or aot. When you then come to run that app or tool, it should be almost as fast as on an equivalent Intel processor, and experience with Rosetta 2 confirms this: performance on Apple silicon Macs is comparable in most cases with that on an equivalent Intel Mac, sometimes even better. If you’re interested in the tricks that are used by Rosetta 2 to achieve this, then Dougall Johnson’s article examines those in detail.

If you look inside macOS, or in the log, you’re unlikely to come across Rosetta, as internally it’s known as OAH. All its components are stored on the Data volume, not in the sealed System, as it’s only installed on demand, and can be updated outside of normal macOS updates. Its executable code is thus stored in the path /Library/Apple/, with its components in usr/libexec/oah, and in usr/share/rosetta. Also notable in Ventura (but not before) is RosettaLinux, included in the usr/libexec/oah folder, providing Rosetta for use in Linux virtual machines.

It consists of a Launch Daemon, run by com.apple.oahd.plist, and its root helper, which provide the oahd service, and this is the only part of it which you’ll see in action in the log. These components are all small, but in extremes of use OAH can consume a lot of memory and CPU when called on to translate very large Intel executable code files.

Whenever possible Rosetta completes its translation well before the code is required to be run. For some apps, this may occur when they’re installed on the Mac, but it can also be delayed until launch time. One way to observe this is to open a Universal App with the option to Open using Rosetta ticked (in the Finder’s Get Info dialog).

While Launch Services and other macOS subsystems are preparing to launch the app, you should see three small entries in the log.
Aot lookup request for <private>
marks the request to see if there’s already a cached copy of the translated code. If oahd finds a cached copy of the translated code, it reports
Using cached aot <private> -> <private>

If there isn’t, then oahd continues with the process of translation, reporting
Translating image <private> -> <private>
Once that’s completed, that’s reported in the log with
Translation finished for <private>
Typical translation time for a minimal 242 KB Universal binary, with a little more than 100 KB of Intel executable to be translated, is less than 0.0125 seconds.

When that Intel code is being run, its entry in the Launch Services app information dictionary records LSArchitecture as “x86_64” rather than “arm64”, which is just about the only thing to tell you what has occurred.

What happens here is that the whole of the app’s Intel executable is loaded into memory, passed to OAH, which translates its executable code into Arm instructions, and hands that back to be run. For a small app, this can be accomplished while Launch Services and other subsystems are preparing to launch the app. For more substantial apps, that may require a lot of code to be loaded into memory, considerable translation work, and a significant delay in launching, hence the aim to perform this aot, before the user needs it.

On an Apple silicon Mac, you can readily tell different types of app apart from their Get Info dialog. Most current apps should be Universal, in that they contain complete executable code to run on both Intel and M1 Macs.

Their Get Info dialogs contain a checkbox which allows you to force them to be opened using Rosetta. Older apps which don’t yet support running native on Apple silicon Macs are reported as being Intel apps.

You may see the first apps which can only run on an M1, so are identified as Apple Silicon apps.

Being able to force an app to run using Rosetta has its uses. One of the rules for Apple silicon Macs is that you can’t mix Intel and Arm code in the same process. If an app is going to load code modules dynamically, then those too must be run using the same architecture. Rosetta translation applies to an entire process, and you can’t mix and match code within any process.

If your app does need to load code modules that are still Intel-only, then you may need to force it to be opened in Rosetta, or those Intel-only modules may not be available when it’s running. There may also be occasions when you want other loaded code to run in Rosetta: some tools and executables work differently on the two architectures, and it may be advantageous to be able to get Intel results on an Apple silicon Mac. One example of this is any code which uses Mach Absolute time, which is quite different between the two architectures. An app run in Rosetta translation is given Mach ticks equivalent to one every nanosecond; M-series native Mach ticks are incremented every 41.67 nanoseconds instead.

There are three types of Intel code which can’t be run using Rosetta:

• kernel extensions, which is just as well as most are getting old;
• virtualisation environments like Parallels Desktop and VMware, and lightweight virtualisers;
• code requiring specialist Intel vector instructions or processor features, which is rare.

The fundamental requirement for any app or tool to translate in Rosetta and run successfully on an Apple silicon Mac is that it must be wholly 64-bit, and fully compatible with that version of macOS running on Intel Macs. Unfortunately, this excludes all those apps which can only be run in Big Sur or later inside a Mojave virtual machine, including Adobe CS6 and other stalwarts still in wide use despite their age.

Unless an Apple silicon Mac has already used Rosetta, it shouldn’t be installed, and it’s only downloaded and made available if it’s needed. If you want it installed earlier, all you have to do is run an app requiring translation, either an older version which isn’t a Universal App, or by running that app (temporarily) using Rosetta. If you want a convenient script to preload Rosetta, Rich Trouton provides one on Der Flounder blog.

Rosetta 2 translation is also available within macOS lightweight virtualisation environments, for both macOS and Linux guests. In macOS VMs it’s installed and used exactly the same as within the host macOS, even including the RosettaLinux folder despite the fact that it can’t be used within a VM. For Linux to be able to use Rosetta 2, a special shared folder has to be created by the virtualiser, then mounted in the Linux guest. Further steps are required to set Rosetta to translate x86_64 ELF binaries when required. Virtualisers which don’t use the macOS lightweight virtualisation framework are unlikely to support Rosetta in guest VMs.

Further information about Rosetta for developers is here.