Switch Homebrew and Catalog Game Dumps
Community-built apps and retail game dumps travel in different file types and answer different questions. This page keeps the two apart.
What the term covers
Switch homebrew means software written for the console by people outside the licensed pipeline: media players, file managers, save editors, emulators for older systems, small games, benchmarking oddities. The defining trait is authorship, not legality — a hobbyist wrote it, usually published the source, and shipped a build for anyone who wants it.
These builds are almost always NRO files. An NRO is a single relocatable executable produced by the open development toolchain the scene maintains, and it stands alone. There is no manifest listing sibling files, no title ID assigned by a publisher, no version record for the system to compare against. The whole program is one file you can copy onto storage and read with a plain file manager.
Projects live wherever their authors put them: a repository, a release page, a community index. Some are years stale, some see commits weekly, and quality ranges from polished to abandoned experiment. That churn is normal for volunteer work and is worth expecting.
What this catalog indexes instead
Everything indexed here is a retail game dump in one of two container formats. Those are structured packages: a wrapper, a set of content archives, and a metadata record stating the title ID, the title version, and the system level the title expects. They exist because someone read a title they own and wrote it out as files.
None of that describes a community app. A dump is a copy of published content; an NRO is original work by its author. They are stored differently, verified differently, and obtained from different places. If you want the internals of the package side, the NSP container in detail takes it apart, and the format trade-off is at Read NSP versus XCI.
The two file families side by side
The table below is deliberately narrow. It compares what the files are, not what you can do with them.
| Property | NRO | NSP or XCI |
|---|---|---|
| Author | Hobbyist or small team | Commercial publisher |
| Shape | One executable file | Container holding content archives |
| Title ID | None assigned | Sixteen hex digits in the metadata |
| Source code | Usually published | Never published |
| Listed here | No | Yes |
Read down the Title ID row and the split becomes obvious. A retail package carries an identifier because a distribution system needed to track it. Community software never entered that system, so there is nothing to track and no field to fill.
Why the two threads keep tangling
Three habits do most of the damage. Vocabulary is the first: the scene calls everything a build, so a media player and a game copy get the same noun. Storage is the second — both end up on the same removable card, in adjacent folders, and a folder listing flattens the distinction. Search behavior is the third, since the same person often asks both questions in one session and search engines learn to serve one answer to both.
Practical consequence: when a guide mixes them, its file paths stop making sense. A page telling you to drop a package into the folder where standalone executables belong has confused the two, and following it produces a file the system never looks at. Checking which family a file belongs to before you copy it saves the confusion.
What this site does not publish
There are no console modification guides here. No bypass instructions, no signature discussion, no shop configuration, no walkthrough for getting third-party code running on retail hardware. That is a deliberate boundary rather than an oversight: this index documents file formats and catalog fields, and the modification side is amply covered by communities that maintain it properly.
What is in scope: what a container holds, what a row in a listing claims, and how to tell a good match from a bad one. Start with how to read an NSP listing, then use Open the catalog to look at real rows. If something in a listing looks wrong, Report an issue.