muguet runs the WebAssembly build of GTA V as a native Mac app

It throws away the browser layer and keeps the wasm

The mechanism is stated in two sentences in the project documentation and it is the whole design. The port relies on the WebAssembly compilation of the game, which in a browser runs inside the JavaScript engine behind WebGPU, Web Audio and web workers. Muguet removes that layer and runs the same game.wasm as a regular native application, with wasmtime for the code and wgpu on Metal for the graphics. The audience is therefore narrower than it first appears. This is not a reimplementation of the game in Rust, and the Rust in the repository is the host, not the game. It is for people who want the WebAssembly build to feel like a normal Mac or iOS application, with a native window, Metal graphics and local multiplayer, rather than running inside a browser tab with all the constraints that implies. The project also notes that the source it targets is essentially the same as the web port, which tells you the fidelity ceiling is set by that build, not by the porting work.

JIT on macOS, compiled ahead of time on iOS

The difference between the two platforms is decided by one practical constraint, and the documentation is direct about it. On macOS, the game code is compiled to native arm64 the first time you launch it and then cached. On iOS, that cannot be done properly, and the stated reason is that the author does not want users to deal with the hassle of enabling JIT, so on iOS the game code is compiled when you build the app and baked into it. The Cargo manifest makes the same split visible in code. The jit feature is a default feature, and it pulls in wasmtime's cranelift compiler, parallel compilation, and the wasmparser and wasm-encoder crates, which is the toolchain that turns the wasm into native code at run time. The dependency list also shows how the rest is assembled: wgpu 30 for the graphics, winit for the window and input, cpal for audio, a static audiopus_sys build for the Opus codec, objc2 with the Foundation, CoreFoundation and GameController bindings for the platform layer, pollster for blocking on GPU work, zip for reading the game archive, and bcdec_rs for decoding block compressed textures. A patch section points wgpu-core and winit at vendored copies in the vendor/ directory, which tells you those two were forked to make this work.

You supply the game files, and that is the legal position

The project handles the copyright question by not touching it. Because the author cares about not being sued, you need your own copy of the game, provided as a zip of the folder holding data/ and b/<build>/ with game.wasm and the shaders/ inside. The project then asks you for that zip. No game content is bundled, no keys are extracted, no protection is bypassed, and nothing in the repository is a substitute for owning the game. That distinction matters if you are reading about the project, and it is also the reason the artefact is a personal build rather than a distributed binary. The repository layout matches this story, with a build.rs, a src/ directory, a launcher/ directory, an ios/ directory, a vendor/ directory for the patched graphics and windowing crates, and two shell scripts at the root for producing the Mac and iOS outputs. The licence on the code is GPL-3.0-or-later, and the package metadata names the author and version 0.1.0, matching the single 0.1 release published on 2026-10-10.

The one-line install hides a real toolchain requirement

The easy path is a single command you paste into a terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/c22dev/muguet/main/build.sh)"

That downloads Muguet into /tmp/muguet, installs what is missing such as Homebrew and Rust, then asks whether you want the Mac or the iOS version and walks you through the rest, ending with the .app or the .ipa in ~/Downloads/muguetOutput. If you already have the repository, you can double-click build.command or run ./build.sh. The requirements behind that one line are not trivial. You need an Apple silicon Mac running macOS 14 or later, a Rust toolchain, and Xcode 26 or later from the App Store. For iOS you also need rustup with the 1.98.1 toolchain installed and the aarch64-apple-ios target added for that toolchain, xcodegen, which the documentation installs with brew, an Apple developer account where a free one works, and a device on iOS 15 or later with ideally 8 GB of RAM. The build scripts are also available directly, with the Mac one producing build/Muguet.app:

./make-app.sh

and the iOS one taking your team identifier and the game archive:

TEAM=<your team id> ./make-ios.sh game.zip --install

Passing --ipa produces build/Muguet.ipa instead of installing directly, and with a free account you add FREE=1 along with a BUNDLE_ID of your own.

Multiplayer is one host and a UDP port

The multiplayer layer is deliberately modest, and the documentation describes it in one sentence. On top of the port, Muguet adds a small UDP multiplayer for other people who have the same port to play with you. One player hosts from the launcher, or runs the muguet-server binary on any machine, and the others join with that address, on UDP port 47520. The reason it is small is that one host anchors each session, whether that host is a player in the launcher or a muguet-server process on any machine, and everyone else connects to that address. The project also states that the app should be installed with AltStore, and warns that this probably will not work well with Sideloadly, or even SideStore, referencing an issue in the SideStore tracker. That is an honest and specific warning rather than a vague one, and it matters because sideloading tools differ in how they handle the entitlements the next section covers. The app also works with a paid developer account, which removes that particular variable for anyone who has one.

Two limitations decide whether this works for you

The limitations section is short and both items are hard blockers for particular users. The first is that iOS needs the increased memory limit entitlement, which is the one that trips people up at the last step of an otherwise successful build. The entitlement is not a normal App Store entitlement, which is part of why the project directs iOS users to AltStore rather than the standard sideloading tools, and it is why a free account with your own BUNDLE_ID is called out in the iOS build instructions. The second is that story missions are single player only, so the multiplayer layer is for free roam and the parts of the game that do not depend on mission scripts. There is also a performance floor, in that the recommended device has ideally 8 GB of RAM, and a hardware floor, since the macOS target is an Apple silicon Mac on macOS 14 or later and the graphics path is Metal through wgpu. The project credits a number of contributors for specific fixes, among them a heap corruption and a GPU memory leak fix, faster rendering, ASTC textures, native Opus audio, gamepad flight controls and graphics presets on Mac, decoding of block compressed textures on all cores, a minimap fix, controller input release when the app loses focus, and importing your own saves. That list is a good proxy for how much of the work is in the porting rather than the packaging.

Editorial conclusion

Adopt muguet if you own the game files and want the WebAssembly build running natively on Apple silicon with Metal graphics and a local multiplayer session, and you are prepared to build from source on a Mac with Xcode 26. Do not adopt it expecting story missions to work in multiplayer or expecting the iOS build to be straightforward, since iOS needs an increased memory limit entitlement and AltStore rather than the other sideloading tools. Before you start, confirm you have a copy of the game whose data folder and b/<build>/ folder you can zip, check that your Mac is on macOS 14 or later, and read the entitlements requirement rather than discovering it at the install step.

Frequently asked questions

Official sources

1. c22dev/muguet on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases