osu!lazer ships two codenames, and building it means loading a .slnf not the solution

Two codenames appear in one tag stream, and tachyon is the newest

The three most recent release names are `2026.1026.0-tachyon` on 2026-10-26, `2026.1013.0-tachyon` on 2026-10-13, and `2026.1005.1-tachyon` on 2026-10-05. Each carries a date-number prefix and a codename suffix, and the suffix on all three is one the README does not describe.

The README calls lazer the current codename and calls this the future and final iteration of the client, the one that marks the beginning of an open era, with a joke that lazer is a pun on being sharper than the current state of the art. So the documentation describes lazer while the tag stream's head is tachyon.

The practical consequence is that a version string here is two pieces of information. The date part tells you how current the build is and the suffix tells you which channel it came from, and picking a build means deciding which channel you trust. The status paragraph is the project's own guidance on that: players are encouraged to install from a release alongside their stable osu! client until most users prefer this one over osu!stable.

Load a .slnf, and the README tells you not to open the solution

The build section leads with an instruction that saves a new contributor an afternoon: load the solution via one of the platform-specific `.slnf` files, rather than the main `.sln`, because that reduces dependencies and hides platforms you do not care about.

Three filters are valid: `osu.Desktop.slnf` for the common case, `osu.Android.slnf`, and `osu.iOS.slnf`. The repository root carries all of them plus `osu.sln` and `osu.sln.DotSettings`, and the per-platform projects behind them are `osu.Desktop/`, `osu.Android/` and `osu.iOS/`, with matching `osu.Android.props` and `osu.iOS.props` files that carry the platform-specific build settings.

Mobile adds a step: to build for mobile platforms you will likely need to run `sudo dotnet workload restore`, which installs the Android and iOS tooling the build requires. The solution filters keep those platforms out of a desktop build. Run configurations for the recommended IDEs are included in the repository, so the IDE path is a matter of opening the right file.

One CLI command runs it, and Debug is not a valid way to measure it

There is a command line path, and it is a single line:

dotnet run --project osu.Desktop

No solution juggling, no workload restore for the desktop target, and the README notes that if the build fails you should try restoring NuGet packages with `dotnet restore`. The clone is equally short, `git clone https://github.com/ppy/osu` then `cd osu`, and `git pull` inside the directory updates it.

The instruction that matters for anyone measuring anything is the next one. When running locally to do any kind of performance testing, make sure to add `-c Release` to the build command, as the overhead of running with the default `Debug` configuration can be large, and the README notes the overhead is especially large when testing with local framework modifications.

That is a specific warning about a specific trap. This is a rhythm game, so frame timing is the thing the project cares about, and a Debug build of a game loop is a fine way to produce a number that looks like a regression and is not one.

Four rulesets, and each one carries three test projects

The top level of the repository is dominated by ruleset directories, and there are four: `osu.Game.Rulesets.Osu/`, `osu.Game.Rulesets.Taiko/`, `osu.Game.Rulesets.Catch/` and `osu.Game.Rulesets.Mania/`. Those are the game's four play modes, and they are separate assemblies rather than modes behind a switch, which is why a ruleset can also be written by someone outside the project.

The multiplier is the interesting part. Every one of the four has a matching `.Tests/` directory and also `.Tests.Android/` and `.Tests.iOS/`, so the ruleset test suites are triplicated per platform. The same pattern appears for the core: `osu.Game/`, `osu.Game.Tests/`, `osu.Game.Tests.Android/` and `osu.Game.Tests.iOS/`.

The consequence is that each ruleset has test projects for desktop, Android and iOS. `osu.Game.Benchmarks/` sits alongside them for the performance side.

Framework and resources are separate repos, and the cross-test scripts need siblings

Two of the projects this repository depends on do not live in it. `osu-framework` and `osu-resources` are their own repositories, and the README explains that sometimes it is necessary to cross-test changes in either of them.

The mechanism is a set of four scripts at the root, `UseLocalFramework.ps1` and `UseLocalResources.ps1` on Windows, `UseLocalFramework.sh` and `UseLocalResources.sh` on macOS and Linux. The catch is stated immediately after: the commands assume you have the relevant projects checked out in adjacent directories, and the expected layout is three siblings.

That assumption is a hard constraint rather than a convenience. The layout is a directory named `osu` for this repository, one named `osu-framework`, and one named `osu-resources`, side by side. Clone them anywhere else and the scripts' assumption no longer holds.

Three layers of code analysis, and Fody weaves the build

Before committing, the README asks you to run a formatter, with `dotnet format` in the command line or a Format code command in the IDE. Underneath that sits a second layer, described as cross-platform, compiler integrated analyzers that can provide warnings while you are editing, while building inside an IDE, and from the command line, as if they were provided by the compiler itself.

The third layer is a different tool with a different rule set: JetBrains ReSharper InspectCode, run from PowerShell with `InspectCode.ps1`, or installed for inline support, with Rider named as the IDE that has it. The root carries both `InspectCode.ps1` and `InspectCode.sh`, so the wider rule set is not Windows-only even though the documented invocation is.

Two more root files explain the rest. `FodyWeavers.xml` is present, so the build runs an IL weaving step, and `osu.licenseheader` sits beside it. Add `.git-blame-ignore-revs`, which exists to hide the history of mass-reformatting commits, and the picture is a repository where the mechanical parts of a change are automated and a contributor is expected to run the same tooling as everyone else.

Rulesets are the sanctioned extension point, with templates in the tree

The README's first development section is not about building the game, it is about extending it. osu! is designed to allow user-created gameplay variations called rulesets, and building one lets a developer harness the osu! beatmap library, the game engine and the general UX for a new style of gameplay.

That is the important word, harness: a custom ruleset reuses the beatmap library, the engine and the UX.

Two pointers are given and both are in this repository or next to it. Templates live in `Templates/` at the top level, which is where the README's link goes, and examples of custom rulesets by other people are collected in a custom ruleset directory that is a GitHub Discussions page rather than a folder.

For anyone evaluating this project as a platform, that is the sharpest fact in it. The four built-in modes are the same shape as what a third party would build, so the extension story and the product story are the same story.

iOS access is a TestFlight link that fills to Apple's 10,000 cap

The platform matrix is a single table of direct downloads, and it is unusually complete for a game client: Windows 10+ x64 as an `install.exe`, macOS 12+ with separate Intel and Apple Silicon zip archives, Linux x64 as an AppImage, and Android 7+ as an APK. Versions are pinned per platform, so macOS needs 12 or newer, Android needs 7 or newer, and the two macOS builds are separate files because the architecture split is real.

iOS is the exception, and the README is blunt about why. It ships through TestFlight, and the note says the link fills up very fast because Apple has a hard limit of 10,000 users, that they reset it occasionally, and to please not ask about this. The advice is to check back for link resets or follow peppy for announcements, and the stated goal is to get the game on mobile app stores so the limitation goes away.

So for an iOS user without a slot the remaining documented route is building with `osu.iOS.slnf`, and the repository treats that as a temporary condition rather than a gap. Anything unsupported or unlisted is handled with the same candour: there is still a chance you can run the release or build it manually, and the link for a version matching your device is on the osu! site.

Editorial conclusion

osu! fits a player who wants the open client and is willing to install a release alongside a stable install, or a developer who wants to build a gameplay variation on top of an existing beatmap library and game engine rather than starting one. It does not fit an iOS user without a TestFlight slot, which the README says fills to Apple's hard limit of 10,000 and is reset only occasionally, or a developer opening `osu.sln` on a machine without the mobile workloads. Before adopting, check three things: which release channel you want, since the newest tag is `2026.1026.0-tachyon` while the README still describes lazer as the current codename, whether you can satisfy the sibling checkout layout that `UseLocalFramework.sh` and `UseLocalResources.sh` assume for framework and resources work, and that any performance number you take locally is collected with `-c Release`.

Frequently asked questions

Official sources

1. License: MIT
2. ppy/osu on GitHub
3. Project website
4. README
5. Releases