Route 1: the Android route, via Snes9x EX+

If your Chromebook supports Google Play and Android apps, this is the simpler route. The app is Snes9x EX+ by Robert Broglia — a separate, free Android app (not made by the Snes9x team, and historically based on Snes9x 1.55 code) that is still updated today. On a Play-enabled Chromebook, you install it from Google Play exactly as you would on an Android phone, point it at your game files, and play — with configurable touch controls if you are on a convertible, and Bluetooth or USB gamepads if you prefer physical buttons, which most people do for action games.

Caveats, stated plainly: if your Chromebook predates Play support or your school or work administrator has disabled Android apps, this route is closed to you and no setting on the emulator side will open it. Our full Snes9x on Android guide covers EX+ setup, controller pairing and storage in depth — everything there applies to the Chromebook Android container as well.

Route 2: the Linux route, via the AppImage

If your Chromebook supports Linux apps (Crostini), you can run the real desktop Snes9x. The official Linux build is an AppImage — a single self-contained executable — and our Snes9x for Linux guide covers it in full: download Snes9x-1.63-x86_64.AppImage from the official GitHub release, make it executable, and launch. That gets you the current 1.63 emulator itself — the GTK port, with its XDG-respecting config and joystick hotplugging — rather than a mobile adaptation.

The conditions are real, though. The official AppImage is an x86_64 build, so this route fits Intel and AMD Chromebooks; an ARM Chromebook’s Linux container cannot run it natively. Linux support must also be enabled on your device (and not blocked by an administrator), and performance inside the container depends on your hardware. If your Chromebook supports both routes, the Linux route gives you the newer emulator; the Android route gives you the easier setup.

Which route should you choose?

• Play Store available, want it working in five minutes: Snes9x EX+ via the Android route.
• Linux (Crostini) available on an Intel/AMD Chromebook, want current Snes9x 1.63: the AppImage via the Linux route.
• Neither Android nor Linux available (older or managed devices): there is no honest Snes9x option for that machine — be wary of any site selling you one, and consider the desktop builds on any PC or Mac you have access to instead.

Shared ground rules

Whichever route works for you: no BIOS file is needed for normal SNES games on any Snes9x variant; a Bluetooth controller beats touch controls for anything fast; and neither EX+ nor desktop Snes9x includes any games — the legal route is to dump cartridges you own. School-managed Chromebooks deserve one extra note: if your device is administered, the right move is to check what is permitted on it rather than work around the people who manage it.

For the rest of the family — including the genuinely tricky case of Snes9x on iOS — the platforms hub gives every platform the same honest treatment, and the download page links every official file.

Performance: SNES emulation is light work

Whichever route your Chromebook supports, raw power is unlikely to be your problem. Snes9x is an unusually light emulator: the official Windows readme — still shipped with the current release — recommends a 1GHz-class CPU for a “near perfect experience”, and Snes9x EX+ has long been built for 1GHz-class Android devices. Those are desktop and phone numbers from a much weaker hardware era. A Chromebook that can run Android apps or a Linux container at all is, in processor terms, comfortably past what SNES emulation asks for. The deciding factors on ChromeOS are never megahertz — they are the support questions above: does your model run Play apps, does it run Linux, and has an administrator locked either down?

Moving between routes, and keeping your saves

If you switch routes later — a new Chromebook with Linux support, say, replacing one that only had Android — your progress does not have to start over. Battery saves use the standard .srm format across the whole Snes9x family: a save created in EX+ can be carried to the desktop AppImage build, and vice versa, because both are reading and writing the same format the original games used. Cheat files (.cht) are likewise shared across Snes9x builds. What does not travel as freely are emulator-specific save states, so treat the .srm as your canonical progress and back it up — our Android guide and the download page link the cloud-sync walkthrough that automates exactly that.

One last conditional, because this page has been built on them: ChromeOS features roll out by device and over time, and a Chromebook that lacks Linux support today is unlikely to gain it later. Check your specific model’s support status in its settings before planning around either route — two minutes there beats any amount of emulator troubleshooting.

Why there is no Snes9x app for iPhone

Check the official 1.63 release assets and the answer is structural: six files — two Windows zips, a Mac zip, a Linux AppImage and two libretro zips. No iOS app, no Android APK. The Snes9x team simply does not publish mobile builds of the standalone emulator. On Android, the gap is filled by a separate developer’s app (Snes9x EX+, covered in our Android guide). On iOS, the history and the options are thinner.

The historical footnote: EX on iOS

The Snes9x name did reach iOS once. Robert Broglia — the developer behind Snes9x EX+ on Android — historically offered an iOS version within his “EX” line of emulators, back when distributing emulators on iOS was a very different landscape. That is a piece of history, not a current recommendation: the maintained, living product in that line today is the Android app. If a guide presents the old iOS EX release as a present-day solution, check its dates before trusting anything else it says.

Your realistic option: RetroArch with the Snes9x core

The practical route to Snes9x on iOS today is RetroArch’s iOS app with the Snes9x core loaded in it. As our libretro core explainer details, that core is genuine upstream Snes9x code packaged for libretro — the same emulation you get on desktop, wrapped in RetroArch’s interface. Features people associate with “RetroArch Snes9x” — its netplay system, its rewind — belong to the RetroArch frontend and are applied to the core, which is also why the experience differs from the standalone app even though the emulation underneath is the same.

What we will not do is dress this up with promises we cannot support. Specifically:

• No jailbreak promises. We do not recommend jailbreaking your phone for an emulator, and nothing here depends on it.
• No sideloading hype. Guides pushing expiring certificates, enterprise profiles or sketchy third-party app stores are asking you to trust strangers with your device. The front-door option above is the one we can stand behind.
• No invented store facts. What Apple permits in its store changes over time. If RetroArch’s availability or features on iOS differ when you check, that is the store’s current policy speaking, not something any emulator site controls.

Honest limitations of SNES on iOS

Even via RetroArch, set expectations clearly. There is no Snes9x-team app, so there is no “official” iOS experience to compare against — support questions go to the frontend’s community, not the Snes9x project. Touch controls are workable for RPGs and puzzlers and a compromise for fast action games; a Bluetooth controller improves things dramatically, as it does on Chromebooks and Android. And your games are your own responsibility: every Snes9x variant ships with zero ROMs, and the legal route is dumping cartridges you own.

If you have other hardware, use it

iOS is, frankly, the weakest seat in the Snes9x house. The strongest experiences are the maintained ones: the standalone 1.63 builds for Windows, Mac and Linux from the download page, Snes9x EX+ on Android, and actively maintained ports like Snes9x GX on Nintendo consoles. The platforms hub lays out every option with its real status — including, as here, when the honest answer is “not really, and here is why”.

Why doesn’t the Snes9x team just release an iOS app?

Two reasons, neither of them laziness. First, the Snes9x project is a desktop emulator team: its releases, its documentation and its support channels are all built around Windows, macOS and Linux, and it has never shipped a mobile app of its own on any platform — Android’s Snes9x presence exists because an outside developer, Robert Broglia, chose to build one. Second, for most of iOS’s history, emulator apps faced restrictive App Store policies, which is why the iOS emulation scene long depended on workarounds we do not recommend. Store policy has shifted over time and may shift again; the project’s own release list is the ground truth, and today it contains no iOS build. If that ever changes, it will appear in the official releases — and we will update this page.

Questions people ask about Snes9x on iOS

• “I found Snes9x in the App Store — is it real?” Not from the Snes9x project. Check the publisher name carefully; lookalikes and wrappers appear regularly, and none of them is published or endorsed by the Snes9x team.
• “Can I use the Snes9x core without RetroArch?” On iOS, the core needs a libretro frontend to run in — that is what a core is. RetroArch is the realistic frontend option; a core on its own is not an app.
• “Will my saves work?” Battery saves (.srm) are the standard format shared across SNES emulators, so progress made on desktop Snes9x can move to a core-based setup, and back.
• “Is it worth it?” If iOS is your only device, the RetroArch route is a genuine way to play. If you also own a computer or an Android device, those platforms offer the maintained, first-class Snes9x experiences — see the platforms hub.

Proof it is the real thing: it ships in the official release

You do not have to take the core’s pedigree on faith. The official Snes9x 1.63 release on GitHub ships libretro packages — libretro.zip and libretro-x64.zip — as two of its six assets, alongside the Windows, Mac and Linux builds. The libretro documentation likewise lists Snes9x as a core built from the upstream project. When RetroArch offers to download the “Snes9x” core through its core updater, you are getting that same upstream code in libretro packaging.

Core vs frontend: who does what

The libretro model splits the job in two. The core emulates the SNES: the CPU, graphics, audio and enhancement chips (SuperFX, SA-1, DSP series and the rest that Snes9x emulates in code). The frontend — RetroArch — provides everything around the emulation: the interface, video drivers and shaders, controller abstraction, and the platform features layered on top of any core it runs. Keeping that split in mind prevents the two most common confusions:

• Netplay in RetroArch is a frontend feature. RetroArch’s own netplay system works across cores, including this one — libretro’s documentation explicitly recommends the Snes9x core for netplay. Contrast that with standalone Snes9x’s built-in netplay, whose own readme carries a maintainer’s note that it “has not been maintained and tested in a long time, so it might be broken”. If online play matters to you, the RetroArch route is the maintained one.
• Rewind in RetroArch is also the frontend’s. RetroArch applies rewind to the core from outside. But do not overcorrect: standalone Snes9x has its own, separate rewind implementation (added in 1.54, hold the R key) — it is simply switched off by default, because its rewind buffer defaults to 0 until you set a size in the settings. Two different systems, same name.

Files, firmware and formats in the core

The core loads the standard Snes9x formats: .smc, .sfc, .swc, .fig, .bs and .st. Battery saves are .srm — compatible with every SNES emulator, which makes moving saves between the core and the standalone app painless — and cheats live in .cht files shared with higan/bsnes.

One topic that imports confusion from other emulators: normal SNES games need no BIOS or firmware file in Snes9x, core or standalone, because the enhancement chips are emulated in code. There are exactly two narrow exceptions, both optional add-on hardware: Sufami Turbo loading can use STBIOS.bin, and Satellaview/BS-X content uses BS-X.bin — in the libretro setup these go in RetroArch’s system folder, as the core documentation describes. If a setup guide tells you to hunt down DSP firmware dumps for Snes9x, it has confused Snes9x with bsnes/higan-style emulation; ignore it.

When the core is the right choice

Choose the RetroArch core when you want one library and one interface across many systems, when you want RetroArch’s netplay or its shader/run-ahead ecosystem, or when you are on a platform the standalone release does not cover — the core reaches places like game consoles and mobile frontends that mainline 1.63 does not ship for. Choose the standalone app when you want the emulator exactly as its own team presents it — its native menus, its own netplay and rewind systems, zero frontend between you and the settings. Our standalone vs libretro core comparison walks the trade-offs in full, and the native desktop builds are covered in our Mac and Linux guides. Either way, the code underneath is the same Snes9x — start from the download page and the platforms hub.

One core, everywhere RetroArch goes

The libretro packaging also explains how “Snes9x” appears on platforms the standalone project never targets. The upstream repository’s own build system produces the libretro core for a wide range of systems — including Android builds of the core. That is a RetroArch core for Android, not a standalone Android app (the standalone Android answer is a different product entirely, Snes9x EX+). The same logic is how the core reaches iOS frontends and games consoles: the core travels with the frontend, which is precisely the reach the standalone releases — Windows, macOS, Linux — do not attempt.

Save handling follows the same split. Your in-game battery saves are the core’s standard .srm files, portable to the standalone app and other emulators. Save states, by contrast, are managed by the frontend: RetroArch snapshots the core’s state through the libretro interface, which is also the mechanism its rewind and run-ahead features build on. Practically, this means your .srm progress is yours to move anywhere, while frontend-level states belong to the setup that created them — a distinction worth understanding before you reorganise a library.

Where Snes9xTYL comes from

The project’s own documentation spells out its unusual family tree: Snes9xTYL is based on Little John for PalmOS — specifically its SNES module — which was itself based on Snes9x 1.39. The original TYL port was written by yoyofr and Laxer3a, who adapted that PalmOS lineage to the PSP’s hardware. Version 1.39 is an old core even by port standards, which explains both of TYL’s defining traits: it is fast on very modest hardware, and its compatibility ceiling sits below what modern Snes9x 1.63 achieves on a PC.

Status: legacy and discontinued

Let us be plain: Snes9xTYL is a discontinued, legacy port. The original project finished long ago, and what circulates today are later community builds — the mecm and cm mods (worked on by esmjanus and others) that refined the final official-era code. A widely used GitHub mirror of the v0.4.2 mecm/cm mod lives at github.com/173210/snes9xTYL. These mods are the versions to use, but they are maintenance of a finished project, not active development: no new features are coming, and unfixed quirks stay unfixed.

One naming trap to avoid: Snes9xTYL is not the same thing as “Snes9x Euphoria”, a separate later PSP effort that appears in old official port listings. Guides and download pages sometimes blur the two; they are different codebases with different behaviour.

What you need: a PSP that runs homebrew

TYL is PSP homebrew. It does not run on a PSP with stock firmware through any official channel — the console needs to be running custom firmware or an equivalent homebrew enabler. Setting that up is your responsibility: it modifies how Sony’s hardware operates, sits outside Sony’s supported use, and the correct method depends on your PSP model and firmware version, so follow the PSP homebrew community’s current guidance for your exact device. Once homebrew runs, installing TYL is a matter of copying the build to your memory stick like any other homebrew app.

Setting expectations: what plays well

The PSP is early-2000s handheld hardware, and TYL’s 1.39-based core was tuned for it. The realistic picture:

• Most standard SNES games — the platformers, RPGs and shooters without special chips — are the port’s home turf and the reason it stayed popular for years.
• Enhancement-chip games (SuperFX, SA-1 and friends) are the demanding end of the library on any emulator of this vintage; expect to lean on the emulator’s speed-oriented settings, and accept that some titles will not reach full speed.
• Edge cases exist. A 1.39-era core predates many accuracy fixes. Even the modern mainline readme lists a handful of titles no Snes9x version runs (the DSP-3 and Seta-11/18 games); a legacy port inherits a longer list than the desktop build.

Judged as what it is — a free community port that put a SNES in PSP owners’ pockets — it remains a genuinely good piece of software. Judged against a current desktop emulator, it is a museum piece that still works. Both things are true.

Games, and the rest of the family

Snes9xTYL ships with no games, and this site provides none — dump cartridges you own and play those copies. If your handheld loyalties run Nintendo instead, our Snes9x for 3DS guide covers bubble2k16’s port, and for the TV there is Snes9x GX on Wii, GameCube and Wii U, the one console port still actively maintained. The platforms hub maps the whole family.

Getting the most out of a legacy port

Because development has ended, the community’s accumulated knowledge is the support channel. A few principles, learned the hard way by PSP owners over many years, are worth stating for newcomers:

• Use the mecm/cm mod builds rather than the oldest official-era releases — they represent the most refined state the code reached, and they are what surviving mirrors and collections carry.
• Expect to tune settings per game. Emulators of this vintage expose speed-oriented options because the hardware needs them; a setting that makes one game perfect may be wrong for the next. Time spent in the options menu is part of the experience, not a sign something is broken.
• Start with non-chip games. The standard library is where TYL shines. Treat enhancement-chip titles as experiments, and you will rarely be disappointed.
• Keep your own copies of everything. Legacy homebrew disappears from the internet regularly. The build, your settings and your saves are worth a backup folder on a PC.

Finally, a word on why TYL still gets recommended at all when newer devices exist: the PSP itself. Its screen, controls and form factor suit SNES games remarkably well, it is cheap and plentiful second-hand, and its homebrew scene was one of the most productive in handheld history. Snes9xTYL was that scene’s SNES answer, and on the hardware it was built for, it remains a coherent, finished piece of software — old, honestly limited, and still entirely usable.

What it is built on: Snes9x 1.43

Unlike ports that leave their pedigree vague, this one’s readme states it plainly: it uses Snes9x 1.43 as its base. Version 1.43 is an old core — far older than the current desktop Snes9x 1.63 — and that choice was deliberate. The 1.43-era core is light enough to run well on the 3DS’s modest processor, and bubble2k16 optimised the port around that hardware. The trade-off is that you do not get two decades of later accuracy fixes and edge-case work; what you get is speed on hardware that has no right to emulate a SNES this well.

Status: effectively unmaintained — know this first

The last release of Snes9x for 3DS was v1.30, in March 2018, and the project repository has been quiet since 2019. The honest description is effectively unmaintained: it still works, and the final release is stable for what it is, but nobody is fixing bugs or adding features. Download it from the project’s own GitHub releases (github.com/bubble2k16/snes9x_3ds), treat v1.30 as the final word, and do not expect support if something misbehaves on newer system software.

What it plays, and how well

The port’s headline strength, verified across its release history and community use: games that don’t use special enhancement chips run at full speed even on an Old 3DS (the original 3DS / 3DS XL / 2DS models). That covers the majority of the SNES library — the platformers, RPGs and puzzlers most people revisit.

The exceptions are the famous chip games. Titles built on the SuperFX or SA-1 chips are slow on an Old 3DS — playable in some cases, but not at the full speed the rest of the library achieves. On a New 3DS model, with its faster processor, those same chip games run faster and are a much better experience. So the short version:

• Old 3DS / 2DS: full speed for non-chip games; SuperFX and SA-1 titles will struggle.
• New 3DS: the same library, with noticeably better performance on SuperFX and SA-1 games.

Keep in mind what the base core means for compatibility generally: a 1.43-based port will not match desktop Snes9x 1.63 on the hardest edge cases, and the mainline readme documents a small set of titles (using chips like DSP-3 and Seta-11/18) that no Snes9x version runs. For a handheld of this era, though, the practical hit rate is high.

What you need before installing

Snes9x for 3DS is homebrew software: it runs on consoles set up for homebrew, not through the Nintendo eShop or any official channel. Preparing a 3DS for homebrew is your responsibility — it sits outside Nintendo’s supported use of the console, and the methods belong to the 3DS homebrew community’s own guides, which you should follow for your exact model and system version. The port ships with no games; the legal route is to play dumps of cartridges you own.

How it compares to the other ports

Within the Snes9x family, this port sits at the “clever and finished” end: an old core, heavily tuned, now frozen in time. For consoles on the TV, Snes9x GX covers Wii, GameCube and Wii U and is still actively maintained. For Sony’s handheld, Snes9xTYL on PSP is an even older legacy port. And if you want the current, maintained emulator instead, the desktop builds linked from the download page and the platforms hub are where to start.

Understanding the chip problem

To see why the performance split lands where it does, it helps to know what “chip games” means. The original SNES cartridge format let publishers put extra processors inside the cartridge itself. The SuperFX chip was a co-processor that handled 3D and fast graphics routines; the SA-1 packed what amounts to a second, faster CPU alongside the console’s own. An emulator has to emulate those chips as well as the base console, in real time, on whatever hardware it is running on. Modern Snes9x handles a long list of them — SuperFX, SA-1, the DSP series, C4, S-DD1, SPC7110 and more — but on the Old 3DS’s modest processor, the heaviest chips are simply where the budget runs out. The New 3DS’s extra power is exactly what those games were waiting for.

Practical advice follows from that: on an Old 3DS, build your playlist from the enormous non-chip majority of the library and you will have a full-speed handheld SNES. Save the SuperFX and SA-1 showcases for a New 3DS, or for the desktop emulator, where they are effortless. Choosing the right games for the hardware is not a compromise unique to this port — it is how emulation on fixed, low-power devices has always worked.

What Snes9x GX is

Snes9x GX takes the Snes9x emulation core and wraps it in an interface built for Nintendo consoles and their controllers. It has a long lineage — the project passed through several maintainers (SoftDev, crunchy2, michniewski and Tantric among them) before dborth, and it has been continuously tended ever since, with the current line in the 5.0.x series. Releases are published on the project’s own GitHub repository, github.com/dborth/snes9xgx.

One question comes up constantly, so here is the honest answer: there is no single “based on Snes9x version X” for the current GX build. Older references pin various historical GX releases to Snes9x 1.51, 1.53, 1.56 or 1.60, but the current repository continuously merges and backports upstream fixes rather than sitting on one frozen core version. Any site that prints a neat base version for today’s build is guessing — we won’t.

Licence: a genuinely GPL port

Snes9x GX is unusual in the Snes9x family: its own README describes it as GPL-licensed. That is a real difference from mainline Snes9x, which is freeware for personal, non-commercial use only — publicly available source, but not GPL and not OSI open source. If licence terms matter to your project (a preloaded retro console build, for example), GX and the desktop emulator are not interchangeable on paper even though they share emulation DNA.

The requirement nobody should skip: a homebrew-capable console

Snes9x GX is homebrew software. It does not run on a stock Wii, GameCube or Wii U through any official channel, and Nintendo does not offer it in any store. To use it, your console must already be set up to run homebrew software. Preparing a console for homebrew means modifying how it operates, and that part is entirely on you:

• Modifying your console is your responsibility. It can void warranties and, done carelessly, can damage the console. We do not provide console-modding instructions here.
• The process differs per console (Wii, GameCube and Wii U each have their own homebrew scene and tooling), so follow the established guides for your specific hardware from the homebrew community.
• Once a console is homebrew-capable, installing Snes9x GX itself is the easy part — releases come from the project’s GitHub page linked above.

If that sounds like more commitment than you wanted, the same games run with zero console surgery on a PC or Mac via the mainline builds — see the download page — or on original-era handheld hardware covered by our other port guides.

Which console does what

The same GX project covers three machines. On the Wii it is the classic homebrew SNES option, played with the console’s own controllers. The GameCube build serves the earlier hardware, and on Wii U the port runs within that console’s Wii-compatible homebrew environment. In all three cases you are running a community port on modified console software — expect a homebrew experience, not a polished commercial product, and keep backups of anything on the console you care about.

Games and legality

Snes9x GX, like every Snes9x variant, ships with no games, and this site provides none. The legal route is to dump cartridges you own and play those copies. The emulator itself is free; the games are your responsibility.

Other console and handheld ports

GX is one branch of a whole family of community ports. Nintendo handheld fans should read our Snes9x for 3DS guide, and Sony handheld owners our page on Snes9xTYL for PSP — both come with honest status notes, because unlike GX those ports are no longer maintained. The platforms hub ties all of them together.

A port with a documented history

GX is not a recent experiment. The Snes9x project’s own (now very dated) official ports document, last updated in 2011, already listed Snes9x GX — under its then-maintainer Tantric — alongside the other recognised ports of the era. Few console emulators have been carried forward across three console generations by a relay of maintainers the way GX has, and that continuity is a large part of why it remains the default answer for SNES on Nintendo hardware: the project outlived the consoles it targets, and its current maintainer still publishes releases.

Your game progress is not trapped on the console, either. Snes9x’s file compatibility is a family trait: battery saves in the standard .srm format are readable by other SNES emulators, and cheat files in the .cht format are shared with higan/bsnes. A library built up on the Wii can therefore move to a PC build of Snes9x later — which matters for a port running on ageing hardware, and is one more argument for keeping your own backups of saves you care about.

Getting the official AppImage

The Linux asset in the 1.63 release is Snes9x-1.63-x86_64.AppImage, published alongside the Windows zips, the Mac zip and the libretro core packages on the GitHub releases page of snes9xgit/snes9x — the project’s only current official download channel. The historic snes9x.com site is frozen and hosts no current builds. Our direct link to the official file: download Snes9x 1.63 AppImage from the official GitHub release.

An AppImage is a single executable bundle, so setup is short:

1. Download Snes9x-1.63-x86_64.AppImage.
2. Make it executable — right-click → Properties → Permissions → “Allow executing file as program”, or run chmod +x Snes9x-1.63-x86_64.AppImage in a terminal.
3. Launch it, then open a game from the File menu.

As the filename says, this build targets x86_64 machines. There is no official ARM AppImage in the 1.63 release, so Raspberry Pi and other ARM Linux users are better served by the libretro core route described in our RetroArch core explainer. Snes9x also provides no games: dump cartridges you own. No BIOS file is needed for normal SNES games — the enhancement chips are emulated in code.

The GTK port and where your config lives

The Linux interface is the project’s GTK port — the same port family that received several of the headline features of recent releases. A detail worth knowing if you manage dotfiles or sync settings between machines: in 1.63, the GTK port’s config file location was fixed to obey the $XDG_CONFIG_HOME environment variable. If you set XDG paths, Snes9x now respects them instead of insisting on its own default location; if you have never heard of XDG, nothing changes for you — the defaults just work.

The GTK port also carries the platform’s shader story: slang shader support reached the GTK OpenGL output in the 1.59 era, and the Vulkan output added in 1.62 can use slang shaders as well. If you are coming from the Mac app, our Snes9x for Mac guide covers the other native desktop build.

Controller hotplugging: where Linux beats Windows

Here is an honest platform difference most guides get backwards. Since version 1.61, the GTK port supports hotplugging joysticks — connect a controller mid-session and the emulator sees it. The Windows port is the opposite: Windows hotplugging was disabled back in 1.56 in favour of a menu option to reconfigure joysticks, and no later release re-enabled it. So on Linux you can plug a pad in whenever you like; on Windows, plug in before launching or use the Input menu afterwards. Neither behaviour is a bug — but knowing which one your platform has saves a confused half hour.

Saves, states and cheats

The emulation core is shared across platforms, so the file model is the familiar one: battery saves as .srm files (written by the game’s own save feature), save states for instant snapshots, and cheats — Game Genie, Pro Action Replay and raw codes — stored in .cht files that are also compatible with higan/bsnes. ROMs open in the usual formats (.smc, .sfc and other copier formats), including a single ROM inside a .zip, .gz or .jma archive.

Running Snes9x on a Chromebook or other constrained Linux setups

Because the AppImage needs no installation, it is also the build to try inside Linux containers and other restricted environments where you cannot add system packages. Chromebook owners in particular should read our Snes9x on a Chromebook guide, which weighs this Linux route against the Android app route and explains which Chromebooks can use each. Whatever route you pick, start from the download page or the platforms hub so you are always getting the official 1.63 files.

What recent releases brought to the GTK port

The GTK port has quietly collected several of the most user-visible improvements of the last few release cycles. The 1.55-era GTK work added the tenth save slot; in 1.56.2 the GTK and Unix builds learned to preserve the current joypad state when rewinding, so stepping back in time did not scramble your inputs; 1.61 added the joystick hotplugging described above; and 1.62 improved Wayland support, including handling fractional DPI properly, alongside the new Vulkan output method, which can use libretro’s slang shaders just as the OpenGL output has since 1.59. Version 1.63’s contribution was smaller — the XDG config fix — but it is the kind of detail Linux users actually notice, because it determines whether the emulator respects the directory layout the rest of your system already uses.

The pattern is worth naming: on Windows, recent Snes9x releases have mostly been about stability, while the GTK port kept gaining platform behaviour. If you run both, do not assume the two builds behave identically — check which port a piece of advice was written for before following it, especially anything about controllers, config files or display scaling.

One download for Intel and Apple Silicon

The Mac build of Snes9x 1.63, distributed as Snes9x-1.63-Mac.zip, is a Universal Binary: we inspected the official release file directly, and both the app and its bundled framework contain two architectures, x86_64 and arm64. That means the same app runs natively on an Intel Mac and on an M1, M2, M3 or later Apple Silicon Mac — there is no separate “Apple Silicon version” to hunt for, and no Rosetta translation layer is involved on modern machines.

The minimum system version recorded in the app itself is macOS 10.12, so the honest requirement is simply “macOS 10.12 or later”. Any site claiming the Mac build needs macOS 11 or newer is adding a restriction the binary does not have. Snes9x is freeware for personal, non-commercial use — its source code is publicly available, but it is not GPL and not OSI open source, on macOS just as on Windows.

Where to download the Mac build

The only current official download channel for Snes9x is the GitHub releases page of the snes9xgit/snes9x project. The project’s historic homepage, snes9x.com, is frozen — its news stops in 2006 and its downloads page offers no binaries at all, only links to old mirror sites. Anyone sending you to snes9x.com for “the latest Mac version” is sending you somewhere that cannot provide it.

Our direct link to the official file is here: download Snes9x 1.63 for Mac from the official GitHub release. The same release also carries the Windows builds, the Linux AppImage and the libretro core packages, so it is the one address worth bookmarking.

Installing Snes9x on macOS

• Download Snes9x-1.63-Mac.zip from the official release (link above).
• Double-click the ZIP in Finder to extract it — you get a single Snes9x.app.
• Drag Snes9x.app into your Applications folder.
• Launch it from Applications or Launchpad, then use the File menu to open a game.

There is no installer and nothing else to add: no BIOS file is required for normal SNES games, because Snes9x emulates the enhancement chips in code rather than loading firmware dumps. If macOS refuses to open the app or it closes immediately, work through our dedicated guide to Snes9x not opening on Mac before re-downloading — the cause is usually on the macOS side, not a corrupt emulator.

What the current Mac port is — and what 1.63 changed

Today’s Mac app is not the ageing port long-time users may remember. In version 1.61 the Mac port was completely rewritten by Michael Donald Buckley, rebuilt on newer, supported macOS APIs. That rewrite is the foundation of the current app, which is why the modern build behaves like a normal contemporary Mac application on both Intel and Apple Silicon hardware.

Version 1.63 itself was mainly a bug-fix release across all platforms. Its Mac-specific changes were modest: a new cheat finder, MultiCart support restored, and a fix for a blank window appearing on launch. If you are updating from 1.61 or 1.62, expect stability rather than a feature overhaul — and if you skipped the 1.61 rewrite entirely, the app will feel noticeably more modern than the port it replaced.

Games, saves and cheats on the Mac build

The Mac app registers the ROM types .sfc, .smc, .swc, .fig and .gd3, plus .jma archives, so the cartridge dumps you already use on other platforms open here unchanged. Snes9x ships with no games, and this site provides none — the legal route is to dump cartridges you own.

Cheat support follows the core’s standard model: Game Genie and Pro Action Replay codes plus raw address/value entries, stored in .cht files that are shared with higan/bsnes and loaded automatically when the same game starts again. The new cheat finder added in 1.63 lets you search memory for changing values — lives, health, currency — and turn the results into codes of your own, which is the easiest way to build cheats for games that never had published codes.

Mac, Linux or RetroArch — which route?

If you are on a Mac, the native app above is the straightforward choice: one download, both CPU architectures, no frontend to configure. Mac users dual-booting or running Linux alongside may also want our Snes9x for Linux guide, which covers the official AppImage build. And if you prefer a unified library across many systems, the same upstream code is available as a libretro core — our explainer on the Snes9x core in RetroArch covers how that differs from the standalone apps. Either way, start from the platforms hub and the download page so every file comes from the official release.

Updating, and moving saves between platforms

Updating is manual and simple: when a new release appears on the GitHub releases page, download the new Mac zip and replace the old Snes9x.app. There is no built-in updater and no Mac App Store listing — if a store page or third-party “updater” offers you Snes9x, it is not the project’s.

Your progress travels well. Snes9x’s file formats are deliberately compatible across the family: battery saves (.srm) are the standard format every SNES emulator reads, freeze/save-state files follow the documented snapshot format, and cheat files (.cht) are shared with higan and bsnes. In practice that means a game started on a Mac can continue on the Windows build or the Linux AppImage with the same .srm file — one more reason to keep your saves backed up somewhere other than a single laptop, as covered in our save-sync guide on the platforms hub.