Building a native Windows app from a Mac

TesseraSnap is a window manager for Windows 11. I wrote almost all of it on a Mac. Here’s how that works, and why I’d do it this way again.

Why Rust and raw Win32

A window manager runs all day, every day. It should start instantly, use almost no memory and never be the reason a laptop fan spins up. That rules out shipping a browser engine or a large runtime for the core of it.

Rust against the Win32 API gives you a single small executable with no runtime and direct access to everything a window manager needs: global hotkeys, low-level mouse hooks, window placement and per-monitor DPI.

Cross-compiling from macOS

The toolchain is less exotic than it sounds:

brew install mingw-w64
rustup target add x86_64-pc-windows-gnu
cargo build --release --target x86_64-pc-windows-gnu

That produces a Windows .exe on a Mac. For day-to-day work it’s the fastest loop: write, build, copy to a Windows machine or VM, try it.

Let CI own the Windows-only parts

Some steps genuinely need Windows: the MSVC build, packaging an MSIX for the Store and running the Windows App Certification Kit. Those run in CI on a Windows runner, on every push. Each build produces a Store-ready package, a signed side-load package for testing, and a certification report.

The rule I follow: anything I’d forget to do by hand before a release belongs in CI.

Where AI helped most

The Win32 API is enormous, old and full of sharp edges. AI pair-programming was most valuable in three places:

• Recall — the exact flags, struct layouts and message sequences that used to mean an afternoon of digging through docs.
• Audits — reviewing unsafe blocks, handle lifetimes and hook procedures with fresh eyes.
• Research — mapping out the competitive landscape and the Store’s requirements before writing code.

It didn’t replace testing on real hardware. Nothing does.

TesseraSnap is headed to the Microsoft Store. You can follow along at tesserasnap.com.