Hacker News Reader

Comment by dagmx | Hacker News Reader

Games use a very small portion of the native frameworks. Most would be covered by Foundation, which they have to keep working for Swift anyway (Foundation is being rewritten in Swift) and just enough to present a window + handle inputs. D3DMetal and the other translation layers remove the need to keep Metal around.

That’s a much smaller target of things to keep running on Intel than the whole shebang that they need to right now to support Rosetta.

View on HN

I don’t agree. My point is their collective footprint in terms of the macOS API surface (at least as of 2019 or so) is pretty big. I’m not just speculating here, I work in this area so I have a pretty good idea of what is used.

Could you give examples at least of what you think that big collective footprint might include?

Bear in mind that a large chunk of Mac gaming right now that needs translation are windows games translated via crossover.

As I said in my first comment, it's at least Cocoa (Foundation + AppKit), AVFoundation, Metal, OpenGL, and then all of the lower level frameworks and libraries those depend on (which may or may not be used directly by individual games). If you want a concrete example from something open source, go look at what SDL depends on, it's everything I listed and then some. It's also not uncommon for games to have launchers or startup windows that contain additional native UI, so assume you really do need all of AppKit, you couldn't get away with cutting out something like NSTableView or whatever.

So my point remains, if Apple has to continue providing Intel builds of all of these frameworks, that means a lot of other apps could also continue to run. But ... Apple says they won't, so how are they going to accomplish this? That's the mystery to me.

With the exception of AVFoundation, I’d covered all of those in my comments. That’s not a lot of surface area. Games are typically not using a significant portion of AppKit beyond what I already mentioned, and AVFoundation is likely also a very thin wrapper that is maintainable.

I’m assuming Apple isn’t going to arbitrarily restrict what runs but will remove things to just the subset that they believe are needed for games such that other stuff just implicitly won’t work.

Is it practical for Apple to produce a set of frameworks for Intel that run some useful set of old games but that do not run any useful set of non game software?

I grant it’s probably possible to do, but I think that is a lot more work and more error prone than just continuing to ship the major frameworks as they were.

From Apple’s perspective I’m sure they have a few big goals here:

1. Encourage anyone who wants to continue offering software on Mac to update their builds to include arm64.

2. Reduce download size, on disk size, and memory use of macOS.

3. Reduce QA burden of testing ancient 3rd party software.

These are also the same motivations Apple had when they eliminated 32 bit Intel and when they eliminated Rosetta 1, but they were criticized especially for leaving behind game libraries.

Arguably, arbitrarily restricting what runs gets them the biggest slice of their goals with the minimum work. Devs are given the stick. People typically only play 1 game at a time and then quit it, so there isn’t a bunch of Intel code in RAM all the time because of a few small apps hanging out, and they have less to test because it’s a finite set of games. It just will chafe because if they do that then you know that some unblessed software could run but Apple is just preventing it to make their lives easier.

> Is it practical for Apple to produce a set of frameworks for Intel that run some useful set of old games but that do not run any useful set of non game software?

They already have the frameworks supporting intel. They can just start pruning away.

Some teams will draw the short straw of what needs to continue being supported, but it’s likely a very small subset of what they already maintain today.

Reply on news.ycombinator.com