iso2god-next v1.1.1: First Look at the New GTK4 GUI for iso2god-rs
News — 23 October 2026. A new graphical successor to iso2god-rs appeared this week: iso2god-next, by georgewoodall82 on GitHub, released v1.1.1 on 22 October 2026 — one day after the project was created. It wraps the proven rs conversion engine in a GTK4 desktop app, adds conversion of extracted game folders and FTP upload, and ships builds for Linux, macOS and Windows. This first look covers what it does, what its own author says is untested, and our verdict: promising, worth trying on Linux, and not yet the default recommendation on this site.
Nothing here changes our main downloads: the mature tools linked from our download page remain the recommended routes. This page is a dated news report on a two-day-old project, and we label it that way deliberately.
What iso2god-next is
iso2god-next is a fork of iliazeus’s iso2god-rs, the MIT-licensed Rust command-line converter. Where upstream rs is deliberately minimal — one binary, ISO in, GOD package out — iso2god-next aims to be the full desktop workflow the Windows GUI offered in 2010, rebuilt on the modern engine. It is published under the MIT licence, like its parent project, and its release announcement was posted on GBAtemp alongside the GitHub release.
The project timeline matters for how much trust to place in it. The repository was created on 21 October 2026. Version 1.1.0 was announced on 22 October 2026, and v1.1.1 — the current release at the time of writing — followed the same day. Software this young can be excellent, but it has not yet met the range of images, systems and edge cases that years of use have thrown at iso2god-rs and the classic Windows GUI.
What is new compared with iso2god-rs
| Capability | iso2god-rs (upstream) | iso2god-next v1.1.1 |
|---|---|---|
| Graphical interface | No — command line only | Yes — GTK4 / libadwaita desktop app, plus a CLI |
| Queue | One conversion per command | Queue with drag-and-drop |
| Extracted folder input | No — ISO files only | Yes — folders containing default.xex (360) or default.xbe (original Xbox) |
| FTP upload | No | Yes — to Aurora, Freestyle Dash, XeXMenu or any FTP server |
| Parallel part-writing | Thread option (-j) | Yes — parallel part-writing during conversion |
| Trimming | –trim (end of image) | End-trimming included |
| Title lookup | Built-in title database | Built-in title lookup |
| Platforms in the release | Linux / macOS / Windows binaries | Linux AppImages, macOS DMGs, Windows zip |
Two additions stand out. Folder input removes a whole step for anyone whose library is already extracted — upstream rs simply cannot accept a default.xex folder. And built-in FTP upload to Aurora, Freestyle Dash or XeXMenu restores a workflow that previously existed only in the classic Windows GUI, saving the manual copy step after every conversion.
Downloads in the v1.1.1 release
The release ships five assets. We downloaded and hashed the Linux x86_64 AppImage ourselves: at 37,693,944 bytes its SHA-256 (28ad8d59b7830e5b2435f0849f11a2b11968a807995f45fc5d5a82a2e7774b9e) matches the digest recorded by GitHub exactly, so that asset is verifiably the file its author published.
- Linux x86_64 AppImage — 37,693,944 bytes, SHA-256 verified by us against GitHub (above).
- Linux ARM64 AppImage — 36,895,240 bytes.
- macOS Apple Silicon DMG — 14,765,089 bytes.
- macOS Intel DMG — 16,005,037 bytes.
- Windows x86_64 zip — 29,453,068 bytes.
Get the release from the project’s GitHub page, linked via our download page alongside the established tools — and note the platform warning in the next section before choosing which build to trust with your library.
The caveat, in the project’s own framing
iso2god-next’s own release notes state that the Windows and macOS builds are produced by continuous-integration builds and have not had much testing on real machines. The Linux AppImage is presented as the supported build. We are reporting that caveat, not softening it: if you run Windows or macOS, the DMG and zip are best treated as experimental previews, and any conversion you care about should be checked — or simply done with upstream iso2god-rs, whose macOS and Windows binaries are verified on our Mac and Windows pages.
There is a second, quieter caveat: at two days old, the project has no track record for the odd cases — multi-disc titles, images that need careful padding handling, or dashboards that are picky about uploads. The classic guidance still applies whatever tool you use: Tetris – The Grand Master Ace is documented as needing Partial padding in the GUI workflow, and Wolfenstein: The New Order Disc 1 needs its padding left intact for its first conversion. A new interface does not change how the games themselves behave.
Our verdict
- On Linux: the AppImage is the one to try. It is the author’s supported build, its checksum verifies, and it finally gives Linux users a native graphical converter with folder input and FTP upload.
- On macOS and Windows: interesting to test, too early to rely on. Keep iso2god-rs (or the r4dius GUI on Windows) as your working tool.
- As a default recommendation: not yet. Defaults are earned with time, issue history and tested builds across platforms. iso2god-next has made a strong start; we will revisit this verdict as the project matures.
How a conversion looks in iso2god-next
Based on the project’s own release description, the workflow mirrors the classic GUI more than the command line does. You build a queue — by adding ISO files or extracted game folders, including by drag-and-drop — review the detected titles, and run the queue while the app writes package parts in parallel. When a conversion finishes, you can send the result straight to the console by FTP if you have configured an Aurora, Freestyle Dash or XeXMenu target, instead of copying the header file and data folder by hand. End-trimming and the built-in title lookup carry over the behaviours rs users already know, now presented in a window rather than as command flags.
That workflow is exactly why the project matters even at two days old: it is the first tool in the modern line to reunite conversion, folder input and console upload in one native application on Linux. It is also why caution is the right posture — a queue, a new interface and new upload code are precisely the parts that only real-world use can validate, and none of them had that use yet when v1.1.1 shipped.
However you convert, the console-side rule is unchanged: GOD packages from any of these tools need a modded Xbox 360 (JTAG, RGH or BadUpdate-class) or the Xenia emulator. A stock retail console will not run them.
For the established tools, see our download page, the Linux guide, which Iso2God version to use and the Platforms hub. The lineage of every project mentioned here is in the Version History.
Frequently asked questions
Is iso2god-next made by the iso2god-rs author?
No. It is a fork by georgewoodall82 of iliazeus’s iso2god-rs, published under the same MIT licence. It builds on the rs engine but is a separate, much younger project.
Should I replace iso2god-rs with iso2god-next?
Not yet. On Linux it is worth installing alongside rs and trying. On Windows and macOS its own notes say the builds are lightly tested, so keep rs or the classic GUI as your reliable converter for now.
What does iso2god-next do that iso2god-rs cannot?
Three headline things: a GTK4 graphical interface with a drag-and-drop queue, conversion directly from extracted folders containing default.xex or default.xbe, and FTP upload to Aurora, Freestyle Dash, XeXMenu or another FTP server.
When was iso2god-next released?
The project was created on 21 October 2026; v1.1.0 was announced on 22 October 2026 and the current v1.1.1 followed on 22 October 2026. This first look was written on 23 October 2026.