Steam-client krijgt native ondersteuning voor Macs met Apple-socs

Steam heeft native ondersteuning toegevoegd voor Apple Silicon-socs op Macs. Daardoor is het niet langer nodig om het pc-gameplatform te emuleren via Rosetta 2.

Valve heeft de native ondersteuning voor Apple Silicon toegevoegd aan de recentste Steam Client-bèta. Daardoor wordt de x86-versie van de gamewinkel op Macs met een Apple-soc, zoals de M3 of M4, niet langer geëmuleerd via Rosetta 2. Die vertaallaag gaat ten koste van de prestaties, waardoor het navigeren door Steam trager verloopt.

Vorige week gaf Apple al aan dat de aankomende macOS-versie, 26 Tahoe, de laatste is voor oudere Mac-computers met een Intel-cpu. Tegelijkertijd is het bedrijf van plan om Rosetta 2 binnen twee jaar grotendeels uit te faseren.

Reacties (109)

[ShaSem]

Ik snap nooit zo goed de drang van Apple om functionaliteit zoals Rosetta 2 weg te halen uit macOS. Het voelt niet alsof het kwaad kan om er in te laten, het verhoogt alleen maar compatibiliteit met legacy software die niet meer geupdate wordt. Ik snap dat het met iedere release van macOS extra tijd kost om te testen, maar toch.

Rosetta 2 heeft het wel een stuk langer uitgehouden dan Rosetta 1, dat dan weer wel.

[GertMenkel]

Apple wil graag dat iedereen zich aan de nieuwe standaarden houdt. Rosetta2 kost daarnaast ook een hoop stroom en laat software veel trager draaien dan native. Ze forceren softwaremakers om software te maken die beter werkt op hun laptops. Dat verstevigt Apple's marktpositie, en als alle applicaties behalve één wel werken op de nieuwe ARM-only-chip, in plaats van dat niks werkt behalve wat Apple meelevert, legt de consument de schuld eerder bij de software dan bij de architectuurwijziging van Apple.

Vergeet niet dat ze het geheugenmodel van amd64 in hun ARM-chip hebben moeten stoppen om Rosetta2 mogelijk te maken. Dit is niet alleen software die ze moeten onderhouden, maar ook transistors op de chips zelf. Als ze de software kunnen afschaffen, hoeft hun emulatiehardware ook niet mee in de volgende ronde en kan die transistorruimte beter worden gebruikt voor aarch64-instructies.

Rosetta2 is er om te zorgen dat klanten die ARM-macbooks daadwerkelijk wilden kopen. Het is er niet als langetermijnsoplossing voor software ouder dan vijf jaar. Als je dat wilt, zit je bij macOS aan het verkeerde adres.

Overigens is amd64 op ARM ook mogelijk zonder speciale hardware, al wordt het er wel minder efficiënt van. Na de dood van Rosetta2 kun je met QEMU en soortgelijke opties nog gewoon amd64-programma's draaien (ook zonder VM) mits iemand de moeite neemt om QEMU user mode te porten naar macOS. Als Apple's beloftes over hoe snel hun chips wel niet zijn kloppen, zul je er hopelijk weinig van merken dat de hardwareondersteuning weg is.

[TheVivaldi]

Iedereen heeft het maar over software, maar het gaat hier om games. Die zijn van een heel andere orde en hebben ook een hele andere doelgroep.

[GertMenkel]

Maar games doen het ook prima met deze translatiemethode. Wederom niet zo snel als met Rosetta2, maar Box64 haalt aardige performance op bijvoorbeeld de Snapdragon G3, die nog steeds achter Apple aanloopt op native performance. De truc is om zo snel mogelijk de API-calls te vertalen naar native ARM-calls, waardoor het gros van de hardwareacceleratie en OS-/librarycode even snel draait als native. De laatste benchmarks die ik van Box64 gezien heb op de Snapdragon hadden het over een performance van 80% native, dat is met de snelle chips die in de Pro-modellen van Apple's hardware zitten minstens zo snel als de meeste CPU's die gamers hebben draaien. Op GPU-gebied weet ik het zo niet, maar GPU-code zal even snel draaien of het nu door amd64 of aarch64 wordt aangestuurd.

Apple geeft niet zo heel veel om games (die niet op Apple Arcade verschijnen) dus momenteel wordt er vooral vanuit Valve veel op dit gebied ontwikkeld, maar aangezien Valve ook met een ARM-handheld lijkt te experimenteren verwacht ik dat deze technologie het uitschakelen van de emulatie-hardware het wel zal opvangen.

De grootste uitdaging zal hem vermoedelijk juist weer in software zitten, namelijk dat Apple geen Vulkan heeft, hun OpenGL-driver onvolledig is, en OpenGL sowieso heeft gedeprecate, waardoor iemand al het ARM-optimatlisatiewerk dat in dingen als dxvk wordt gestopt in hun eigen compatibiliteitstool zal moeten stoppen.

[Reactie gewijzigd door GertMenkel op 14 juni 2025 17:49]

[TheVivaldi]

Dat is allemaal leuk en aardig, maar niet alle gamers zijn bereid om zulke stappen te zetten - die willen gewoon dat het werkt. Helemaal op macOS, wat toch al gezien wordt als een systeem waar makkelijk mee te werken is.

[GertMenkel]

Gamers zijn al gebeten door Apple's keuzes toen ze 32-bit-executables onbruikbaar maakten en het is een kwestie van tijd voor dit met de ARM-transitie weer gebeurt. Als je je oude spellen wil kunnen blijven spelen, kun je er beter een PC naast kopen (en dan via Steam streamen op je Mac als dat je voorkeur geniet). De originele Halo, die ook voor macOS is uitgebracht, heeft het ook niet heel lang gedaan op Intel-macs.

Als je geen launcher wil installeren om je oude spellen mee te starten en Valve dit niet voor je oplost, wordt het straks wellicht lastig als Apple-liefhebber. Zo'n beetje alles waar oude spellen op gebouwd zijn, is onderhand deprecated.

En aan de andere kant: Codeweavers heeft al jaren een fork van Wine voor macOS die goed genoeg blijft verkopen dat het bedrijf nog bestaat. Er lijken dus ook genoeg gamers te zijn die wél die moeite willen doen.

[TheVivaldi]

Maar CrossOver emuleert momenteel (net als Wine) alleen ARM. Ze hebben nog geen ondersteuning ingebouwd voor Box64 om niet-ARM-games te spelen.

[GertMenkel]

Dat klopt, maar dat voorkomt niet dat men dat in de toekomst niet alsnog gaat doen. Codeweavers heeft daar vier jaar geleden zelf in een blogpost over geschreven: https://www.codeweavers.c...roadmap-for-apple-silicon

PART 3 – FUTURE: If and when Apple does decide to remove or eliminate Rosetta2, we will likely be prepared. Technology changes, and CodeWeavers has managed these changes for the past 25 years (past 15 years on macOS). We were able to transform our technology to support macOS (then known as OS X) in 2006; able to manage the deprecation of OpenGL in OS X in favor of Apple’s METAL in 2018; able to manage the elimination of 32-bit application support in 2019; and managed the introduction of the Apple Silicon processors in 2020 while in the midst of a worldwide pandemic. We’re fortunate to employ really smart and really clever people that are dedicated to supporting our customers and our technology. And if at some point Intel Macs go away for good, we will again transform ourselves accordingly.

Zodra Apple aankondigt dat Rosetta2 eruit gaat bij de volgende release, gaat Codeweavers hard aan het werk om hun product bruikbaar te houden. Ik vermoed dat ze net als ze nu Wine en andere projecten pakken en ombouwen + optimaliseren voor macOS, ze hetzelfde zullen gaan doen met Box64 of een soortgelijke technologie.

Zoals het er nu aan toegaat in gameland is alleen de Switch nog aarch64, de rest van de populaire "gamer"-platforms draaien allemaal op amd64 en ook nieuw-aangekondigde chips en consoles lijken die trend voort te zetten. De uitzondering is natuurlijk mobiele games, die al native op Mac draaien als ze op een iPad kunnen draaien.

Uiteindelijk komt er een toolkit uitrollen die net zo makkelijk te gebruiken is als Crossover nu is. Of dat voor de meeste Mac-gebruikers makkelijk genoeg is, is voor Mac-gebruikers om te besluiten.

[pete4live]

Ik gebruik zelf geen Apple producten, maar ik ben wel groot fan van Apple's gedachtegoed op het gebied van nieuwe standaarden en hoe deze worden geforceerd.

Veel mensen maken Apple nog steeds belachelijk voor het feit dat het in het verleden MacBooks heeft uitgebracht met alleen USB C poorten, maar ik was eigenlijk groot voorstander van dit concept. Ik had persoonlijk veel liever gezien dat de fabrikanten van randapparatuur gewoon het moderne USB C hadden geïmplementeerd op hun producten, maar Apple is helaas onder druk van de markt toch weer terug gegaan naar het aanbieden van oudere standaarden en poorten. Goed om te zien dat Apple op het gebied van silicon wel gewoon een lijn trekt en niet zwicht voor oude inefficiënte standaarden omdat men dat nou eenmaal gewend is. Jammer voor de legacy software, maar dan moet die software maar gewoon mee gaan met de tijd.

[SterkeYerke]

Steam laat juist zien waarom ik het wel snap. Die stappen pas over naar een native versie op het moment dat het nodig is. Als alle programma’s dat doen, zal dat geheid ten koste gaan van de accuduur van MacBooks.

[Niosus]

Steam heeft echt wel veel meer effort gedaan dan alleen dat. Ik weet nog heel goed dat in het Windows 8 tijdperk veel tijd en moeite hebben gestoken in het porten van hun games, bovenop de Steam client. Ze hebben ook enorm bijgedragen aan WINE en DXVK, onder andere met het doel om meer games ook op Mac te kunnen draaien (al was/is hun grote focus Linux).

De laatste jaren hebben ze die inspanningen serieus terug gedraaid omdat het wel duidelijk is geworden dat het Apple gewoon echt niet kan schelen. In plaats van samen te werken met Valve om er een echt succes van te maken, leggen ze gewoon steeds meer barrieres op. Dat gaat van het niet updaten van OpenGL libraries zodat die gewoon oer-oud zijn en blijven. Het vertikken van Vulkan native te ondersteunen. Het laten vallen van 32bit apps (wat dus alle games vanaf een bepaalde leeftijd zijn), etc.

Dat zijn dus allemaal gaten in macOS die Apple er zelf heeft in geschoten. Op een bepaald moment is het wel genoeg geweest. Valve kan blijven tijd en moeite steken in vertaallagen om alles aan de praat te houden. Op een bepaald moment is de maat vol en doe je juist het nodige voor basis dienstverlening. Apple snapt "PC" gaming niet. En dat is oke, iedereen wist dat eigenlijk wel al. Ik snap dat Valve beslist van het zaakje dan niet verder te forceren.

[SterkeYerke]

Ik ben het helemaal eens met je verhaal hoor. Ik bedoelde meer aan te geven dat er voor devs überhaupt geen reden is om over te stappen vanaf Intel zolang hun programma “goed genoeg” draait, maar dat dat niet wil zeggen dat er voor Apple ook geen reden voor is.

Maar ja, gamen op Macs blijft teleurstellend. Vroeger kon je dan nog gaan bootcampen, want de hardware was soms snel zat voor een beetje gamen, maar dat kan nu niet meer. Hoe draait Linux tegenwoordig eigenlijk op Apple Silicon? Daar valt misschien nog wel wat te halen op termijn.

[Niosus]

Steeds minder goed voor zover ik weet. M1 en M2 waren aan de praat te krijgen, maar sinds M3 is er iets veranderd waardoor het voor zo ver ik weet niet mogelijk is om er op dit moment Linux op te draaien. Dat project was dus goed begonnen, maar Apple lijkt hun architectuur sneller aan te passen dan de vrijwilligers kunnen volgen.

[svenk91]

Volgens mij zit er ook wat extra hardware in Apple’s socs om Rosetta 2 mogelijk te maken. Als ze dat niet meer mee hoeven te nemen in hun M6 soc en latere ontwerpen dan scheelt dat in formaat/prijs/zuinigheid en/of kan je er wat extra performance in stoppen. En aangenomen dat Tahoe, de laatste MacOS versie met Rosetta 2 support, nog 1 jaar feature updates krijgt en dan 3 jaar security updates zoals je veel ziet bij Apple dan hebben ontwikkelaars uiteindelijk 9 jaar de kans gehad om over te gaan.

[ShaSem]

Goed argument, volgens mij klopt dat inderdaad ook. Maar waarom dan de support er uit halen op de SoC’s die het wel ingebakken hebben?

[Ricco02]

Omdat support op software niveau ook geld kost.

Liever iedereen pushen om native apps te bouwen dan. Moet ook wel zeggen dat Rosetta denk ik ook meer iets was om bedrijven tijd te geven om een native versie van hun apps te maken maar ondertussen wel een emulatie van de software te kunnen runnen.

[Llopigat]

Je vergeet wel de olifant in de kamer: Mensen nieuwe Macs laten kopen.

Apple is niet vies van planned obsolescense. Nooit geweest ook. Het zal niet de enige reden zijn maar wel meespelen.

[Reactie gewijzigd door Llopigat op 14 juni 2025 17:58]

[CharlesND]

Je vergeet wel de olifant in de kamer: Mensen nieuwe Macs laten kopen.

Die redenatie snap ik niet helemaal. Op je 'oude' computer die Tahoe nog kan draaien blijft Rosetta met je legacy software werken. Koop je volgend jaar een nieuwe computer met een nieuwer OS dan is Apple al bezig om Rosetta uit te faseren en over 2 jaar werkt een nieuwe computer helemaal niet meer met Rosetta.

Mensen die aan hun legacy software gehecht zijn gaan dus GEEN nieuwe computer kopen. Apple zou juist een nog snellere, hardwarematig ondersteunde versie van Rosetta in een nieuwe computer moeten zetten. Dan zouden al die mensen met legacy software WEL een goede reden hebben om een nieuwe computer te kopen.

Ik zie die olifant met planned obsolescense via het stoppen met Rosette niet zo...

[ultimasnake]

Zolang support erin zit zullen sommige developers de moeite niet nemen de overstap te maken, uiteindelijks is een duidelijk end of life ook gewoon nodig voor de volgende fase.

Of het kwaad kan in lagen in het os of ‘ruimte’ op de processor, geen iddd

[Keypunchie]

Het wat meer “rucksichtlose” laten vallen stimuleert de developers om met hun tijd mee te gaan.

Bij Microsoft en Windows zie je namelijk het omgekeerde ook wel: developers die nooit een poot uitsteken, omdat ze op de “backward compatibility” leunen.

En dat betekent dat ze ook nooit nieuwe features omarmen, en dat je op je kersverse machine nog steeds naar een jaar kruik interface zit te kijken. Wat dat betreft bevalt het Apple ecosysteem mij iets beter, omdat je merkt dat ontwikkelaars actiever zijn.

Het is uiteraard een balanceer-act, hoe het niet moet liet Microsoft ook weer zien, met hun mobiele OS, als je elke 2 jaar alle compatibiliteit weggooit, dan heeft geen developer er meer zin in.

[Remzi1993]

Bij Microsoft en Windows zie je namelijk het omgekeerde ook wel: developers die nooit een poot uitsteken, omdat ze op de “backward compatibility” leunen.

Je bedoelt management die daar de waarde (geld erin stoppen) niet van inziet? Want ik als developer ga daar niet over. Er is enorm veel technical debt overal en bijna bij alle organisaties simpelweg door korte termijn denken wat erg versterkt wordt door het kapitalistische systeem van oneindige groei en hebzucht.

[feuniks]

Hier kun je op meerdere manieren naar kijken:
- Laten we beginnen te stellen dat elk feature, elke functie, elke regel code die in je software of besturingssysteem zit onderhouden moet worden en dus geld kost. Apple kan wel zeggen dat ze het erin laten, maar as-is, maar wat doe je als er een lek in die code zit, die code het systeem vertraagt of het hele systeem laat crashen? Dat kun je ook niet maken als, in dit geval, Apple zijnde. Het is dus erin laten zitten en bijhouden of eruit halen.
- Zo lang je het erin laat, geef je de ontwikkelaars een "optie". Ze hoeven nog niets, dus ze kunnen het aanpassen van hun software zo lang mogelijk uitstellen, want het draait toch onder Rosetta. Ombouwen kost tijd en dus geld. Dat doe je dus alleen als het echt moet of als je toch al heel veel en grote aanpassingen aan het maken bent. Nu weten de ontwikkelaars, wanneer het OS hun software niet meer ondersteunt en dat ze dus nu aan de bak moeten.
- De andere kant van deze medaille is natuurlijk software waar geen nieuwe versie van uit gaat komen. Ik heb hier software draaien waar al heel wat jaren geen nieuwe versie van uit is gekomen en die er ook niet gaat komen, omdat de maker ermee gestopt is (soms met het product, soms de hele maker). Dit soort software stopt dan gewoon met werken, omdat het OS het gewoonweg niet meer ondersteunt.

[Stroper]

Niet-onderhouden software wil ook zeggen potentiële bugs niet gefixt worden, er niks aan verbeterd wordt.

Bovendien maakt het je OS extra complex als je al die legacy-zooi moet blijven onderhouden in nieuwe versies(wat weer voor mogelijke bugs/aanvalsvectoren zorgt).

Het is in weze de omgekeerde filosofie vsn Windows, waarbij backwards compatible bijna een gebod is.

Ieder zijn eigen mening, maar als Mac-gebruiker verkies ik toch het eerste.

[Borgia]

Kost geld, levert weinig of niets op.

[Arjan242]

Hoi, hier een hele domme apple macbook m2 gebruiker. Kan ik straks dan wel spellen c&c and halflife draaien op mijn simpele m2 mac?

[Guru Evi]

Mijn M1 is nu al bijna 5 jaar oud, Tahoe is nog niet uit en dan krijg je nog 2 verdere versies met Rosetta en dan de laatste versie krijgt 3 jaar ondersteuning. Tijd gaat snel deze dagen, Rosetta 2 zal grofweg 10 jaar lang meegaan, genoeg tijd voor app developers, en daarnaast gaat QEMU nog altijd mee als je echt ‘een 386’ wilt.

[CAPSLOCK2000]

Mooi dat er een native versie is, maar "Die vertaallaag gaat ten koste van de prestaties, waardoor het navigeren door Steam trager verloopt." snap ik eigenlijk niet, dat klinkt als dichterlijke vrijheid van Valve. Het klopt in theorie, maar was dat in praktijk merkbaar? Zo zwaar is die Steam client toch niet?
Als de Steam client draaien al te zwaar is voor een vloeiende ervaring dan zou gamen onmogelijk moeten zijn.

[Wolfos]

Ja, de Steam client is een webbrowser en die zijn disproportioneel zwaar voor Rosetta. In games merk je dat minder. Steam is echt merkbaar traag.

[Reactie gewijzigd door Wolfos op 14 juni 2025 13:50]

[bzzzt]

Klopt, maar aan de andere kant heb je ook geen 60+fps nodig om een game shop te browsen en geeft het weinig praktische beperkingen.

[AMDLegion]

Kan je uitleggen waarom inferieure performance oke is?

[bzzzt]

Het is 'oke' voor Valve in de zin dat het niemand beperkt om games aan te schaffen.
Natuurlijk is meer performance altijd beter, maar vind het volstrekt redelijk dat Valve dit niet als nr 1 op de prio lijst had staan omdat de Apple markt voor games klein is en het aandeel M-serie Macs nog kleiner was. Zo'n port actie kan afhankelijk van de bestaande codebase toch echt wel een paar maanden werk zijn wat betekent dat ze er een paar ton armer van worden.

[Reactie gewijzigd door bzzzt op 14 juni 2025 15:30]

[Ricco02]

Is MacOS 26 niet de laatste versie met Rosetta 2?

Denk eerder dat dat de reden is. Om de Steam applicatie uberhaupt op Mac te houden moeten ze een native app bouwen.

[xFeverr]

dat heb ik nog niet langs zien komen. Alleen dat het de laatste versie is die op Intel werkt. Maar dat zijn twee losstaande dingen.

[lepel]

Staat in het artikel:

Vorige week gaf Apple al aan dat de aankomende macOS-versie, 26 Tahoe, de laatste is voor oudere Mac-computers met een Intel-cpu. Tegelijkertijd is het bedrijf van plan om Rosetta 2 binnen twee jaar grotendeels uit te faseren.

Dus niet de laatste versie, maar het komt er wel aan.

[Reactie gewijzigd door lepel op 14 juni 2025 18:42]

[AMDLegion]

Oh eens

[Krulsprietje]

If it works, don’t fix it misschien?

[jabwd]

Toen Steam voor de mac uit kwam wisten ze niet eens dat objective-c++ een ding was dus zaten ze direct te spelen met IOKit. Ik weet niet wat de huidige status is maar ik denk niet dat het veel beter zal zijn. Er is echt een verschil tussen 60fps en gewoon een batterij leegzuigen door je muis te bewegen.

[codeneos]

Volgens mij is het Objective-C en niet C++. Beide zijn een superset boven op C maar zijn zeker niet hetzelfde. Objective-C++ is geen programeer taal.

Ik snap ook niet helemaal hoe het gebruik maken van IOkit het gebruik van Objective-C uit zou suiten.

Veder denk ik dat Vavle behoorlijk developers heeft die ook ervaringen hebben met Mac en Objective-C en andere *mix like platforms. Zie bijvoorbeeld SteamOS.

[Reactie gewijzigd door codeneos op 14 juni 2025 22:29]

[jabwd]

Tegenwoordig misschien ja, maar in die tijd was het letterlijk een revelatie voor de mensen die aan Steam voor macOS werkte want heb prettig met ze gechat.

Objective-C++ is gewoon de term voor de smaak van Objective-C die met C++ based classes kan werken, waar Steam voornamelijk in geschreven is en hun reden om niet Cocoa te werken.

IOKit is trouwens voornamelijk C++, er zijn inderdaad wat hogere interfaces beschikbaar. Ook de reden dan Swift integratie met C++ zo interessant is want ben heel benieuwd hoe het platform zich gaat ontwikkelen eromheen.

[Reactie gewijzigd door jabwd op 15 juni 2025 00:54]

[bzzzt]

Er is echt een verschil tussen 60fps en gewoon een batterij leegzuigen door je muis te bewegen.

Je kan het ook overdrijven. De huidige (Intel) versie van Steam blijft in de single-digits qua CPU gebruik op mijn M2 mini. Nou vind ik 5% CPU load voor iets wat effectief idle is wel wat hoger dan nodig, maar kan me nauwelijks voorstellen dat dit op een laptop de batterij 'leegzuigt'...

[Oon]

Precies dit mis ik ook even, maar misschien dat ze hiermee dan ook Big Screen en SteamVR bedoelen? Die zijn wel wat intensiever

[svenk91]

De steam client (en de website) zijn volgens mij best logge applicaties. Dan de extra performance hit, al is die misschien klein, door een emulatie laag en het zorgt ervoor dat Steam gewoon echt niet soepel aanvoelt.

[adamvansanten]

De steam client op MacOS is echt extreem traag (in ieder geval op een M1). Alleen opstarten duurt al tientallen seconden. Veruit de traagste applicatie op mijn Macbook. Dus deze nieuwe versie is zeer welkom!

[jaenster]

Het valt mij persoonlijk niet zo op, merk het niet echt. Heb wel andere issues met steam @ macos, maar dit is er niet een van. Dat neemt niet weg dat meer native meer beter is

[AMDLegion]

Dit was oprecht heel merkbaar ( voor mij ) en zit nu 2 dagen op de beta waardoor je deze native versie krijgt en ik merk een groot verschil

[Jeffrey2107]

De Steam client is best wel een zwaar programma. Het is min of meer Chromium in vermomming met wat extra andere tools eromheen.

Als je er eerlijk naar kijkt qua prestaties is de Steam client best slecht. Dit werdt op Mac OS op ARM nog veel duidelijker. Heb video's gezien van de opstarttijd die letterlijk gehalveerd is met deze native ARM client.

Alleen weer jammer dat dit soort optimalisaties nooit echt naar andere platforms komen. Leuk dat Mac nu een 64bit ARM client heeft maar windows en linux moeten het nog steeds met het slome ding doen.

[jaenster]

Ze gaan niks veranderen aan de app, die chromium zonder addressbalk draait natuurlijk al prima op arm64. Wat ik vermoed (100% onderbuik) is dat ze wat trucs uithalen met native v8/node modules om dingen als overlays in een spel voor elkaar te krijgen. En die, zijn waarschijnlijk niet geschikt voor arm

[Elaborate8455]

Het zou vet zijn als ze proton werkend kregen op de Mac! Zou Valve veel geld mee kunnen verdienen!

[rubenvb]

Wine (en dus waarschijnlijk ook Proton) werkt op macOS dus in principe is het een kwestie van alles compileren en de mogelijke macOS-specifieke akkefietjes oplossen.

Natuurlijk werkt Wine (en dus Proton) enkel voor x86, en zit daar op geen enkele manier een aarch64 emulator in. Daarvoor heb je op Linux Box64 en FEX-Emu. Ik heb weinig success gehad toen ik een niet-game applicatie wilde runnen op mijn NanoPi M4, misschien dat dit voor Valve een optie is.
Let wel dat de meeste games geen native aarch64 versie hebben, waardoor je dus terugvalt op een emulatie zoals Rosetta, maar dan hoogstwaarschijnlijk minder efficiënt. Hoewel Box64 een heel interessante aanpak heeft (die vooralsnog héél Linux-specifiek is): ze gebruiken zo veel mogelijk native libraries en doen wat black magic als een x86 applicatie een aarch64 library oproept. In principe heb je dan near-native performance voor al die dingen, wat erg cool is.

[PureTryOut]

Even een correctie, Wine ondersteunt prima ARM. Het kan op ARM echter alleen maar ARM Windows applicaties draaien, en die zijn er vrijwel niet. Zeker geen games in ieder geval.

[mickjuh]

Vergeet CrossOver niet. Deze gebruik ik bijna dagelijks. Werkt soms verassend goed voor DirectX 12 games

[michelb76]

Kun je wat voorbeelden geven? Ik heb niet veel succes nog met Crossover.

[mickjuh]

Ik draai Ubisoft Connect met daarin bijvoorbeeld Avatar. Maar heb ook Steam gedraaid met Metro Exodus.

[Anactia]

Niet dat het uiteindelijk veel uitmaakt want er zijn toch vrij weinig games die native voor macOS uitkomen, en als ze dat al doen, is de macOS version een Mac App Store exclusief omdat Apple meebetaald heeft aan de port, dus het grootste gedeelte van de games draai ik dan toch uiteindelijk via Crossover/Wine, die sowieso gebruik maakt van Rosetta.

[WernerL]

Heeft de Apple-versie geen compatibility-mode (Proton) aan boord waarmee je vanuit Steam via Wine kunt spelen? Want dat is hoe ik al mijn games in Linux speel. Ook de games die niet officieel ondersteund worden op Linux. Gaat bij singleplayer games eigenlijk bijna altijd wel goed.

[nandervv]

Nee, Mac OS heeft geen proton.

Mac en games is lachwekkend slechter dan linux en games

[VeterisVulpes]

Probeer eens het gratis Porting kit. ;-)

[1Mark]

Op zich werkt dat best goed (en al die translation layers samen kosten niet eens gek veel overhead..), maar de Game Porting Tool Kit is nog wel bewerkelijk qua user experience voor degenen die er mee willen gamen (ipv als developer gebruiken als porting kit)

[Wraldpyk]

Ik heb CrossOver als applicatie, en daarbinnen heb ik Steam Windows versie geinstalleerd. Vrijwel alle spellen werken soepel en bug-vrij op mijn M1 mac. CrossOver is net als Proton een vertaal-laag en niet emulatie.

[armageddon_2k1]

Ik heb echt tientallen mac games die ik buiten de App Store om gewoon via Steam heb

[rbr320]

Games die gebouwd zijn voor de Intel architectuur ja. Als Apple straks stopt met het ondersteunen van Rosetta2 kan je deze games niet meer spelen op je Mac met Apple Silicon, want dat is gebaseerd op de ARM architectuur

[InsanelyHack]

En waarom zouden ze dat doen stoppen met het ondersteunen van Rosetta2?

[rbr320]

Dat staat gewoon in het artikel.

Vorige week gaf Apple al aan dat de aankomende macOS-versie, 26 Tahoe, de laatste is voor oudere Mac-computers met een Intel-cpu. Tegelijkertijd is het bedrijf van plan om Rosetta 2 binnen twee jaar grotendeels uit te faseren.

[InsanelyHack]

Je hebt helemaal gelijk. Het wordt ècht een probleem op de macs die met macOS 28 worden geleverd. De m1 t/m m4 werden met een lagere initiële macOS versie geleverd en kunnen dus altijd een lagere versie dan macOS 28 in dualboot installeren. Optimaal? Nee maar het blijft gewoon werkbaar. In Rosetta 2 zit niet veel verandering. Hoe het nu werkt is prima voor bijna alle intel apps.

[Sjah]

Ja luistert dat zo nauw, is er dan geen overeenkomst waardoor een game toch met weinig moeite draaiende kan worden gemaakt?

[rbr320]

ARM is een volledig andere instructieset dan x86. Je hebt dus op z'n minst een vertaallaag als Rosetta2 nodig om het werkend te krijgen. Een andere optie is om de binaries opnieuw te compileren.

[bzzzt]

Het probleem met opnieuw compileren zit er vooral in dat games vaak gebruik maken van allerlei libraries die ook op de juiste instructieset moeten zitten. Bij oudere games lopen dat soort libraries vaak ontzettend achter dus betekent het porten gelijk dat de hele game enige gemoderniseerd moet worden. Zeker als het geld al lang verdiend is kan zo'n investering niet uit.

[rbr320]

Klopt, met andere woorden: @armageddon_2k1 kan de native MacOS games die hij nu via Steam heeft straks niet meer spelen op zijn Apple Silicon Mac met MacOS 27 of hoger, want die gaan nooit voor ARM geupdate worden en zijn afhankelijk van Rosetta2, wat Apple gaat uitfaseren..

[Reactie gewijzigd door rbr320 op 16 juni 2025 14:43]

[bzzzt]

Pas bij macOS 28, en zelfs dan houdt Apple nog een deurtje open:
"At WWDC 2025, Apple stated that most Rosetta 2 features will be removed from macOS with version 28 in 2027, with support limited to unmaintained games."
(bron: wikipedia)

[Keyb]

Hmnm heb ik dan die upgrade nog niet binnen, of blijft die steam client erg traag op m'n mac.

[JWL92]

de recentste Steam Client-bèta.

[nelizmastr]

Het is de laatste beta. Als je geen beta aanzet krijg je de update nog niet.

[RoyReyn]

Juiste zet van Valve. Apple investeerder steeds meer tijd en geld in gaming en juist nu is het slim van Valve om weer te investeren in het Apple ecosysteem. Met de investeringen van Apple denk ik dat gaming op macOS steeds groter zal worden. Valve is er gewoon vroeg bij!

[SuperDre]

Nou, gaming op Apple hardware is echt verwaarloosbaar op Steam, dus dat beetje extra zal weinig met zich meebrengen. Want leuk dat Valve nu hun client native heeft (wat natuurlijk eigenlijk amper een prestatie is), maar dan moeten er ook genoeg games zijn.

[Don Corleone]

Hopelijk krijgen we nu ook native drivers voor controllers.

[bzzzt]

MacOS heeft al lang controller support. Mac ports van games ondersteunen ze alleen heel vaak niet.

[Don Corleone]

Ja dat weet ik, maar bijvoorbeeld De PS5 controller werkt niet goed in steam. Steam probeert een driver te installeren maar die werkt niet.

[bzzzt]

Wat heeft Steam te maken met OS support voor controllers?

[nielsnederveen]

Dat uitfaseren van Rosetta vind ik wel jammer. Ik vraag mij af hoe Crossover zonder die laag functioneert? Zo nu en dan speel toch wel eens een Windows spelletje op mijn Mac.

[arjan1995]

CrossOver gebruikt het voor de initiële vertaling van X86 naar ARM. Daarboven op heeft het support voor de windows-api zodat windows spelletjes op een Mac kunnen draaien. Dat zijn dus wel x86 / x64 windows spelletjes.

Zonder rosetta zou het nu alleen arm windows spelletjes kunnen draaien, en die zijn er (bijna) niet. Dan zouden ze dus iets anders moeten vinden voor de x86 -> ARM emulatie.

[Wolfos]

1,85% van de Steam gebruikers volgens de laatste hardware survey.

Dat klinkt als weinig, maar dat is even twee miljoen maandelijkse gebruikers en als we dat even doortrekken ruim honderd miljoen dollar aan omzet.

[rbr320]

Je hebt natuurlijk gelijk, maar Linux gebruikers hebben 3 keer dat marktaandeel en krijgen al jaren te horen dat native ports financieel niet uit kunnen. Dus ik ben bang dat het native beschikbaar zijn van de Steam client op arm Macs geen verschil gaat maken

[thedicemaster]

native ports van spellen zijn ook niet echt nodig met een goede vertaal laag.

onder linux met proton draaien veel windows spellen al beter dan onder windows, een native port is dan verspilde moeite.

ik heb weinig ervaring met Mac, dus ik weet niet hoe goed daar alles geregeld is.

[Wolfos]

Ontwikkelaars gaan niet vaker porten naar deze platforms, nee. Maar er zijn best wat games beschikbaar en vanuit het oogpunt van Steam is goede ondersteuning gewoon logisch.

[Jeffrey2107]

Is het ook wel zo dat Linux elke update half breekt qua games en dat de devs niet zitten te wachten op de enorme lading tickets die van Linux komen.

En nee dat laatste is niet eens omdat Linux zo slecht is. Meer omdat Linux gebruikers veel sneller tickets maken terwijl Windows en Mac OS gebruikers dat niet zo snel doen.

[rbr320]

Is het ook wel zo dat Linux elke update half breekt qua games

Bron? Want in mijn jaren ervaring is dit helemaal niet waar. Mijn vrienden die op Windows gamen hebben veel vaker issues na updates.

en dat de devs niet zitten te wachten op de enorme lading tickets die van Linux komen.

Of misschien juist wel? Elke ontwikkelaar wil toch het liefst bug-vrije software opleveren?

En nee dat laatste is niet eens omdat Linux zo slecht is. Meer omdat Linux gebruikers veel sneller tickets maken terwijl Windows en Mac OS gebruikers dat niet zo snel doen.

Niet alleen dat, ze maken ook kwalitatief betere tickets omdat Linux gebruikers vaak meer affiniteit hebben met computers en het debuggen van fouten. Dit is een leuke anekdote betreffende het onderwerp: https://www.reddit.com/r/..._58_sales_over_38_of_bug/

[Jeffrey2107]

nou ja de eniste stable ABI op Linux is Win32. Dependency hell is een ding. etc.

En je zou denken dat die devs die tickets willen om betere software te maken. Maar je vergeet dat het een hele lading tickets is voor een enorm kleine groep. Dus nee.

[rbr320]

nou ja de eniste stable ABI op Linux is Win32. Dependency hell is een ding. etc.

Sorry maar nee. Het mantra dat Linus zijn mede-kernelontwikkelaars altijd op legt is "we do not break user space", of zoals hij het zelf ooit heeft gezegd:

Breaking user programs simply isn't acceptable. [...] We know that people use old binaries for years and years, and that making a new release doesn't mean that you can just throw that out. You can trust us.

Kortom, de Linux kernel API en ABI voor niet-kernel software zoals games zijn super stabiel. De meeste games leveren daarnaast gewoon zelf de libraries mee waar ze van afhankelijk zijn, dat gebeurd op Windows ook. Als je op Steam publiceert voor Linux kan je in plaats daarvan ook de Steam Linux Runtime gebruiken, een vaste set libraries die niet meer wijzigt. Hiervan komt af en toe wel een nieuwe versie uit, maar de oude versies blijven gewoon beschikbaar via Steam.

En je zou denken dat die devs die tickets willen om betere software te maken. Maar je vergeet dat het een hele lading tickets is voor een enorm kleine groep. Dus nee.

Jij hebt duidelijk de Reddit post achter de link niet (goed/helemaal) gelezen. Het punt is nu juist dat het overgrote deel van de bugs waarover Linux gebruikers tickets aanmaken, helemaal niet platform specifiek zijn. Dus Linux gebruikers vinden bugs die ook de Windows gebruikers zouden treffen, maar met voldoende informatie om er ook daadwerkelijk iets aan te doen in plaats van tickets als "this is bugged" of "it crashes" die je meteen weer kunt afsluiten omdat je er niets aan hebt. Het is dus geen enorm kleine groep vervelende gebruikers, maar een groep gratis software testers met een omvang die zelf grote game-studios zich nooit zou kunnen veroorloven als ze ze zouden moeten betalen.

[Reactie gewijzigd door rbr320 op 16 juni 2025 15:01]

[Thonz]

Het lijkt erop dat steam/apple dingen weten/voorzien waar jij (nog) geen oog voor hebt.

[lenwar]

Dat, of Steam loopt gewoon netjes vooruit op het feit dat de rosetta-laag uit gaat. Wanneer dat stopt, kan Steam niet meer gebruikt worden, en dat is niet praktisch voor een winkel

[SwaggyEggs]

Apple zal er alles aan doen om steam geen succes te laten worden op hun platform. Die apple tax is gewoon te juicy.

[svenk91]

Hoe houden ze Steam tegen dan? Volgens mij worden die geen haar in de weg gelegen op MacOS?

[bzzzt]

Sterker nog: Apple heeft in 2010 samen met Valve en onder grote fanfare Steam voor Mac aangekondigd en ook behoorlijk geholpen door bv graphics drivers voor macOS eens fatsoenlijk te optimaliseren (wat daarvoor echt huilen was kwam redelijk 'on par' met Windows al hebben ze dat nooit in weten te halen).

Wat niet heeft geholpen is het vervallen van support voor 32 bits Intel binaries met macOS Catalina in 2019. Vrijwel alle Mac ports op Steam waren indie of oudere games die gebruik maakten van 32 bits code. Had in die tijd een aardige library opgebouwd ivm Humble bundles e.d. waarvan het overgrote deel ook prima op macOS draaide. Na Catalina dus niet meer.
Hetzelfde gaan we nu weer zien met games die niet naar ARM zijn geport (voor games die nauwelijks meer verkopen kan zo'n ombouw actie echt niet uit).

Ik schrijf het toe aan de complete desinteresse van Apple voor legacy support. Meerdere CPU transities bewijzen wel dat als je geen 30 jaar aan legacy code hoeft te ondersteunen dat vrij soepel kan, maar de prijs is dat software een houdbaarheidsdatum heeft.
Ik denk ook niet dat Apple specifiek Steam tegenhoudt, alleen dat het bedrijf weinig interesse heeft in 'drop and forget' softwarebouwers die feitelijk Apple verantwoordelijk proberen te maken voor het onderhouden van legacy ondersteuning.

[TheVivaldi]

30 jaar hoeft wat mij betreft ook niet, maar iets langer dan nu zou wel handig zijn.

[Thonz]

Ik heb nog menig potje tf2 gespeeld op mijn early 2105 mbp!

[aikebah]

Dus tijdreizen naar het verleden gaat mogelijk worden in de toekomst en in 2105 bestaat apple nog steeds

[Thonz]

gesnapt!

[bzzzt]

Onzin, tenzij Apple alle mogelijkheden third-party software op macOS op te starten zou blokkeren en dat doen ze niet. De rel die ze dan over zich afroepen is veel groter dan de minimale game markt voor macOS...

[TheVivaldi]

Waarom zouden ze dat niet doen? Op iOS, macOS, tvOS, etc. hebben ze sideloading ook heel lang geblokkeerd en nog steeds met beperkingen nu.

[CharlesND]

Waarom zouden ze dat niet doen? Op iOS, macOS, tvOS, etc. hebben ze sideloading ook heel lang geblokkeerd en nog steeds met beperkingen nu.

Ja , op mijn desktop met macOS was het altijd onmogelijk om iets buiten de appstore te downloaden. Adobe, Microsoft, Google, alles geblokkeerd op mijn MacPro!

Vals nootje, Vivaldi.

[TheVivaldi]

Ik bedoel meer dat het vanuit Apple gezien een logische stap zou zijn om macOS ook op die manier dicht te timmeren. Je ziet de beginselen daar al van: voorheen kon je ‘gewoon’ iets buiten de appstore installeren; nu moet je al een toets ingedrukt houden om dat te kunnen doen.

[bzzzt]

macOS is sinds dag 1 open geweest voor het installeren van eigen software of software van derden, dus in die zin is het geen logische stap om dat dicht te timmeren. Apple krijgt al bijzonder aandacht vanwege marktwetgeving dus denk niet dat ze de diverse overheden graag nog meer munitie geven.

Het installeren van software 'lastiger' maken heeft een heel andere reden: niet alle software 'leveranciers' zijn te goeder trouw. Dat het installeren van software uit volstrekt onbekende bron een drempel krijgt is ook in het voordeel van gebruikers. Voor een voor bedrijven verwaarloosbaar bedrag kunnen ze zich bij Apple registreren voor een developer certificaat waardoor die drempel wegvalt.

[lenwar]

Precies. Maar Apple wil het hebben. Ze willen de Apple Tax hebben op hun platform, niet dat Steam, de Steam Tax heeft.

Overigens haal ik niet uit het artikel dat Apple hier ook maar iets mee te maken heeft (met het feit dat Steam nu ook de ARM-cpu's van Apple native gaat ondersteunen), dus ik denk zelf niet dat ze actief Steam geen succes proberen te laten zijn.

[SG]

Je kan het ook zo zien die andere willen 100% binnen harken en delen ho maar.
Vs apple tax.
Dit zijn dingen die het glas is half vol vs half leeg.
En de bais bepaald hoe het gezien wordt. En daar in hebben bedrijven onderling andere kijk dan ook consumenten die ook bais. Hebben en subjectief.

Dat consoles gesloten zijn is normaal, maar zelfde verdien model wat apple aanhoud.

Valve maakt enorme omzet met hun steam. Blijkbaar willen ze nog meer binnen harken en niet delen. Denk je nou echt dat zij het voor de consumenten doen. Dit zijn corporaties die clashen dus valve vs apple en valve vs windows.
Valve wil zijn eigen platform en timmert hard aan linux.

Core game platformen zijn nog steed consoles en windows. 1001 pro valve linux meldingen zou denken dat linux pool positie heeft maar dat valt vies tegen.
Ik merk dat anti whatever forums gelobby en gespui aanzienlijk is en de windows en appla haters linux en valve ophemelen. Maar mainstream die je niet hoort gamed massaal op Ps4 ps5 nintonde xbox en windows pc met g-kaart.

Wil je platform echt pushen en dat doen console het hards is tripple A exclusive.
Dus willen Valve en apple hun platform zwaar pushen zullen met exclusive lijn komen.

Want de mainstream gamer moet op linux en apple een must have game zien. Naast ook zware marketing voor awareness bij grote publiek. Valve is gamedev van oorsprong dus verbaas mij dat ze dat niet doen. Ze hebben zelf grote IP. Apple zou 5 studio moeten op zetten die elk grote tripple A game produceren en apple zou ook wat game IP kunnen binnen halen .
Maar als apple silicon meer game capabel moet zijn zullen ze de Asoc en M standaard de gpu cores moeten verhogen.
M-max heeft bandbreedte van PS5 en dikke igpu. Msoc standaard is 1/3 1/4 daarvan.
Meer bandbreedte en igpu in lagere tier soc.s

[lenwar]

Je hebt helemaal gelijk natuurlijk. Alle corporates (zowel Apple als Valve) willen allemaal winstmaximalisatie, en bij voorkeur omzet weghalen bij de potentiële concurrent.

De vergelijking met de consoles gaat in de praktijk maar deels op. En dat deels is voornamelijk 'het gevoel.' / 'de gewenning.' Van een PC (of dat nou een Apple/Linux/BSD/Microsoft/iets anders is), zijn we gewend dat we er zelf (via derden) software op kunnen zetten.
Bij een gamingconsole zijn we dat niet gewend. Technisch gezien is een gaming console natuurlijk ook een soort pc met een beperkte interface. De PS5 draait schijnbaar op FreeBSD 11 (en dan laten we even in het midden of dat een desktop of Server-OS is.) en de XBOX draait als het goed op Windows. Beiden natuurlijk zwaar getweakt en geminimaliseerd tot wat er nodig is voor het platform, maar technisch is er (dus) geen reden voor om geen software via derden te kunnen laten draaien, maar door de gewennig, lijken we (de mainstream) dit te accepteren.

Mijn reactie was ook puur op de aanval richting Apple over hun 'Apple Tax'. Valve wil ook graag hun 'Valve Tax'. (ofwel, beide platformen willen geld voor hun dienstverlening, die al dan niet wat toevoegt voor de speler/leverancier)

[ImperatorTiber]

Dat is het punt: men wil kiezen tussen stores, ipv vastzitten aan eentje en alleen aan hun de tax betalen.