Mandarine-Neo: a Citra fork carrying experimental 3DS hacks

A fork whose selling point is what it adds and what it might break

Mandarine-Neo is a fork of Citra, the open source Nintendo 3DS emulator, and the project description is unusually candid about what it is for: a Citra fork with new features and hacks which are experimental and may not be present in Azahar, and a continuation of the Mandarine 3DS emulator project.

That framing matters because it defines the project as a delta rather than a product in its own right. The README calls it an alternative Citra fork with experimental hacks and features. There is no feature matrix in the documentation, no list of compatibility differences, and no statement of which upstream Citra commit the fork is based on. What you are given is a build, a set of requirements, and the project maintainer's own position on how the fork relates to Azahar.

The maintainer is direct about the comparison. The README has a section titled with the question of whether Azahar is more up to date, and answers that it is, adding that Azahar is still the recommended choice for most people. The reason to try this fork is given as wanting an alternative which may have exclusive features and hacks not present on Azahar.

So the honest way to evaluate Mandarine-Neo is as a specialist build for a user with a specific problem, not as a general replacement. The 3DS emulation scene has a de facto upstream in Azahar, and this project positions itself beside it rather than against it.

The code is C++, and the repository layout is that of a large emulator project: a src directory, externals for vendored dependencies, tools, a CMakeLists.txt with a CMakeModules directory, a Doxyfile for generated documentation, a dist directory for packaging, hooks for version control integration, a .gitmodules file for submodule dependencies, and a .ci directory for continuous integration.

Where the fork sits relative to upstream Citra and to Azahar

The relationship chain has three links, and each carries a different kind of risk.

The first link is Citra itself. Mandarine-Neo is a fork of Citra, so it inherits Citra's architecture, its code layout, and its baseline compatibility. A fork of an emulator also inherits the legal and practical situation of that emulator, which is why the licence matters here.

The second link is Mandarine. The project description says it is a continuation of the Mandarine 3DS emulator, which suggests a lineage before the Citra fork, and the project is named for it. The release names show this too, with the r1.3.0 tag labelled Mandarine-Neo 1.3.0 and the previous two labelled Mandarine 1.2.1 and Mandarine 1.2, so the Neo suffix and the new versioning arrived together with the Citra base.

The third link is Azahar, which the README treats as the alternative rather than a competitor. The stated difference is scope: Azahar is more up to date, Mandarine-Neo may carry exclusive features and hacks. The difference in approach is therefore about the kind of change being made. A project that tracks upstream closely will accumulate whatever the upstream community is fixing, and will be more likely to be compatible with current game and homebrew expectations. A project that adds its own experiments may reach behaviour that upstream has not accepted, or has rejected for good reason, and it will drift from upstream over time.

That drift is the real cost of a fork at this scale, and it is worth weighing before installing. A hack that fixes one title may be a workaround for a bug that upstream solved differently, and a later upstream release may make that workaround wrong.

Installing: take the release build for your operating system

There is no build-from-source section in the README, and no package manager recipe. The installation instruction is one sentence: grab the appropriate release for your operating system of choice from the Releases section of the page.

That is a deliberate simplification for a C++ emulator with vendored externals, a CMake build, and a CI directory, since producing a working build for each platform is a packaging problem the project has already solved for you. It also means the binary you run is the binary the maintainer tested on that platform, not one you compiled.

One platform note comes with it, and it matters on Windows.

> For Windows, we reccomend MSYS2 since it doesnt need the `Microsoft Visual C++ runtime` in order to work

The typo is the maintainer's, but the instruction is clear. The Windows build is expected to run under MSYS2, and the reason is that it does not require the Microsoft Visual C++ runtime to be installed on the machine. That is a real convenience for anyone on a managed corporate workstation where installing a redistributable is not permitted, and it is also a dependency decision baked into the build, since the project was compiled against a different C++ runtime than the one most Windows software uses.

The recommended system requirements section is given as plain blocks, one for desktop and one for Android.

Operating System: Windows 10 (64-bit), MacOS Ventura, or modern 64-bit Linux
CPU: x86-64 (64-bit) CPU. Single core performance higher than 1,800 on Passmark
GPU: OpenGL 4.3 or Vulkan 1.1 support
Memory: 2GB of RAM. 4GB is recommended

The Android requirements are the second block, and the CPU expectation is specific.

Operating System: Android 9.0+
CPU: Snapdragon 835 SoC or better
GPU: OpenGL ES 3.2 or Vulkan 1.1 support
Memory: 2GB of RAM. 4GB is recommended

A Snapdragon 835 is a 2017 part, so this is a mid range bar rather than a flagship one, which is a reasonable target for an emulator that runs on a CPU. The GPU requirement matters as much, since OpenGL 4.3 or Vulkan 1.1 is the floor for the desktop path and OpenGL ES 3.2 or Vulkan 1.1 for the mobile one.

What the release history says about the pace of work

The release list is short and the gaps between entries are the story. The newest tag is r1.3.0, labelled Mandarine-Neo 1.3.0 and published on 2026-04-15. The two before it are r1.2.1 from 2025-01-29 and a tag written r1,2 for Mandarine 1.2 from 2025-01-28, which are effectively the same day.

So the project shipped a 1.2 line in late January 2025 and a 1.3 line in April 2026, roughly fifteen months apart, and the last push was on 2026-04-19, four days after the r1.3.0 tag. The branch in use is neo, which matches the fork's new name.

There is an inconsistency worth flagging for anyone tracking versions: the r1.2.1 tag is labelled Mandarine 1.2.1 while r1.3.0 is labelled Mandarine-Neo 1.3.0. The project was renamed between those releases, so a version number alone does not tell you which codebase you are looking at, and the r1,2 tag string has a comma in it rather than a dot, which means scripts that parse tag names will trip over it.

Because this is a fork whose own README says another project is more up to date, the release cadence is the honest measure of how much work is going in. Fifteen months between minor versions, with the last activity in April 2026, describes a project in a steady but unhurried state rather than one chasing every upstream change. For a user whose goal is the newest compatibility, that is the deciding fact.

What you give up by choosing a fork over the maintained build

The honest limitations of this project are visible in the documentation, and they are not small.

The first is upstream drift. Mandarine-Neo is a fork, and the project does not document which Citra commit it is based on, so there is no way to tell from the repository whether a given upstream fix is present. The README says the experimental hacks may not be present in Azahar, and by the same logic there is no statement that anything from Azahar is present here. Upstream compatibility work since April 2026 is, as far as the documentation shows, not tracked.

The second is that the hacks are experimental. The description says so twice, in the project description and in the README, and the README does not enumerate them. A user installing the build for a specific title is relying on an undocumented behaviour of a specific build, and the failure mode when it does not work is not a clear error but a wrong picture, a hang, or a crash.

The third is the documentation. There is no user manual here, no troubleshooting section, and no compatibility list. The README is a page of about a dozen lines covering what the fork is, how to install, the hardware requirements, a Discord link, and a donation link. For a project whose entire premise is that its differences matter, that is a thin surface. Anyone who needs to know what a given hack does is dependent on the Discord server or on reading the source.

The practical conclusion is that Mandarine-Neo is a project to install when you already know what you want from it, and not a project to adopt as your default emulator.

Editorial conclusion

Mandarine-Neo fits a player who is chasing a specific compatibility hack or a feature that Azahar does not carry, and it does not fit a user who wants the most up to date emulator or a predictable release stream, because the project itself points to Azahar for most people. Before switching, read the release notes for the r1.3.0 tag and check that the hack you want is actually in the build you install, and confirm your machine meets the stated requirements, since the desktop path needs OpenGL 4.3 or Vulkan 1.1 and the Android path asks for a Snapdragon 835 or better.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. ptyfyre/mandarine-neo on GitHub
4. README
5. Releases