Flycast: a GPL-2.0 Dreamcast and Naomi emulator for desktop, Android and consoles

What Flycast emulates and who it is for

Flycast targets four Sega arcade and console platforms: Dreamcast, Naomi, Naomi 2 and Atomiswave. That combination is the reason to choose it over a Dreamcast-only emulator. Naomi and Naomi 2 are arcade boards built on Dreamcast-era hardware, and Atomiswave is a later arcade system that shares the lineage, so an emulator that covers all four lets a cabinet owner or arcade preservationist work with one binary instead of several.

The README describes the project as a multi-platform emulator derived from reicast, and the repository confirms the scope: a core/ directory holding the emulation code, shell/ for the platform frontends, and separate CI workflows for Android, C/C++, Nintendo Switch, Windows UWP and BSD. That workflow list is the clearest statement of which platforms are exercised on every change. Anyone emulating Dreamcast games on a desktop, a phone, a Switch or an Xbox Series console is in the intended audience. The project is licensed GPL-2.0, which matters if you plan to redistribute a build or bundle it into a product.

How the emulator is structured: core, shell and platform frontends

The repository layout separates the emulation core from the user interface. core/ holds the emulation logic, shell/ holds the per-platform frontends (the README references shell/linux/flycast.png for the logo and shell/apple/generate_xcode_project.command and shell\windows\generate_vs_project.bat for project generation), and resources/, fonts/ and intl/ hold assets and localization data. The crowdin.yml file at the top level indicates translation work is managed through Crowdin, which lines up with the v2.7 release note naming localization as a theme.

That split explains how one codebase reaches Android, Linux, macOS, Windows, Switch and Xbox. Each frontend drives the same core, so a fix in core/ benefits every platform, and a platform-specific problem lives in its own shell directory. The practical consequence for a user is that the Android build and the desktop build share emulation behaviour but not menus, input handling or file pickers. The practical consequence for a contributor is that a change touching core/ needs to be judged against five CI workflows. The README points configuration and supported-feature questions at an external wiki, not at documentation inside the repository, so the repo itself tells you less about options than you might expect.

Installing Flycast on Linux, macOS, Android and Xbox

The README gives four supported install paths. On Linux, Flycast is on Flathub and the documented commands are a two-step pair. The first installs the application, and the second launches it. After the install command completes, the application appears in your desktop environment's launcher under the name Flycast.

flatpak install -y org.flycast.Flycast
flatpak run org.flycast.Flycast

On macOS, the project maintains a Homebrew tap with three channels. Master is described as recommended, stable tracks tagged releases, and dev is the nightly channel. The cask names differ only by suffix, so switching channels means uninstalling one cask and installing another; the README defers update, uninstall and channel-switching instructions to the tap's own README.

brew install --cask flyinghead/flycast/flycast@master

Android is the simplest case: the README points at a single Google Play listing, com.flycast.emulator, and gives no sideloading instructions. For Xbox One and Series consoles, the README says to take a build from the builds page or the UWP GitHub Actions workflow and install it through the Xbox Device Portal, which is a developer-mode feature rather than a store install. iOS is not an option: the README states that support for the platform was dropped.

Building Flycast from source on Linux

The README lists the Linux build dependencies explicitly: a C/C++ compiler toolchain such as gcc/g++, CMake, make, libcurl development headers, libudev development headers, SDL2 development headers, and a graphics API, either Vulkan or OpenGL. Missing any one of the development header packages stops the configure step, and the error usually names the library rather than the package, so install the -dev variants your distribution provides.

The build itself is a standard out-of-tree CMake flow. The clone uses --recursive, which is required because the repository carries a .gitmodules file and therefore submodules; a plain clone without that flag leaves the build short of dependencies.

git clone --recursive https://github.com/flyinghead/flycast.git
cd flycast
mkdir build && cd build
cmake ..
make

On macOS and Windows the README does not describe a command-line build. It points at bootstrap scripts instead: shell/apple/generate_xcode_project.command on macOS, which the README says to open by right-clicking and choosing Open, and shell\windows\generate_vs_project.bat on Windows, which it says to double-click. Both generate a platform project rather than building directly.

BIOS, builds and the parts the README leaves to the wiki

The README is short for a project of this scope. It does not document BIOS handling, memory card or VMU configuration, controller mapping, or network play; it directs readers to TheArcadeStriker's flycast wiki for configuration and supported features. If you are trying to work out whether a specific game needs a BIOS image or how to attach a VMU, the repository README will not answer it, and that is a real cost for a first-time user.

What the README does document is the build channel structure, and it is worth reading carefully. There are three: latest master builds from the master branch, nightly dev builds described as experimental, and stable tagged releases on GitHub Releases. The macOS Homebrew tap mirrors that split with its three casks. The distinction matters because a bug you hit on a nightly may not exist in a tagged release, and a fix you are waiting for may only be on master. The README also notes that automated test results are published on the builds page, which is the only testing signal the material describes.

The release history shows the project is still adding platform features rather than only fixing games: v2.5 introduced DCNet and support for DreamConn+ and DreamPicoPort adapters, v2.6 added per-pixel rendering with OpenGL ES and a Battle cable server, and v2.7 covers localization and Naomi multiscreen. The last push to the repository was on 2026-09-28.

Flycast against RetroArch and standalone Dreamcast emulators

The most common comparison is with RetroArch, and the difference is architectural. RetroArch is a frontend that loads emulator cores, so using Flycast through it means running the same emulation code behind RetroArch's menus, shaders and input stack. The standalone build ships its own shell and its own settings interface. If you already run a RetroArch setup and want Dreamcast inside it, the core route keeps one interface and one controller configuration; if you want the project's own frontend, current features and its release channels, the standalone build is the direct path. The README does not discuss RetroArch at all, so nothing in the repository tells you how the core is packaged or how current it is.

Against other standalone Dreamcast emulators, the distinguishing feature is the arcade coverage. Flycast emulates Naomi, Naomi 2 and Atomiswave alongside Dreamcast, which is broader than a Dreamcast-only emulator. That breadth is also where the trade-off sits: an emulator covering four systems has more configuration surface than one covering a single console. If you only ever run Dreamcast titles and want the smallest number of settings to reason about, the extra arcade support buys you nothing and costs you menu complexity. If you run Naomi titles, it is the whole reason to be here.

Licence and the cost of staying current

Flycast is GPL-2.0. The LICENSE file sits at the repository root and the README states the licence in its header area. For an end user this changes nothing: run it, and the only obligation is the usual one of not misrepresenting where it came from. For anyone redistributing a modified binary, bundling it into a device image, or shipping it inside a commercial product, GPL-2.0 is a copyleft licence with source-availability conditions. That is a question for a lawyer, not for this article, but the trigger point is distribution, not personal use.

Upgrade cost depends on which channel you chose. A Flathub or Google Play install updates through the store. A Homebrew cask install updates through the tap, and switching between master, stable and dev means changing casks. A source build means re-running git pull, then cmake and make, and re-resolving dependencies if the README's dependency list grows. The repository uses submodules, so a source update needs the recursive flag again or the submodule contents stay at their old revisions. There is no documented migration path between channels, and the README does not describe what a version upgrade does to existing configuration files.

Editorial conclusion

Flycast suits anyone emulating Dreamcast, Naomi, Naomi 2 or Atomiswave, especially on Linux or Android where the install paths are short. It is the wrong choice if you want an emulator that ships its own BIOS or runs on iOS, which the README says was dropped. Before adopting it, confirm your PC has Vulkan or OpenGL and the SDL2, libcurl and libudev development headers, and check whether your build is the stable release, master or a nightly, since the three channels differ.

Frequently asked questions

Official sources

1. flyinghead/flycast on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases