By John Gruber
WorkOS: APIs to ship SSO, SCIM, FGA, and User Management in minutes. Check out their launch week.
Jim Salter, writing for Ars Technica:
Google presents Chrome for download as either an x86_64 package or an M1 native option — which comes across as a little odd, since the M1 native version is actually a universal binary, which works on either M1 or traditional Intel Macs. Presumably, Google is pushing separate downloads due to the much smaller file size necessary for the x86_64-only package — the universal binary contains both x86_64 and ARM applications, and weighs in at 165MiB to the Intel-only package’s 96MiB.
The Intel binary of Chrome running through Rosetta on M1 Macs wasn’t slow, but the native version is, unsurprisingly, a lot faster. Salter ran a bunch of benchmarks, though, and Safari is still faster than native Chrome on MacOS 11 Big Sur on M1 Macs.
Google is definitely doing this wrong, asking users to navigate this before downloading. Chrome is supposedly for everyone, not just nerds. Plus, if you already have the Intel-only build installed on an M1 Mac, Chrome’s weird auto-update feature isn’t updating to a native Apple Silicon build. Google has trained Chrome users for years not to do anything, to just trust that Chrome will automatically keep itself up to date, but typical users with the Intel build installed are going to be running at half speed through Rosetta.
Here’s a detailed discussion on the Chromium developer forum discussing the pros and cons of simply shipping a universal binary. The basic gist is that Chrome is so large, doubling the compiled binary footprint for a universal build was deemed problematic for all users. Why make the majority of Mac users still on Intel-based Macs download a version twice as large? I’d say the problem is that Chrome is too bloated. They should ship a universal binary to everyone and get to work slimming Chrome’s footprint. Maybe some work on that would help Chrome catch up to Safari performance-wise.
★ Thursday, 19 November 2020