Highball: Open-Source Mac Gaming Tool Queries Compatibility DB Before 80GB Downloads

Background: Whisky's Archive Leaves a Gap

After Apple Silicon removed Boot Camp, Mac users had two main paths for Windows games: pay for CrossOver or self-manage Wine. The popular free GUI Whisky was archived in 2025, leaving users without a maintained option. In late August 2025, Highball appeared — a native macOS app (SwiftUI + full CLI) that one-click installs Wine and three rendering layers (DXMT, D3DMetal, DXVK), hooks into Steam or Epic libraries, and runs on macOS 14+.

Why Highball Exists: Learning from Whisky's Failure

The README's "Why Highball is built this way" section analyzes three failure modes of prior tools and inverts each:

Engine lock-in: Many tools bundle modified Wine as a black box; when maintainers leave, builds cannot be reproduced. Highball pulls engines only from public upstreams (Gcenx builds, DXMT, Sikarugir) pinned by version and SHA-256. Game-specific patches (e.g., MoltenVK fixes for Red Dead Redemption 2) live in the repo's spike directory with build scripts, and PRs are sent upstream. Engine upgrades become a JSON pull request.

Data burial: When a tool dies, accumulated "which game runs with what config" knowledge disappears. Highball separates all recipes and data into an independent repo highball-db under CC0 — owned by no one, surviving any tool. CrossOver users can also use it.

Ecosystem parasitism: Tools often free-ride on Wine, capture donations, and lock users into paid tiers. Highball pushes bug fixes upstream, donation links point to Gcenx and DXMT, and the README explicitly says: "For commercial-grade support, buy CrossOver; it funds most of Wine's Mac work."

The Database Is the Product

The open compatibility database at gethighball.com/database (sourced from highball-db) is Highball's core differentiator. Each game entry has a verdict — verified playable or not, which renderer to use, community-reported frame rates, and the source of every conclusion.

Data is explicitly tiered:

Verified — tested by the project

Community report — submitted by players

Prediction — machine-inferred

So you know the reliability of each verdict.

Kernel-level anti-cheat games (most online shooters) are marked "no go" upfront — they fundamentally cannot run under Wine's translation layer. This saves you from downloading 80 GB only to hit a black screen.

Data comes from a one-command report after playing:

highball report <bottle> "Game Name" --rating 5

This generates a pre-filled compatibility report submitted to highball-db; accepted reports are auto-archived via CI. Community reports already cover M4, M5, and macOS 15. Verified data feeds back into launch logic: Highball selects renderers based on what predecessors validated.

Concrete examples from the database: Cyberpunk 2077 on M5 hits 60–82 FPS (D3DMetal renderer + FSR 2.1); Red Dead Redemption 2 runs on M1 Pro. These are real submissions, not marketing claims.

User Experience

Install via DMG (notarized) or Homebrew:

brew install --cask gauthierpiarrette/highball/highball

First launch auto-installs Rosetta (if needed), downloads engines (hundreds of MB), and prepares the Windows environment. Steam's initial 235 MB client unpack adds time; total first-run 15–25 minutes with a progress bar per step. Restart resumes where it left off.

Nice touches: ⌘C/⌘V/⌘A work inside Windows apps (Command→Ctrl, Option→Alt; Alt combos for gaming unaffected, toggleable per environment). Everything lives in ~/Library/Application Support/Highball/ — no touches to /usr or /Library; deleting that folder fully uninstalls.

Launcher support (honestly documented in knownIssues fields):

Steam & Epic: default engine works

Rockstar, EA, Ubisoft launchers: embedded browsers need Wine 11 built from CrossOver 26.3 code — GTA V, RDR2, The Sims 4 verified

Battle.net & Ubisoft Connect: login window pops but no games run yet

GOG Galaxy: black screen; DRM-free GOG installers run directly inside the environment

Full CLI parity: install engines, create bottles, launch games — all headless.

Technical Architecture

App and CLI are thin views over HighballKit. Engines are manifest-defined bundles (Wine + runtime libs + rendering-layer overlays). A bottle is a WINEPREFIX plus bottle.json. Renderers are directory overlay layers; at launch the chosen renderer is injected via WINEDLLPATH_PREPEND per game.

This makes "swap renderer" a directory swap. Compatibility verdicts become launch configs directly because recipes are declarative JSON steps (install runtimes, edit registry, pick renderer, pin versions) — machine-readable, hence auto-executable.

Licensing boundary: D3DMetal comes from Apple's Game Porting Toolkit (non-commercial only). Highball neither modifies nor redistributes it; users must explicitly accept Apple's terms to enable it.

Caveats & Outlook

Beta: README labels it beta — main flow works, edges may break. 909 stars in <1 month shows traction, but bugs may wait for next release.

Performance ceiling: Wine + translation layer has overhead; AAA titles won't hit native max FPS. Database frame-rate data sets realistic expectations; FSR upscaling helps.

Kernel anti-cheat: Hard no — database flags them upfront.

Young database: Value grows with reports. Popular titles covered; long-tail games may have no entry — your report becomes the reference.

The project's deepest insight: most open-source projects compete on code; Highball makes its most valuable asset a public good no one owns — a CC0 dataset that outlives the tool. Whisky's legacy wasn't code but a culture of honestly labeling limits; Highball encodes that honesty into data structures — knownIssues fields, three-tier tagging, every verdict with source and timestamp. Tools age; open, sourced data doesn't. On that axis, it already thinks further than most "Wine wrappers."

GitHub: github.com/gauthierpiarrette/highball