Open-source project
OpenEmu-Silicon/OpenEmu-Silicon avatar
OpenEmu-Silicon/OpenEmu-Silicon

OpenEmu-Silicon runs the classic Mac emulator natively on Apple Silicon

Native ARM64 port of OpenEmu for Apple Silicon MacBooks

521 stars27 forksC++NOASSERTION

At a glance

What is it?
OpenEmu-Silicon is a community fork of the OpenEmu classic Mac emulator, rebuilt as an ARM64 binary with Metal rendering for M-series Macs, with 30 plus emulated systems, RetroAchievements, automatic cover art, save states and cores that update on their own.
Who is it for?
OpenEmu-Silicon fits a Mac user who wants to run classic Mac software and console games on an M-series machine without Rosetta, and who is willing to use a fork rather than the upstream project. It is the wrong tool if you need Intel-only software, since the build is ARM64 native, and it is the wrong tool if you rely on old save states, because states from certain older cores are incompatible with the current builds and crash when loaded.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 3 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A fork that exists because of the processor change

OpenEmu-Silicon is a community-maintained fork of OpenEmu for M-series Macs, and the fork exists for one reason: the processor. The upstream project was built for Intel Macs, and an ARM64 machine cannot run it without translation, so the community took the codebase and rebuilt it natively.

The result is described as fast, native and with no Rosetta, and the first feature in the list is the ARM64 build with Metal rendering and no Rosetta required. Metal matters as much as the architecture here, because the old Intel build would have used whatever the era provided, and Metal is the current graphics path on Apple hardware.

The compatibility target is stated precisely. It runs on macOS 12.0, Monterey, and later, and has been tested on macOS Sequoia and macOS 26, Tahoe. The installer is signed and notarized, so there is no Gatekeeper workaround, which matters because a notarized build is the difference between dragging an app into your Applications folder and fighting your system security settings.

The experience it preserves is described as library-first. You drop in your games, you get cover art, you pick a system and you play. The fork is not a redesign, it is the same front end with a different engine underneath, plus new cores, fixes and features added on top.

Installing it, and the two things that catch people out

The install is a signed DMG from the releases page, or a Homebrew cask, and the cask route is two commands:

bash
brew tap OpenEmu-Silicon/OpenEmu-Silicon https://github.com/OpenEmu-Silicon/OpenEmu-Silicon
brew install --cask openemu-silicon

The requirements are stated in the same breath: an Apple Silicon Mac, an M1, M2, M3 or M4, running macOS 12.0 or later. There is no Intel build mentioned, which follows from the ARM64 native approach.

The first catch is the save states. Save states from certain older cores are incompatible with the current ARM64 builds and will crash if loaded, and the app detects these on launch and shows a warning. The instruction is to back up your save states before your first launch, and the migration wiki page has the list of affected ones and the instructions.

The second catch is permissions. Input Monitoring permission may need to be granted manually in System Settings under Privacy and Security, which is the macOS prompt that appears when an application starts reading keyboard or controller input, and which does not always appear on first run.

There is also a migration guide for people coming from the original OpenEmu, and the README suggests reading it first, which is a reasonable instruction for anyone with an existing library and save states.

Thirty plus systems, and the two that have no core

The systems list is long and the README names the notable ones: NES, SNES, Game Boy, GBA, N64, Nintendo DS, PlayStation, Dreamcast, GameCube and Wii, and more. The full working status, the BIOS requirements and the planned work are on the Supported Systems wiki page.

The caveats are given just as plainly. A handful of systems have known issues, with PSP, Saturn and Game Boy Color categorization named, and PS2 and the Commodore 64 have no core yet. So the honest number is 30 plus systems working today, with two well-known platforms absent and a few more imperfect.

BIOS requirements are called out as part of the wiki page rather than the feature list, which is the right place for it, since the requirement is per system and changes with the core. The repository layout backs the breadth up. The top-level entries include directories named after the emulators themselves, among them BSNES, DeSmuME, Dolphin, FCEU, Flycast, Gambatte, GenesisPlus, MAME, Mednafen, Mupen64Plus, Nestopia, PPSSPP, SNES9x, Stella, blueMSX, mGBA, Picodrive, 4DO, Atari800, Bliss, CrabEmu, JollyCV, O2EM, PokeMini, Potator-Core, ProSystem, VecXGL and VirtualJaguar, along with the OpenEmu app source, the OpenEmuKit, the OpenEmu-SDK, the OpenEmu-Shaders directory and the Xcode workspaces and schemes for the app.

That is a monorepo of emulators, which is how the project can update a core without shipping a new app.

Cores that update on their own, and the separate release stream

One feature line stands out from the rest of the list, and it changes how the project is maintained: easy updates, with emulation cores updating on their own, without a full app release.

The release list shows how that works in practice. There are two streams of tags, v1.4.0 for the app itself on 2026-10-14, and cores-v1.6.0 for the emulation cores on the same day, with cores-v1.5.1 a fortnight earlier. The cores are versioned independently of the application, which is exactly what lets a core be fixed or replaced without asking every user to reinstall the app.

The other features are more ordinary but each carries a decision. RetroAchievements is supported on 9 cores, covering NES, SNES, Game Boy, GBA, Genesis, N64, PlayStation and more. Automatic cover art pulls box art and metadata through ScreenScraper. Save states and persistent saves mean you can pick up where you left off, and the controller support is described as mapping for the controllers Mac players actually use rather than a generic gamepad. There is also built-in cheat database integration, which is a standard emulator feature.

The project describes itself as free and open source, with no ads and no paywall, and states that it stays that way.

The save state problem, stated plainly

The known issues section leads with the save state compatibility problem, and it is worth giving it its own attention because it is the one thing that can cost you progress rather than time.

Save states from certain older cores are incompatible with the current ARM64 builds and will crash if loaded. The app detects these on launch and shows a warning, which is a good piece of engineering: the failure is caught before it becomes a crash mid-session. The instruction is still to back up your save states before the first launch, and the migration page lists which ones are affected and what to do about them.

The reason is structural rather than a simple bug. A save state is a snapshot of the emulated machine's memory, and the memory layout of a rewritten ARM64 core is not the layout the old Intel core produced. Two other entries in the known issues are smaller. Input Monitoring permission may need to be granted manually, and a few cores have quirks on Apple Silicon that are still under investigation, with the open issues linked.

For a user coming from the original OpenEmu with a library of saves, that first point decides whether the migration is a ten minute job or an afternoon of work, and the README's advice is to read the migration guide before installing rather than after.

The community roles, which are not all code

The contributing section is unusual in a good way, because it names five roles and only one of them involves writing code. The table lists a compatibility tester who tests games on the latest build and documents results, an issue triager who reproduces bugs, labels issues and closes duplicates, a RetroAchievements liaison who tests achievements per core and keeps the compatibility table current, a docs and wiki role that keeps install guides and core pages accurate, and a code contributor for bug fixes, features and core updates.

The Discord is the place where that happens, and the README says it is the best place to get help, follow development, try early builds and talk to the people working on the project, and that you do not need to write code to be part of it. Each of the three groups is described in a line: testers try new builds and cores before release and report what breaks, contributors talk through a fix or feature before opening a pull request, and players ask questions, share setups and say which systems they want improved.

The starting point is CONTRIBUTING.md in the .github directory, which covers the development setup, the branch and pull request rules and each role in more detail, and the README suggests issues labelled good first issue for anyone looking for a first task. When you report a bug, the guidance is to give your Mac model, your macOS version, and the system and game you were running, because that context is what is most useful.

The repository also carries an AGENTS.md and a CONTEXT.md, plus .claude and .cursor directories and a .githooks directory, which is the standard set of files for a project where automated assistants are expected to work in the tree.

Where OpenEmu-Silicon is the wrong choice

The first limit is the hardware. An ARM64 native build with no Rosetta means Intel-only software does not run, and the stated requirement is an M1, M2, M3 or M4. If you need to run old Mac software that has no modern build, the translation layer is the point, and this project deliberately drops it in favour of native speed.

The second is the systems that are missing or imperfect. PS2 and the Commodore 64 have no core, and PSP, Saturn and Game Boy Color categorization have known issues. If one of those is the system you actually care about, the fork is not the answer and a standalone emulator for that console is.

The third is save state portability, already covered, and it is the sharpest one for an existing OpenEmu user.

The fourth is the trust question around core updates. The ability to update a core on its own is convenient, and it also means a core can change under you without the app changing. A user who cares about reproducibility of a particular game has to pin the core, and the project does not describe a mechanism for that beyond the versioned core tags.

The fifth is the licensing, which is a stack rather than a single thing. The badge in the README says BSD-3-Clause plus core licenses, because each emulator core carries its own terms, and the LICENSE file at the root of the repository is the reference. For a project that ships many third-party emulator cores, that is a reasonable arrangement and also one that needs reading rather than assuming.

Finally, the legal boundary is the same one every emulation project has. The software is open source and the project is explicit that it is free with no ads and no paywall, but you supply the games and the BIOS images, and the responsibility for what you run is yours.

Licence, release rhythm and the state of the project

The licence is the one named in the badge, BSD-3-Clause plus core licenses, with the LICENSE file in the repository as the reference and the individual core directories carrying their own terms. The repository's licence field is recorded as a custom licence that GitHub cannot classify, which is the usual outcome when a project ships code under several licences at once.

The release history shows active work. The app release v1.4.0 came on 2026-10-14, the emulation cores release cores-v1.6.0 on the same day, and cores-v1.5.1 on 2026-10-01. The last push to the repository was on 2026-10-20, and the repository is not archived.

The primary language is C++, and the repository layout confirms a native application rather than a wrapper. There is the OpenEmu app source with its Xcode workspace, iconset and xcworkspace file, the OpenEmuKit framework, the OpenEmu-SDK, an OpenEmu-Shaders directory, the per-emulator core directories, a Casks directory, an Appcasts directory and a Scripts directory, plus appcast.xml at the root, which is the Sparkle-style update feed for the app. The .lldbinit and .githooks entries point to a native development setup with debugger configuration and version control hooks wired in.

The project describes itself as actively maintained for M-series Macs, and the rate of releases is consistent with that claim.

Editorial conclusion

OpenEmu-Silicon fits a Mac user who wants to run classic Mac software and console games on an M-series machine without Rosetta, and who is willing to use a fork rather than the upstream project. It is the wrong tool if you need Intel-only software, since the build is ARM64 native, and it is the wrong tool if you rely on old save states, because states from certain older cores are incompatible with the current builds and crash when loaded. Before you install it, check three things: that your Mac is an M1, M2, M3 or M4 on macOS 12.0 or later, that you back up your save states before the first launch, because the app detects the incompatible ones and warns you, and that you read the Supported Systems wiki page, since PS2 and the Commodore 64 have no core and a handful of systems have known issues. The licence is BSD-3-Clause plus per-core licences, the current release is v1.4.0 from 2026-10-14, and the last push was on 2026-10-20.

Frequently asked questions

What is OpenEmu-Silicon and who maintains it?

It is a community-maintained fork of OpenEmu for M-series Macs, rebuilt as a native ARM64 build with Metal rendering so no Rosetta is required. It runs on macOS 12.0 or later and has been tested on macOS Sequoia and macOS 26.

How do I install OpenEmu-Silicon?

Download the latest signed DMG from the releases page, or use Homebrew with `brew tap OpenEmu-Silicon/OpenEmu-Silicon https://github.com/OpenEmu-Silicon/OpenEmu-Silicon` followed by `brew install --cask openemu-silicon`. You need an Apple Silicon Mac, an M1 to M4, on macOS 12.0 or later.

Will my old save states work in OpenEmu-Silicon?

Not always. Save states from certain older cores are incompatible with the current ARM64 builds and will crash if loaded. The app detects these on launch and warns you, and the README asks you to back up your save states before your first launch and to read the migration guide.

Which systems are missing or imperfect in OpenEmu-Silicon?

30 plus systems work today, but PS2 and the Commodore 64 have no core yet, and a handful have known issues, with PSP, Saturn and Game Boy Color categorization named. Full working status and BIOS requirements are on the Supported Systems wiki page.

How do emulation core updates work in OpenEmu-Silicon?

Cores update on their own without a full app release, and they are versioned separately from the application. The recent tags show v1.4.0 for the app and cores-v1.6.0 for the emulation cores, both on 2026-10-14.

Official sources

  1. Issues
  2. OpenEmu-Silicon/OpenEmu-Silicon on GitHub
  3. README
  4. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/openemu-silicon-openemu-silicon.svg)](https://hysenlabs.com/projects/openemu-silicon-openemu-silicon)

Was this useful?