Haven't used MacOS in forever but on Linux Steam/Valve games don't really use an binary file to launch but instead use scripts that can be edited and if this is the case for MacOS then you might be able to simply remove the check for rosetta (assuming its not actually needed).

I can't test this out for you sadly. Best of luck.

The Steam app you install into the Applications folder is kind of a stub; it more or less immediately executes the real Steam app which is installed into "~/Library/Application Support/Steam"

The real app is a universal app (in the Steam client beta, anyway), but the stub is Intel-only, at least for the time being. There is a mechanism to update the stub app, but they've not used it yet.

The stub app and the real app are basically the same thing on a code level (just doing different roles) so it might be possible to copy stuff across from the real app to the stub app to do a sort of manual upgrade of the stub to be a universal app, but it's very possible that this won't work, due to the stub app noticing that it's not the version it expects to be and updating itself back to the Intel-only version. I've not done the experiment myself yet to find out.

I'm hopeful that this is just Valve being conservative; if the stub breaks, they can't push updates to fix it, the user would have to manually reinstall. So, makes sense to leave it as-is while they gain confidence there's nothing wrong with the Apple Silicon version. My guess would be they update the stub sometime after the 'real app' is made universal outside the beta.

To add a bit more specificity to aiusepsi's reply:

Originally posted by aiusepsi:

The stub app and the real app are basically the same thing on a code level (just doing different roles) so it might be possible to copy stuff across from the real app to the stub app to do a sort of manual upgrade of the stub to be a universal app, but it's very possible that this won't work,

This won't work due to the fact that all Mac apps must be code-signed, and this type of manipulation will break the code signature, so it's best not to try.

(Also, given that /Applications/Steam.app is 6.7 megabytes and ~/Library/Application Support/Steam/Steam.AppBundle/ is 1.1 gigabytes, I really suspect tat they are not "basically the same thing".)

Originally posted by aiusepsi:

I'm hopeful that this is just Valve being conservative; if the stub breaks, they can't push updates to fix it, the user would have to manually reinstall.

While I think that this is a reasonable guess as to what is going on with Valve's reasoning, it's kinda bizarre that every other Mac app in the universe just updates using Sparkle and I have ~never had an app break in this way. So this is quite possible to implement reliably. The correct "cautious" thing to do at this point would be to ship a universal2 stub binary, not hang on to the old / dead Intel build for eternity.

We are 5 years into this transition now and it does seem strangely incompetent that Valve is still stuck on this very basic step. Personally I'm probably never getting rid of Rosetta2, I've got dozens if not hundreds of games that are totally unmaintained and will never get Apple Silicon builds, and even Apple has said that they're going to keep around a subset of Rosetta2 for an extremely long time specifically for stuff like old game preservation, but the fact that Valve can't make this very simple step in the platform's transition for more than half a decade does make me worry about the viability of Steam for mac gaming going forward. I was so happy that I was able to get Cyberpunk 2077 via Steam so I could play it on my Deck as well as my Mac (given that I can't play it on an iPhone or iPad, that storefront made a lot more sense). But are publishers going to keep doing those same-day releases if Valve can't get it together?

Does anyone know any plans or a roadmap for releasing a universal installer?

wow

Originally posted by glyph:

To add a bit more specificity to aiusepsi's reply:
...
This won't work due to the fact that all Mac apps must be code-signed, and this type of manipulation will break the code signature, so it's best not to try.

On of the inevitable problems with trying to be at least a little succinct; yes, code signing problems are one of the potential ways it can not work I alluded to by saying "it's very possible that this won't work". However, it is not the case that Mac apps have to be code signed. You can individually allow unsigned apps, or apps with a broken signature, through the Privacy & Security section of system settings. Fun fact: you have to do this with the Mac version of Civ VI (unless you buy all the DLC) because Aspyr ship a broken code signature.

(Also, given that /Applications/Steam.app is 6.7 megabytes and ~/Library/Application Support/Steam/Steam.AppBundle/ is 1.1 gigabytes, I really suspect tat they are not "basically the same thing".)

The executable in both cases is the same program, the 'steam_osx' executable. I used the word 'stub' specifically because Steam.app is cut down from full Steam client content. The word Valve themselves use to describe this component is 'bootstrapper'.

So, I did actually just try replacing the steam_osx binary from Steam.app with the one from Steam.AppBundle (and erasing the code signature) and it actually seems to work as expected. Looking at the bootstrap_log.txt, usually it does something like this:


The startup line with the updater built 2021 is Steam.app starting up, and then it hands off control to the version from Steam.AppBundle. Then, after doing my experiment switching the steam_osx executable over:


So... yeah. It works! I'm actually a little surprised how smoothly that went. I don't have another Mac that doesn't have Rosetta 2 installed to test on, but I bet it'd work.

So this is quite possible to implement reliably. The correct "cautious" thing to do at this point would be to ship a universal2 stub binary, not hang on to the old / dead Intel build for eternity.

They're not going to stick with the Intel version for eternity.

I'm sure that the Steam bootstrapper is reliable in itself. After all, every install of the Mac Steam client since that became a thing 15 years ago has used the same software component to update itself. The arm64 version of it should also work just as reliably.

But: at the scale Steam operates, being exposed to a vast array of possible software and hardware setups, unexpected things can happen. For example unexpected interactions from third-party software; e.g., a virus scanner blocking the version of steam_osx with an arm64 slice because of some misfiring heuristic. Stuff that you couldn't predict in advance or reasonably test for.

So, it makes sense to do a limited roll-out to start; catch as many problems in beta as possible before relying on it for everyone, especially given that there's not really any practical benefit to rushing it. Just running the Steam webhelpers as arm64 builds is (perhaps) 95% of the benefit. A little bit of caution for maybe a few months is not the same thing at all as "hanging onto the Intel build for eternity".

the fact that Valve can't make this very simple step in the platform's transition for more than half a decade does make me worry about the viability of Steam for mac gaming going forward.
...
But are publishers going to keep doing those same-day releases if Valve can't get it together?

I'd be among the first to lament that it took Valve this long to put out an arm64 native version of the Steam client. Anyone sufficiently bored enough to look back through my post history can verify that I have indeed lamented this. And it's a shame that it took Apple putting out notice that Rosetta 2 was going away to get to this point.

But: this isn't the first step Valve took on the platform transition. They put out an arm64 version of the binaries necessary for games to use the Steamworks API four years ago. If a publisher was going to be worried about Steam's commitment to support for arm64 Mac, that should have been assuaged then. And the client is arm64 native now. Catastrophising at this point seems redundant.