Hacker News Reader

Comment by nkurz | Hacker News Reader

What's the argument for why fat binaries like this are a good idea, as opposed to having separate binaries that can be downloaded for different architectures? It seems like the main advantage would be when there is (something like) a networked drive simultaneously accessed by incompatible machines, with a secondary case for when the same drive is transferred from machine to machine (or when a single machine is upgraded to a different processor). Is this a large enough use case to drive adoption, or is there some other major benefit that I'm missing? Or is it that having 2x (or 17x) larger binaries to distribute isn't actually much of a downside, so even a small benefit is sufficient justification?

View on HN

Most apps, 2x binary size is no big deal. This has been true since the 1990s, when we had fat binaries that were M68K and PowerPC. Nobody’s doing 17x, that’s just a joke.

Figuring out how to get users to download the correct binary, now that sucks. Do you add JavaScript to your download page or do server-side sniffing with the user agent to deliver the correct binary? And do you want to explain to someone that yes, they downloaded the Mac version but they have an x86 Mac and can’t download the ARM binary?

>And do you want to explain to someone that yes, they downloaded the Mac version but they have an x86 Mac and can’t download the ARM binary?

Can't you detect the system architecture through the user agent string? eg. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Us.... I guess it's still an issue if you're downloading for ARM mac, using a x86 mac, but that's a pretty rare occurrence and you can work around it by allowing users to select the architecture manually.

The only advantage that user agent sniffing has over fat binaries is the decreased size, and usually, it’s a fairly small difference. Small benefit, big drawback. Plus, there are all the smaller developers or hobbyists who just want to share the app they made, and maybe don’t want to figure out how to get user agent sniffing working on their site—or maybe they are just sharing a link to Google Drive with the game that they made.

Also from my experience, people still share downloaded copies of applications.

We can use thin binaries only when necessary—web browsers, for example.

I would go further than "no big deal"—it's a complete nonissue. You could have 5 architectures and it would still be a nonissue, because for most graphical applications, 99% of the size is taken up by graphics and similar assets.

The copy of TextEdit on my Mac is 6.8 MB, but the actual binary is only 167 KB. Even if you were to go nuts and compile a full-on 17-architecture version of the TextEdit binary, it would still constitute less than half the size of the app, and this is for TextEdit, an app with exceedingly few graphics.

And, we're talking exclusively about hard disk space—it's not as though the foreign architectures are getting loaded into memory and taking up space there. I'm all about sweating the details when it comes to optimization and performance, but even on a smaller SSD, a couple extra megabytes per app just isn't going to have a real impact.

Fun fact: many of the binaries in Snow Leopard are still PPC-Intel universal binaries, even through 10.6.8. The extra space used was so minimal that Apple didn't bother to fully strip out the PPC portions until Lion. (Early versions of Snow Leopard can even be booted on PPC by replacing certain files: https://forums.macrumors.com/threads/snow-leopard-on-unsuppo...)

User confusion is a real thing. First stage of this is when presenting a download - how does an average user know which of the 3 or 4 binaries you offer to download?

Then a year later the user gets a new computer and migrates everything to it using Migration Assistant. The platform specific binary he downloaded from your website no longer runs, and he assumes it’s because it’s broken, or the new computer has a new OS, or he has to buy a new copy for the new computer.

Another potential problem would lie in a user copying an app to a second computer with a different architecture.

Lots of reasons to distribute fat binaries if you’re not in the App Store (n which case the OS can/will auto download the correct version upon migration).

I'm not a macOS user, but aren't macOS applications installed by just copying the bundle (which appears to the user as if it was a single file, instead of a directory)? Making the same application bundle work on both architectures means that a user who upgrades from an Intel macOS to an ARM macOS can just drag-and-drop the applications from the old system to the new system, and they will work.

Most applications are distributed that way. Some have more complicated, Windows-style installers (PKG files) because they need to do things like install kernel extensions or what have you before they'll work.

> It seems like the main advantage would be when there is (something like) a networked drive simultaneously accessed by incompatible machines

Your thinking is way too complex. Apple's #1 resource is smooth UX and having different versions of an app that you need background knowledge about your computer to choose is very not smooth.

If you download a Windows application e.g. https://www.textpad.com/download you often have to decide whether to download the 32-bit or 64-bit version. Not a big problem for any of us HN users, for sure. But it's not a great interface e.g. for my dad, who just bought a laptop, which "runs Windows", he doesn't know whether it's the 32-bit or 64-bit version.

Might not be so relevant today for Windows, as I guess it's been a while since 32-bit Windows was popular. But the point stands, that during times when there are multiple versions in popular use, as will soon be the case for the Mac platform, asking the user to choose which they have is confusing, as they might not know.

Being able to download a single binary and it "just works" is exactly the user-interface for a download page that you want.

For most applications the machine code is not the bulk of the size, that’s assets like images. These aren’t duplicated in a ‘fat’ binary so the size increase is rather modest.

The advantage is convenience for the user (and developers), one download that works transparently for all computers.

The only real advantage is you don't have to worry about which binary to pick on the download page.

This is an enormous advantage, so it's not to be disregarded lightly.

Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone. Perhaps you download a shim installer that tests your processor and chooses the correct download? Perhaps instead of a generic web browser downloads are done within a framework that already knows the correct architecture? Especially if you are Apple, and if the goal is simply choosing the right version initially, it seems like there would be many better solutions.

> Perhaps you download a shim installer that tests your processor and chooses the correct download?

Wouldn't that only work if the shim itself was a universal/fat binary? Otherwise you still run into the same problem. You can sort of work around on unix-like systems by using the shebang, and on windows by having the executable in .net.

Sure, it could be a universal binary, or something interpreted, or bytecode using an existing VM. But the shim would be something small, and could probably be reused as a standard installer for many programs. My argument wouldn't be that a universal binary is never the right approach, but that it seems wasteful to make every binary support multiple architectures instead of using a more targeted approach.

> Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone.

In the average application, the binary is only a minor contributor to bundle size, assets are the vast majority of it.

For instance on my system Delicious Library 3 is a 110MB bundle. The binary is under 4MB. Same observation with Keka (30MB / 344K), xACT (15MB / 960K) or unicode checker (10MB / 500K)

Fat binaries were not an issue during the last transition, they're even less so now.

It's an enormous advantage in one specific case, where you have enough non-technical users who would otherwise need to manually choose a binary.

That was a big deal for Apple during their two previous transitions, but not as much these days where as I understand it a significant portion of Mac software distribution happens through the official App Store platform.

We see the same in the Linux world, where fat binary support has been developed and proposed on multiple occasions but has never really caught on because the number of users who don't know their CPU architecture but want to install software from outside their distro's package manager is effectively negligible.

Universal Binaries were barely an issue fifteen years ago, either. Sure, they were a bit larger but only the actual compiled code changed. Any assets used were the same and the difference in package size wasn't particularly significant.

> as I understand it a significant portion of Mac software distribution happens through the official App Store platform

It's not that significant. I'd guess the amount that goes through the app store is almost certainly less than half, and very possibly much less.

It's an enormous advantage:

- to restore your apps onto a new machine using Migration Assistant and have them "just work" at full performance

- to have a single app that you can drag and drop install on your old and new hardware

- in campus environments to have a single image and archive for all local software

There are tools specifically designed to remove unused parts of fat binaries as well. One of the most notable Mac ones is Monolingual.

What would be really neat is a self-stripping universal binary.

Sometimes, especially for retro-computing, it's more handy to actually have fat binaries.

A self-stripping binary sounds like a really interesting programming challenge, though.

Reply on news.ycombinator.com