ZapFast: a native WhatsApp client in Rust and egui

What ZapFast replaces, and for whom

WhatsApp on the desktop usually means one of two things: a browser tab running the web client, or the official Electron app. Both carry a Chromium runtime. The README states that in the project's Linux test, ZapFast opened in under a second and used about 150 MB of idle RAM, against 1.13 GB for WhatsApp Web and its Chromium processes, with a link to the measurements at zapfast.rocks/benchmarks/. That comparison is the project's own, on its own hardware, and the README does not describe the methodology, so treat the numbers as a claim to verify rather than a settled result.

The audience is narrower than "everyone who uses WhatsApp on a PC". ZapFast is for people who keep a chat window open beside their editor or terminal all day, who care about idle memory, and who would rather have message history stored on their own machine than re-fetched from a browser cache. The README says recent history is copied to the computer after linking and stored there, and that older messages load as you scroll up, first from the local archive and then from the phone. That local-first ordering is the design decision the rest of the app is built around.

It is a companion device, not a replacement. You still need the phone to link, and the phone remains the source of truth for account state.

How the protocol layer and the UI are split

The architecture is two crates deep. ZapFast itself is the egui front end; the WhatsApp Web protocol, covering pairing, encryption, history sync and media, comes from whatsapp-rust. The Cargo.toml lists eframe with the glow backend rather than wgpu, which the comment in the file explains as avoiding the larger wgpu dependency. egui and eframe are pinned at 0.36, egui_extras at the same version with file, image, svg, webp and gif features enabled.

That split matters when something breaks. A rendering bug is a ZapFast bug. A protocol bug, such as the poll API limitation described further down, lives in the library the project depends on, and ZapFast's response is to block the action rather than work around it.

The dependency list also shows how much of the app is deliberately assembled from small crates: sha2 for content-hashing saved stickers, aes, cbc, hkdf and hmac for decrypting Signal sticker packs, zip for reading .wastickers archives, skrifa and memmap2 for finding system fonts without scanning whole files, and image for JPEG, PNG, WebP and GIF decoding. Several of those are noted as already arriving through the protocol crate, which keeps the direct dependency count honest.

Building ZapFast from source and linking a phone

The README points to zapfast.rocks for downloads and guides, and the repository ships packaging directories, a PACKAGING.md and a native-packages.yaml, so prebuilt packages exist for the three supported platforms. Building from source needs the Rust toolchain the repository pins. The rust-toolchain.toml file and the rust-version field in Cargo.toml both point at the same requirement, 1.98, with edition 2024.

The repository declares two targets in Cargo.toml: a library named zapfast at src/lib.rs and a binary named zapfast at src/main.rs. A plain cargo build in the repository root builds both, and the resulting binary is what you run. On Linux, the eframe features list includes both wayland and x11, so either session type should work without a rebuild. Expect the first compile to take a while; egui, image decoding and the font stack are not small.

Once the binary runs, the first screen is the linking screen. The README describes two paths: scan a QR code, or link with your phone number.

After linking, recent history is copied to the computer. The README notes that existing installations request one settings refresh after upgrading, to recover previously lost mute settings and pin order, and that this happens without relinking. If you are coming from an older build, that refresh is the step you should watch for rather than re-pairing the device.

GIF search is the one setup detail with an external dependency: the README says it needs a free GIPHY API key unless the build already includes one. The README does not document where that key is configured, so check the project site's guides before assuming it works out of the box.

Where ZapFast stops short

The README is unusually candid about its own edges, and they are worth reading before you switch.

Polls in disappearing-message chats are blocked outright. The stated reason is that creating polls in those chats is not yet supported by the protocol library's poll API, so ZapFast refuses the action instead of silently ignoring the timer. That is the right call, but it is still a missing feature.

Text direction is partial. Hebrew and Arabic RTL paragraphs keep logical word order by reordering font runs, and the README says explicitly that this is not a full Unicode Bidirectional Algorithm. Mixed-direction text with embedded numbers or Latin fragments is where that distinction will show.

Poll results can be incomplete. Voting needs the original poll's key; if the key is missing, the message tells you to vote on your phone instead. When the phone is offline, results are labelled incomplete and the request retries with backoff.

Attachments have a 64 MB automatic download ceiling, and expired attachments require asking the phone to upload them again. Received disappearing messages stay in the local archive after they expire on the phone, which is a privacy consideration as much as a feature.

The biggest caveat is not in the README at all: this is an unofficial client using the WhatsApp Web protocol. Nothing in the repository guarantees that the protocol library keeps working if the service changes.

ZapFast against the official desktop app and WhatsApp Web

The obvious alternative is the official WhatsApp desktop application, and the difference is architectural rather than cosmetic. The official app bundles a browser engine; ZapFast renders through egui on glow and ships no browser engine at all, which is where the memory gap in the project's own Linux measurement comes from.

The second difference is where history lives. WhatsApp Web keeps a local cache tied to the browser profile. ZapFast copies recent history to the machine on linking and reads older messages from that archive first, falling back to the phone. The README also states that received disappearing messages remain in the local archive after they expire on the phone, which the official clients do not offer and some users will not want.

A third difference is responsiveness to small details. Accent-insensitive contact search, pinned chats that stay in pin order regardless of new messages, and a composer that regains focus when you return to a conversation are all documented behaviours. These are the kind of things a browser tab does not do, and they are the practical payoff of a native UI.

What you give up is coverage. The official client is the reference implementation; ZapFast is a reimplementation of the protocol with documented gaps. If your workflow depends on a feature the README does not list, assume it is absent until you check.

Licence, packaging and the cost of keeping up

ZapFast is MIT licensed, and the Cargo.toml declares the same. MIT is permissive: you can build, modify and redistribute it, and the packaging directory plus PACKAGING.md suggest the maintainers expect downstream packagers to do exactly that. That is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read the licence and the licences of the dependencies yourself.

The dependency list is the real upgrade cost. egui, eframe and egui_extras move together at 0.36, and the Cargo.toml comment warns that skrifa must stay aligned with epaint to avoid compiling two versions of the font stack. Bumping egui is therefore not a one-line change. The comment on memmap2 explains it limits font scans to the required pages, which is a deliberate constraint rather than an incidental dependency.

Maintenance looks current: the repository is not archived, and the last push was on 2026-09-17, the same day as the 0.14.0 release notes dated 2026-09-16, which mention polls, themes and a quieter desktop. The release cadence visible in the release list is tight, with 0.13.0, 0.13.1 and 0.14.0 all landing within three days. Fast release cadence cuts both ways: fixes arrive quickly, and so do changes you may need to track. The README does not document a rollback path or a stable-branch policy, so pin a version if you package it.

Editorial conclusion

Adopt ZapFast if you run WhatsApp on a desktop all day, want the message archive on your own disk, and can live with the gaps the README admits to: no disappearing-message polls, no full bidirectional text algorithm, and a GIPHY key needed for GIF search unless your build ships one. Skip it if you depend on features only WhatsApp Web or the official desktop app provides, or if you are unwilling to link an unofficial client to your account. Before you commit, check the linking screen against your phone, confirm the archive lands where you expect, and read the benchmark page at zapfast.rocks rather than trusting the RAM figure second-hand.

Frequently asked questions

Official sources

1. crmne/zapfast on GitHub
2. License: MIT
3. Project website
4. README
5. Releases