Universal binary for macOS

[skyzyx]

Can we get a Universal Binary (possible with the latest GoReleaser) for macOS?

[bendrucker]

Why would we do this when suitable architecture-specific builds are already available? I see you've gone around posting form issues to a bunch of repos, but you have't explained why it's valuable.

The costs are readily apparent: longer build times, bigger downloads.

I understand the point of universal binaries in theory, especially for consumer apps.

goreleaser/goreleaser#2070 (comment)

With brew install on the other hand, there would seem to be little benefit.

It's great that GoReleaser supports this but that's not reason enough to do it.

[skyzyx]

Well, because people don’t need to spend time thinking about which CPU architecture they have on any particular machine. The single binary will run on both.

I have an Intel MacBook Pro, and an M1 Mac Studio. I have lots of build scripts where I’m having to go back and apply logic to figure out which version of which binary to download from different places. The end-user value is not having to deal with any of that. In some cases, I synchronize scripts and occasionally binaries over dropbox to multiple machines. Again, it would be great if I just had a single binary to deal with.

If you’re building two CPU architecture already, you’re not looking at additional build time. You are looking at a double sized binary, but that’s true for literally every fat-binary that has ever existed during CPU architecture transitions.

So, that’s the rationale behind my request. I had made the assumption that the value was self-evident, but it seems that was a poor assumption on my part. Mea culpa.

[bendrucker]

Was assuming universal builds were a separate build or otherwise delegated to Go but that's actually not the case. Go has no knowledge of multi-architecture builds—it generates separate arch-specific builds and then GoReleaser merges them:

https://github.com/goreleaser/goreleaser/blob/main/internal/pipe/universalbinary/universalbinary.go#L135-L241

With existing arch-specific releases in use the choices are:

1. Replace the arch-specific binaries with a single universal one, breaking existing users (upon upgrade)
2. Add a new universal binary

(1) is initially disruptive when released but then settles into a stable long term state where active users use universal binaries. (2) is not disruptive but means all releases will be needed indefinitely, since existing users have no incentive to ever switch.

GoReleaser itself opted for (1)—you can see references from a handful of broken dependents in the PR:

goreleaser/goreleaser#2572

That said, it strikes me that this is a "drop in the bucket" solution to a problem that spans all CLIs and is already broadly solved by scripting and package managers. I can't seem to find a single universal binary out there among popular CLI tools I have installed, with the exception of GoReleaser. The idea that small volunteer projects should be leading the charge on an effort with such niche demand seems off. I'm not opposed to a PR but generally skeptical that this is a good use of time/energy at the moment.

[wata727]

If many other users want to use universal binary, consider doing so. Since there hasn't been such a need so far, I believe many users are happy with the current architecture-specific binaries.