But wasn’t macOS the only major gaming-relevant platform still using OpenGL anyway? If you’re already writing a Mac-specific backend, why not just write directly for Metal instead of OpenGL? Or, at the least, write for Vulkan and use a translation layer like MoltenVK?

Poster specifically mentioned CS3, which was a perpetual license. Adobe is not incentivized to keep a version of their software someone purchased once seventeen years ago working when they would much rather sell a monthly subscription.

Going from DirectX to Vulkan to Metal is simply too many translation layers to work well. You're almost always going to end up with an annoying bottleneck and poor hardware utilization. MoltenVK alone might be fine if Vulkan was more widely supported by shipping games.

I think it's more plausible that Valve decides to make a Proton for Mac using the D3D to Metal translation layer from Apple's Game Porting Toolkit—but that would be going against Apple's intended purpose for the toolkit.

I don't know, this is just stuff I heard, but I think some of it is Valve just being _annoyed_. Like Apple made this choice despite reaching a point where the highest end graphics card they ship is equivalent to a high-end... laptop graphics card! You shouldn't be in charge of a thing if you're not going to cover a wide spectrum.

At least with USB-C Apple "donated" their designs.

What about Game Porting Toolkit? To be honest I feel like that's resulted in fewer native ports and more Mac players enjoying the x86 library that would never be ported natively.

I don't think so, but no Mac before 2016 can run 13.x: https://everymac.com/systems/by_capability/maximum-macos-sup...

EOL or no, there are many people who still use older OSes because they own older computers, can't afford an upgrade or don't want one (it works just fine!), and can't be bothered with figuring out running a newer OS on officially unsupported hardware.

Case in point: I built a macOS app that implements Google's Nearby/Quick Share (an AirDrop-style file sharing thing on Android). Multiple people tried running it on Catalina and were disappointed that it wanted a newer OS. So I did end up backporting it to Catalina.

>Very few apps still support it

Citation? I use Monterey at work and every app I need works on it still.

Any tutorial?

Virtualizing older macOS on M4 hardware has nothing to do with Rosetta 2. And it would be ridiculous for Apple to remove hardware features that Rosetta 2 relies upon before they're actually ready to retire Rosetta 2—that would force Apple to invest more software engineering effort in updating Rosetta 2 to work without those features.

Unless you work at Apple, none of us outsiders have even been able to look up other people's bug reports

(insert name of any corporation ... listed on any stock market) just really doesn't care about you, and as a developer, you're just a sucker to extract money from.

Realistically you can run more than 2 VMs with some work[0], but legally companies that provide CI and other virtual solutions can't buy 1 mac then get a license to run 100 virtual macs.

0: https://khronokernel.com/macos/2023/08/08/AS-VM.html

the community has been joking that win32 is the most stable Linux api

Back when IDA Pro for Linux & macOS was finally released, they decided to make every OS a separate license purchase. The net result of this was that every single person I knew who used it just kept buying Windows licenses and using it under WINE when they wanted to use it on their other computers.

Linux (the ecosystem; not necessarily the kernel) is actively hostile to binary software.

In addition to this, Steam provides an option for developers to expose the older game versions to the players, which Valve themselves make an active use of. So if you have a specific old mod that’s not compatible with the new update, or don’t want to deal with the update in a middle of playthrough, you don’t have to upgrade

Maintaining the build artifacts and pipelines and testing backward compatibility for a long-lived project like HL2 must be pretty difficult, I would think? That’s a great example and counterpoint.

Maybe I'm missing something but I run SQL Server in Docker under Windows WSL2 at near native speed.

What's the competitive advantage here?

Perhaps there will be an intermediate step where they drop support for x86-64 executables, but retain support for x86-64 virtualization. That would still let Apple slim down the macOS system frameworks to a single architecture like they did previously when they dropped the x86-32 frameworks.

As a consumer, yes. Old steam games are a big deal.

In business... not where I work, but I hear stories of shops that still have lots of old 32-bit COM stuff, etc.

Intel has proposed dropping 32-bit and 16-bit support in the future.

https://www.intel.com/content/www/us/en/developer/articles/t...

On windows, a lot of installers are 32-bit even if the application they're installing is 64-bit so that they can fail gracefully on 32-bit OSes.

32-bit applications are still pretty ubiquitous, including Office add-ins, and there is no particular benefit on x86 in removing support for 32-bit on the application side.

Yes

> Old phones no, but old apps yes. If a developer has abandoned an app and hasn't been investing in the update treadmill, but end users still care about it, that can make people feel negatively about Apple.

On the other hand, it is well within the standard Apple approach to say "here's how we want people to use our hardware. We are well aware that this is not consistent with how some potential and past users want to use the hardware, but we are comfortable with losing those customers if they will not adapt to the new set-up."

> remarkable thing is that 90% of listeners don’t seem to notice

That's not a remarkable thing, it's the reason.

(And out of the remaining 10%, a good fraction may notice but prefer the new convenience. Those who remain can find the difference between most and all, or go corded.)

>Their reference point is a lossy 128kb/s file from a streaming service double transcoded over bluetooth so that must be what music sounds like. Who would have thought technology would progress backwards.

The only major streaming service that doesn't do lossless is Spotify.

Further just about no one is going to be able to tell the 256kb/s AAC that the iPhone sends to headphones across bluetooth from the lossless audio file.

Also, portable headphones have progressed leaps and bound since 2005 and they'll all basically sound better playing over bluetooth than the portable headphones that were out in 2005.

What streaming service even does 128kb/s? Youtube is the only one that comes to mind and that's for free usage only. Paid accounts get 256kbit AAC

Spotify uses OGG Vorbis codec and streams at 160 kbps at standard bitrate and 320 kbps at high quality

In addition to AAC, the entire Apple Music catalog is now also encoded using ALAC in resolutions ranging from 16-bit/44.1 kHz (CD Quality) up to 24-bit/192 kHz

Amazon Prime Music at 256 kbps

That's about 99% of the streaming music market people actually use

Of course to make this strawman argument you have to ignore the previous comment that says you can do wired connections just over a different port type.

Let’s also ignore any understanding of the DAC quality between older iPods and newer iPhones, where even the dongle Apple sell are considered a high quality DAC.

Let’s also ignore any advances in Codecs in that time, or advances in audio hardware itself.

Let’s also ignore that most iPod users would have bought low quality MP3s or medium quality AACs at the time. Not to mention that most customers use streaming today so wouldn’t even be able to take advantage of the higher quality codecs today.

Finally let’s ignore customer preferences and what niche set of customers would have bought high end enough audio equipment and have the hearing to appreciate and also not want wires today to even fall into your narrow band description.

Who would have thought that if you ignore all aspects that are inconvenient to an argument that you could make any argument you want?

Not who you are replying to but my $30 wired Apple earbuds (came with my 6S) have outlived all of my co-workers half dozen $160 AirPods. That’s reason enough for a lot of people.

My wired Shure in ear monitors have much better sound quality, and battery management on AirPods is pretty annoying. Even when they’re not running out mid-trip, it’s just unnecessary mental overhead to keep another thing charged.

I don't daily drive my phone for commuting anymore, but the trade-offs aren't exactly new: - battery frustrations - cost of a dozen cheap but good quality headphones vs a wireless equivalent - easier to lose wireless headsets when you put them down somewhere (wired too, but way cheaper so less big deal) - audio quality? Who knows

For people that demand noise cancelling, you need an active power source, but I personally hate noise cancellation and always turn them off. Maybe valuable in a plane with lots of engine noise.

Simpler interface to debug and fix than bluetooth.

For me it’s because

- I already have high quality earphones, same set for many years

- they don’t require charging

- audio quality is great

- they’ll work on any device with a 3.5mm jack, no proprietary lock-ins

- I have never lost a set of earphones and if I did replacement wouldn’t break the bank

Easier to store vs bulky charging case and charger and charger cable etc. The wired solution is more portable, believe it or not.

I find it very practical with small Bluetooth earbuds, but I agree on the consumption aspect of it. I really don’t like that I can’t change the batteries in my AirPods. I would even be semi-okay with having to hand in them to a technician for battery exchange, for a reasonable cost. But the current battery exchange for airpods is just another name for buying new earbuds. And the third party solutions that actually change the batteries cost about as much as new buds.

If you're trying to play older 32-bit games, chances are you'd like to have sound, too.

Who is going to develop the virtual audio device drivers (for each OS) that are required to virtualize sound? Who is going to run all the tests needed to make sure that the guest-side 32-bit iOS 7 (and 8, 9, 10) drivers are going to play well with the host-side driver?

Who is going to accept the risk that someone takes over the guest VM after exploiting one of the well-known and unpatched kernel-level vulnerabilities present in iOS 10? What happens if malware finds and exploits a bug in that new audio driver virtualization pipeline so it can escape the VM and then compromise the host iOS?

Nobody wants to read emotional hyperbole when it's just an excuse to lie or exaggerate instead of being truthful or accurate. It's more common than not to find people expressing disappointment with Apple online who are lying, ignorant to the point that their complaint is just incomprehensible, using long outdated and incorrect information, exaggerating the problem to the point of absurdity, or applying expectations or standards that literally no company or alternative product on Earth meets. A good chunk of the time you can even get people to reply in a way that betray the fact that they never even owned or used the Apple product they're complaining about, they're just seeking upvotes or karma with easy and popular sentiments even if they're factually wrong.

Holding Apple accountable and having a negative opinion is fine, but it's a fairly rare thing to find someone online doing it in good faith.

I agree that feelings are okay. But also the internet and society is so overloaded with emotional hyperboles. I like with HN that a lot of people make the effort to be bit more diplomatic, less aggressive and more based in facts than most online communities.

> OP expresses disappointment with Apple

I read it as polarisation against Apple. As in what follows is not to be taken literally, but as a diatribe. The message being, in essence, "I don't like Apple." If that wasn't the intended message, OP is right--the comment is stronger without it.