Citron Neo carries the Citron emulator forward as a multi-platform project

What Citron Neo actually is

Citron Neo is an open-source emulator that continues the Citron codebase. That single sentence is the whole scope statement, and it is worth sitting with what it implies.

This is a fork-continuation rather than a from-scratch project. The Citron project is gone as a going concern, and its repository description reads, in full, The switch fell off, with a link to citron-neo.org. That phrasing tells you the situation plainly: a project that was working stopped, and someone picked up the code and kept going it under a new name.

What follows from that is a different relationship with the code than a new emulator would have. There is a body of prior art to inherit, and the Citron-continued lineage means existing knowledge about the console, about the patches that were needed, and about the build system carries over. The top-level entries show the shape of that inheritance: a patches/ directory alongside src/, an externals/ directory, hooks/, and a CMakeModules/ tree.

The project describes itself as running on Windows, Linux, macOS and Android (arm64), and the primary language is C++. The licence is GPL-3.0-or-later, with third-party components and their licences listed separately in a LICENSES/ directory, which is what you would expect from a codebase that carries a large external dependency surface.

As a console emulator, its practical use depends on the game dumps you bring to it, and those need to be your own legally obtained copies. The emulator itself is the open-source half of that arrangement.

CPM and the end of submodule juggling

The build story starts with one decision that removes a familiar annoyance, and it is stated early in the README.

Library dependencies are fetched at configure time by CPM, so you don't need to initialise submodules first.

CPM is CMake's package manager, and the practical effect is that the dependency download happens as part of the configure step rather than as a separate manual step. The familiar sequence for a CMake project with submodules is clone, then recursive init, then configure, and people routinely forget the middle step and get a confusing configure error. Here that step does not exist.

There is still a .gitmodules entry at the top level, so the submodule machinery is present in the repository, but the README states plainly that you do not need to initialise it first, and that dependencies arrive through CPM at configure time.

The other build-related entries in the tree support that story. vcpkg.json sits at the root, which is the manifest for the vcpkg C++ package manager, and CMakeModules/ holds the custom find and configuration logic. hooks/ and .git-blame-ignore-revs suggest that repository-level tooling is maintained alongside the code, and the .reuse/ directory indicates that reuse compliance is tracked, which is consistent with the LICENSES/ directory and the GPL-3.0-or-later licensing.

There is also a Doxyfile at the root, so the project generates Doxygen documentation for its internals.

The Linux build and what PGO actually buys

The Linux path is the one the README documents in the most detail, and it is the path to use if you want the fastest build.

The first command is run once:

./build-citron-linux.sh setup

and then the build itself is:

./build-citron-linux.sh use --pgo none --lto full

The flag combination is the interesting part. The script has a setup stage and a use stage, which implies a staged workflow where setup prepares a toolchain or environment and use performs a build against it. Within use, --pgo none turns off the profiling-guided optimisation round and --lto full enables full link-time optimisation.

The README is explicit about the trade-off, because it says the documentation covers the PGO stages, which give the best performance. So --pgo none is the fast iteration path and the PGO route is the release path.

The output location is stated exactly, which saves some hunting. The binary lands in build/use-nopgo/bin/citron, with an AppImage beside it. The path name encodes the choice you made, since it says use-nopgo, so the PGO build must land somewhere else. There is an AppImageBuilder/ directory at the top level, which is the packaging tool for that artifact.

The separate document, docs/BUILDING-CITRON-LINUX.md, is where the PGO stages are described, and the README points there for the performance path. The build script itself, build-citron-linux.sh, is in the repository root.

Windows, macOS and Android as separate build problems

The other three platforms each get their own treatment, and they are not variations on the Linux script.

For Windows the README says to build with clang-cl natively, or cross-compile from Linux with llvm-mingw, and docs/BUILDING-CITRON-WINDOWS.md has both. Two paths for one platform is a deliberate redundancy: the native path is the straightforward one on a Windows machine, and the llvm-mingw path lets a Linux builder produce a Windows binary, which matters for a project that has to produce builds for four platforms from whatever infrastructure is available.

Two scripts at the root match that. build-clangtron-windows.bat is the native Windows entry point, and build-clangtron-windows.sh is the cross-compile one from Linux. The name clangtron in both is worth noticing, since it suggests a renamed or rebranded toolchain path rather than the upstream name.

For Android the route is Gradle rather than CMake. From src/android, the command is:

./gradlew assembleMainlineRelease

That is a standard Android Gradle task name, so the project uses the conventional plugin layout inside src/android rather than something bespoke. One detail is stated plainly and matters more than it looks: without a release keystore in the environment, the APK is signed with the bundled debug key. That is fine for a local build and means the artifact you produce yourself is not distributable as a release build without your own key.

macOS has no separate section in the README, even though the platform is listed as supported. The build system is shared CMake, so the Linux instructions are the closest reference, but the README does not give a macOS-specific command, which is a documentation gap worth knowing about before you start.

Contributing on Discord, and what that costs you

The contribution model is the part most likely to surprise a newcomer, and it is short enough to read in one go.

Development and maintenance happen on Discord.

Then: Issues and pull requests are welcome. Ask on Discord before starting something large. When reporting a bug, say which platform, GPU and driver you're on, and which commit or build you're running.

That last sentence is a good bug report template and it reflects the reality of emulator work, where the same code behaves differently across graphics drivers. But the structure of the arrangement has consequences. The GitHub issue tracker exists and is where issues and pull requests go, yet the coordination happens on a chat server, which is ephemeral and not indexed by search engines. A question asked and answered on Discord is effectively lost to anyone who arrives later.

The same applies to contributors. Being asked to talk to Discord before starting something large means that the design discussion for a significant change lives outside the repository, so a later reader of the history sees a pull request without the reasoning that produced it.

The release record reflects the same rhythm. The releases are dated rather than versioned: 2026-03-27, 2026-04-17 and 2026-04-27, with a CHANGELOG at the top level. The last push was on 2026-10-22 and the repository is not archived, so the code is being worked on even though the last tagged release is from April 2026.

Where Citron Neo fits, and where it stops

The comparison worth making is with the alternatives, and there is an obvious one to state plainly.

The honest framing is that Citron Neo is one emulator among several for the same console, and the difference between them is a matter of lineage, build coverage and how much of the console's behaviour each one reimplements. What Citron Neo inherits from Citron is a codebase that had already been through the long process of working out what the console's hardware actually does. That is real work, and it is not something a new implementation can shortcut.

Its distinguishing feature as described here is build coverage rather than emulation fidelity. Four platforms, a Linux path with a PGO route and full LTO, a Windows path with both native and cross-compile options, and an Android path, all from one CMake tree. For a project that has to run on whatever hardware a user has, that spread is the practical value.

The limits are visible in what the README does not say. There is no compatibility list, no statement of which games or which titles work, no performance figures, and no configuration documentation. An emulator project without a compatibility list leaves the user to discover what works by trying, and the README is a build guide rather than a usage guide. The macOS path is asserted but not documented. And the Discord-centred workflow means the project has no public roadmap, no written architecture notes, and no searchable record of the design decisions.

There is also the licensing dimension for anyone who wants to contribute or redistribute. GPL-3.0-or-later applies to the project, and the LICENSES/ directory records what each third-party component brings with it, which is the file to read before shipping a build that embeds them.

For someone who wants to read, build and modify a console emulator with a four-platform build and a maintained fork lineage, this is a working, recently-touched codebase with a clear structure and an explicit licence. For someone who wants documentation of what runs and how well, the repository does not offer it.

Editorial conclusion

Citron Neo suits a developer or a user who already follows the Citron lineage and wants a build that covers Linux, Windows, macOS and Android from one tree, since the build scripts and the cross-compile paths are the part of the project that is actually documented here. It is the wrong tool if you need an emulator with a public issue tracker roadmap, because the README points contributors at Discord for everything including bug reports, and it is the wrong tool for anyone without their own legally obtained game dumps, since the project is a console emulator and its use depends entirely on what you run in it. Before building, read docs/BUILDING-CITRON-LINUX.md for the PGO stages and docs/BUILDING-CITRON-WINDOWS.md for the native clang-cl and llvm-mingw paths, and check that CPM can reach the network at configure time.

Frequently asked questions

Official sources

1. citron-neo/emulator on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases