Flux: a Rust re-creation of the macOS Drift screensaver

A reconstruction, not a port

The project describes itself as an open-source tribute to the macOS Drift screensaver, and the backstory explains why those words are careful. The author has been enamoured with the Drift screensaver since it came out with macOS Catalina, calls it mesmerizing, and thinks it might stand to dethrone the venerable Flurry screensaver. The stated aim is to capture that magic and bottle it up in a more portable vessel. But this is not a port, and the reason given is direct: the source code for the original is locked up in a spaceship somewhere in Cupertino. The framing instead is a delicate blend of detective work and artistic liberty. That distinction matters for anyone evaluating it, because a tribute is judged on whether it evokes the original rather than whether it matches it. The one piece of feedback quoted in the README, from an anonymous Apple employee, is in that spirit, praising the effort while noting one or two small elements of the original are missing.

Four colour schemes and a web demo you can open now

The project is usable before you build anything, because there is a browser build and a live demo. The README links to launching it in the browser alongside a link to buy a screensaver for Windows, the phrasing being that letting your PC idle with style supports development, and alongside a recording video and the author's account on X. The samples section shows renders in each of the four default colour schemes: Original, Plasma, Poolside and Freedom, plus a single image with all four side by side. That the Original scheme exists alongside three others is the design decision in miniature. A tribute that only reproduced the one look would be a copy, while a tribute with a palette of its own is a piece of software that can stand on its own, and the freedom to recolour the fluid is also what makes it usable as a screensaver rather than as a demo.

One Rust workspace, three build targets

The Cargo manifest shows a workspace with six members and a shared dependency set, which is how the three delivery targets are organised. The members are flux, flux-desktop, flux-wasm, and three sub-crates under a flux-gl directory: flux, flux-desktop and flux-wasm. The names give away the layering. flux is the core, and the desktop and wasm crates are the shells around it, while flux-gl holds the OpenGL-specific variants of the same three. So the simulation core is written once and rendered three ways, which is what makes the browser demo and the native application behave the same. The graphics stack is chosen per target: wgpu at version 30 for the modern path, and glow with glutin and glutin-winit for the OpenGL path, with winit as the windowing library at version 0.30. The manifest also carries glam for the maths, rand and rand_pcg for the randomness, half for 16-bit float support, bytemuck for casting buffers, and tokio with the full feature set for the async runtime.

WebAssembly is the primary target, not an afterthought

The wasm32 section of the manifest is unusually substantial, and it explains why the web demo exists at all. It pulls in wasm-bindgen pinned to a version that matches the Nix version, along with wasm-bindgen-futures, web-sys, js-sys, gloo-utils with the serde feature, console_error_panic_hook so a panic in Rust produces something readable in the browser console, and console_log for the same reason on the logging side. getrandom is included with the wasm_js feature, which is the standard way to get randomness when there is no operating system entropy source. The build requirements make it explicit that rustc with the wasm32-unknown-unknown target is needed, along with wasm-pack, cargo, node, pnpm and elm. The presence of elm is the surprising entry: the web front end is written in Elm, so the project is Rust for the simulation and Elm for the interface, with the Rust compiled to WebAssembly and called from the Elm code.

Building with Nix is one command

The repository ships a flake.nix, a flake.lock and a flake-module.nix, so the whole toolchain is reproducible. With Nix, a new release is built into the result folder with a single command.

nix build

For development, the development shell opens with all the necessary tools.

nix develop

cd web
pnpm serve

That is the fast path for anyone on a machine with Nix: no need to install rustc, wasm-pack, node, pnpm and elm separately, because the flake brings them. The presence of a .envrc at the repository root suggests direnv is also supported, so entering the directory can load the environment automatically.

The manual build and the web development loop

Without Nix, the README lists what you need to install: rustc with wasm32-unknown-unknown as a target, cargo, wasm-pack, node, pnpm and elm, and it notes that how you get them depends on your operating system. The example for macOS and Linux uses rustup, installing the stable toolchain and then adding the wasm target.

rustup toolchain install stable
rustup target wasm32-unknown-unknown

cd web
pnpm install

The web directory is where the front end lives and it is driven by pnpm. A development server runs from that folder with pnpm serve, and a release build with pnpm build. So the loop is: install the Rust toolchain and the wasm target, install the JavaScript dependencies in the web folder, serve it for development or build it for release. The webgl topic tag on the repository matches the OpenGL path in the manifest, and the screensaver tag matches what the finished artefact does.

Release profile tuned for a small binary

The release profile in the manifest is where a project reveals what it values. codegen-units is set to 1, with a comment saying this allows further optimisations by disabling parallel compilation. Link-time optimisations are enabled. The optimisation level is s, for size, with the comment optimise for size. Panic is set to abort, with the comment stripping expensive panic unwinding code. There is one exception with its own comment: the dev profile for the image crate is set to opt-level 3 because the unoptimised build is too slow, which makes sense for a crate that does image decoding inside a hot path. The workspace package version is 7.2.1, with edition 2021, the MIT licence and the author recorded as Sander Melnikov. The repository itself has no GitHub releases, so the version lives in the manifest rather than in a tag, and the last push was on 2026-09-06.

Where Flux is the wrong choice

Four limits apply. It is a screensaver and a demonstration of a fluid simulation, not a general graphics engine, so if you need a renderer for an application, this codebase is a starting point rather than a foundation. It is a visual reproduction, so it will never be pixel-identical to the original, and the quoted feedback from an Apple employee says as much. Its primary target is the browser, so the WebAssembly build is the best-supported path and the native desktop build has to be built from source; there is no packaged installer in the repository, though a paid Windows screensaver is sold through a store link in the README, which is how the author funds the work. And there is a licensing asymmetry to check before you build on it: the code is MIT, but reproducing Apple's screensaver may raise trademark questions that the MIT licence cannot settle for you. The project ships a LICENSE file and credits the logo gopher as modified from a source by another artist.

Editorial conclusion

Use Flux if you want the Drift screensaver on a machine that does not run macOS, or if you want to read a fluid simulation written in Rust that renders through WebGL, wgpu and WebAssembly from one shared core. Do not treat it as a pixel-exact reproduction, because the author describes the work as detective work plus artistic liberty, and one element of the original is not reproduced. Verify first that the version you take matches the target you need, since the workspace version is 7.2.1 while the repository has no tagged GitHub releases, and that the build toolchain is present, because a manual build needs a Rust toolchain with the wasm32-unknown-unknown target, wasm-pack, node, pnpm and elm.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. sandydoo/flux on GitHub