Website downloads x64 by default #7036

Activity

1. brendandebeasi

   added

   bugSomething isn't workingSomething isn't working

   on Aug 31, 2026
2. github-actions commented on Aug 31, 2026

   

   github-actionsBot

   on Aug 31, 2026 – with GitHub Actions

   Contributor

   More actions

   Confirming the setup first: the x64 DMG is a separate Intel-only build, not a universal binary — release-desktop.yml:70-81 copies each per-arch DMG to a stable Superset-<arch>.dmg name, and electron-builder.ts builds per-arch mac targets. So downloading Superset-x64.dmg on an Apple Silicon Mac gets you a Rosetta-translated app, which is a real (if silent) degradation, not just a naming confusion.

   Where the choice is made

   Only one place on the site can ever hand out the x64 DMG: the download interstitial at superset.sh/download.

   • apps/marketing/src/app/[lang]/components/DownloadButton/DownloadButton.tsx:44-47 — every download CTA just routes to /download; it doesn't pick a URL.
   • apps/marketing/src/app/[lang]/download/components/DownloadInterstitial/DownloadInterstitial.tsx:19-23 — macUrlFor() returns DOWNLOAD_URL_MAC_X64 iff the detected platform is Platform.MacIntel, otherwise arm64. It's used both for the auto-redirect (:36-47) and the "download now" fallback link (:114).
   • packages/shared/src/constants.ts:62-63 — the two URLs.

   For contrast, the download buttons in the web app (app.superset.sh) hardcode arm64 — apps/web/src/app/(agents)/agents/page.tsx:73 and apps/web/src/app/(dashboard-legacy)/settings/billing/page.tsx:63 — so they can't produce this. The issue form says "Web app (app.superset.sh)" but the described flow (clicked download → got x64) matches the marketing interstitial. Worth confirming which host it was.

   Suspected root cause

   detectMacArch() in apps/marketing/src/app/[lang]/hooks/useOS/useOS.ts:18-43 infers CPU architecture from the WebGL unmasked renderer string, and treats "renderer string doesn't contain apple" as proof of Intel:

   return renderer.toLowerCase().includes("apple")
     ? Platform.MacAppleSilicon
     : Platform.MacIntel;   // useOS.ts:37-39

   Every genuine failure path already falls back to Apple Silicon (:30, :32, :36, :41), so a missing extension isn't what bit this reporter. The bug is the last branch: a renderer string that is present but not the real GPU is silently classified as Intel. That happens on Apple Silicon whenever:

   • the browser masks or randomizes WEBGL_debug_renderer_info for fingerprinting resistance (Brave's farbling returns a generic/Google string by default; Firefox with privacy.resistFingerprinting);
   • hardware acceleration is off or the GPU is blocklisted, so WebGL falls back to a software renderer (SwiftShader, llvmpipe, ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device ...))) — none of which contain "apple";
   • the page runs in a VM, remote/screen-shared session, or a browser launched with --disable-gpu.

   The heuristic is also on borrowed time: WEBGL_debug_renderer_info was removed in Safari 17 and is deprecated in Chromium, and GPU model is a poor proxy for CPU arch regardless. Note also that the fallback direction is now backwards from reality — Apple hasn't shipped an Intel Mac since 2023, so "unknown" should mean arm64 and Intel should require positive evidence.

   Reproduction

   Manual, no Intel hardware needed:

   1. On an Apple Silicon Mac, launch Chrome with --disable-gpu (or turn off Settings → System → Use graphics acceleration when available), or use Brave with default Shields.
   2. Visit https://superset.sh/download.
   3. Observe Superset-x64.dmg downloads. Check chrome://gpu or evaluate the renderer string in the console to see what detectMacArch saw.

   Unit-level sketch (detectMacArch is currently module-private, so this needs it exported, or test through usePlatform with a stubbed navigator.userAgent):

   test("software renderer on Apple Silicon is not classified as Intel", () => {
     stubWebGLRenderer("ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero)), SwiftShader driver)");
     expect(detectMacArch()).toBe(Platform.MacAppleSilicon);
   });

   There are no tests for useOS.ts today — adding a table of real renderer strings (Apple Metal, Intel Iris, SwiftShader, masked/empty) would pin this down. The download_started event already carries platform (DownloadInterstitial.tsx:42), so the analytics split between mac-intel and mac-apple-silicon should show how often this fires in the wild; a share materially above the real Intel Mac population confirms it.

   Suggested fix direction

   1. Primary signal: UA-Client Hints. In Chromium, await navigator.userAgentData.getHighEntropyValues(["architecture"]) returns "arm" / "x86" directly and isn't affected by GPU state. It's async, which fits the existing useEffect in usePlatform (useOS.ts:73-75).
   2. Invert the WebGL fallback so it only reports Intel on a positive match (/intel|amd|radeon|nvidia|geforce/), defaulting to arm64 for anything unrecognized, masked, or software-rendered. This alone fixes the reported case.
   3. Always offer the escape hatch. The interstitial's non-waitlist branch (DownloadInterstitial.tsx:100-125) should carry an explicit "Intel Mac? Get the x64 build" / "Apple Silicon build" link so detection being wrong is a one-click recovery rather than a trip to GitHub Releases — apps/docs/content/docs/install.mdx:17 already does this.
   4. Longer term, a universal DMG (mac.target with arch: ["universal"] in apps/desktop/electron-builder.ts:113-140) removes the guess entirely, at the cost of artifact size and a change to the release-artifact renaming in release-desktop.yml:70-81.
3. Kitenite

   added 3 commits that reference this issue on Sep 3, 2026

   fix(marketing): stop inferring Mac CPU arch from the WebGL renderer

   ...

   d4ea33c

   fix(marketing): stop inferring Mac CPU arch from the WebGL renderer

   ...

   ebc3874

   fix(marketing): stop inferring Mac CPU arch from the WebGL renderer

   ...

   1e811b3
4. Kitenite

   closed this as completedin #7054on Sep 3, 2026
5. holt

   added a commit that references this issue on Sep 4, 2026

   fix(marketing): stop inferring Mac CPU arch from the WebGL renderer (P…

   ...

   45c671c