Hacker News Reader

Comment by alin23 | Hacker News Reader

Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?

I get it that macOS has to evolve, but that doesn't mean all apps have to drop Intel support at the same time.

On hardware-level apps like my Lunar app I have plenty #if arch(arm64) because some features like reading the brightness nits or reading ambient light is different or completely missing based on the architecture. I need to test the UI differences based on what features are available.

I don't see it viable to stay on macOS 26 for this, especially if we're going to see breaking changes again with the display and window server subsystem like we did with Tahoe. M5 support for Gamma table changes is still broken after so many months [0]

[0] https://developer.apple.com/forums/thread/819331#819331021

View on HN

> Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?

You don't. You could stay on an old MacOS. Apple would prefer that you tell your customers to stop being poor and buy a new computer. They will make your situation increasingly unbearable until you do.

The overwhelming majority of people haven't needed a new computer since 2016. The current economic situation makes a new computer a worse value proposition than it's been in 35 years. Vendors are responding to this situation by manufacturing obsolescence. Microsoft pulled the same stunt with Windows 11's TPM 2.0 requirement.

I think it's a stretch to call Apple's ARM transition "planned obsolescence". The M-series chips are very clear improvements on what came before and there is a clear rationale for that transition.

We're talking here about an OS that hasn't even come out yet, that will get years of security support, for computers that Apple hasn't been selling for several years now. Seems pretty reasonable.

I said "manufactured," not "planned." I don't think Apple intended to do this at the outset. Tim Cook wasn't leaned back in an office chair, twirling a moustache saying "yes, let's make every mac made before 2019 SUCK!"

If it was planned, Rosetta 2 would have never existed in the first place. It would have been a qemu fork haphazardly crammed into Xcode.

There was no "planning" here. Here's how I imagine it went: a developer whined about tech debt, management seized an opportunity to generate revenue, neither party considered, yknow, humans, and now we're here.

I have a MacBook from 2017 and and m3 air today.

For day to day tasks there is no difference.

I have a MacBook Pro from 2016 and an M4 Pro from last year. There is a night and day difference.

I think "M series chips are no better than ten year old Intel chips" is a take that would be somewhat difficult to sustain, given the data.

For developers, the difference is like night and day.

My 2019 MacBook Pro used to sound like a jet plane taking off whenever I did any sort of build. On a bad day, I could've baked some cookies on it. Admittedly, the corporate spyware that was constantly scanning every single file didn't help matters.

Try using it unplugged.

Eerily similar story here. My wife was using her 2017 MBP (the one they got sued over) and she adored it until Tahoe suddenly caused Chrome to run like hot garbage. I bought her an open-box M3 Air. She likes the color. It doesn't provide any more value to her life than her 2017 MBP did, and yet we're out $1000 because Apple said so.

So on the one hand you are so much aware of the obsolescence issue and on the other hand you just decided that upgrading a 2017 MBP to Tahoe is a good idea? I am on a M4 Pro Mac mini and it is still running Sequoia.

Btw she can downgrade to Sequoia from Tahoe.

Shame on my wife for doing what she has always been told to do, and updating the software on her laptop.

And why the hell would I know that? I was 8 years old the last time I used a Mac. This is shit I shouldn't have to know.

> Apple would prefer that you tell your customers to stop being poor and buy a new computer.

This is certainly an interesting way to characterize dropping support for old hardware. What is a reasonable way to go about hardware deprecation in your view?

When a company obsoletes a hardware platform, as Apple will do with this update, it is their moral duty to open the platform. Release the necessary source code, blobs, and docs to allow independent actors maintain their equipment, or maintain that equipment on behalf of its owner.

Apple won't. We all know that. The Broadcom wi-fi chips and the subtle differences in their embedded architecture vs. conventional PCs means x86 Macs will never be adequately supported without Apple's stewardship.

I think one thing that rubs people the wrong way is that Apple has basically infinite money at this point. They're not dropping support for old hardware because they don't have the resources to maintain the support. They're just doing it because they want to, and that's kinda lame.

Especially when I can keep getting both feature and security updates for Windows on hardware that's the same age (or older) as the EOL Apple hardware.

This isn't even just an Apple attitude. The whole macOS and iOS software ecosystem has this "nothing before the prior two OS releases exists anymore" attitude, and it is absolutely infuriating. It is absolutely possible and not a huge lift to support prior operating systems, but Mac developers just don't tend to care or do it.

The reasonable way to go about hardware deprecation is to not do it until that hardware is Truly Gone™, buy some actual definition of Gone that isn't an arbitrary number of years or versions.

That's overly dramatic. I don't think a new Macbook Air today is a worse value proposition than some Mac from 35 years ago. I just checked Apple prices from 1991:

    - Mac Classic II, the slowest of the bunch, $1.900, or about $4.661 today
    - Quadra 900, the fastest model in 1991, was $7.200 ($17.663 today)
    - PowerBook 170 was $4600 ($11.285)

"Value" and "price" aren't the same thing. A new computer in 1991 cost more, but it also covered a vastly increased set of use cases versus a machine from 5 years prior (assuming the hypothetical 1991 computer buyer had even owned a computer before). Today, you can buy a used MBP with an M1 and it will do everything a new MBP can do, and the differences compared to a new machine will be imperceptible to most users.

Plenty of people would even be perfectly happy on an x86 Mac, too. Sure, there would be a perceptible difference compared to a new machine, but not enough to justify the price. That's what obsoleting Rosetta is about, it's about artifically making x86 Macs so unbearable that would-be happy users have no choice but to buy something else.

All his comments are overly dramatic.

I still prefer my pre-2016 Intel Mac since I can do more things that I want to do on it than my newer M4.

Keep a macOS 26 machine around for testing. All Intel Macs will be stuck on 26 as well, so testing under 26 is probably best anyway.

Virtualize macOS 26 for testing purposes: https://eclecticlight.co/2025/01/21/what-can-you-do-with-vir...

> Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?

Isn't this a general form of 'how do we deal with the transition from a to b?'

If your client's can get intel Mac's, then you should be able to get one. If they can't, why do you need to keep supporting intel Mac's?

Continue to upgrade to the latest macOS on your host system, use something that leverages Apple's Virtualized.framework to run any version of macOS you want.

For instance, consider https://tart.run/

All the Android / iOS devs on my team use Tart locally when we need to test mixed environments.

Then we use Tart's sister Cirrus CLI to run our builds on our server.

> like my Lunar app

Oh hey! Thanks for making this. I've been running this app for a while now, between one and two years. Very much something that I rely on and appreciate.

> Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?

In a older version of the OS running in a virtual machine?

That's not going to solve the issue.

You are trying to emulate x86 to test those builds.

Rosetta doesn't emulate x86 hardware, but translates x86 instructions into ARM. The only thing your solution would get you is verification that the Intel build can work on Apple Silicon with Rosetta.

If testing on an Intel Mac is unacceptable, and testing on an ARM Mac using Rosetta is also unacceptable, then there was no reason to complain about Rosetta being deprecated in the first place.

Keep an Intel Mac around or drop support.

They followed the same path when moving from PPC to Intel.

And 32-bit to 64-bit.

IIRC Apple supported 10.5 extra long because of it being the last PowerPC MacOS. I wouldn't be surprised if they do something similar here. Keep an intel mac around, and you should be fine

Keep an Intel Mac around?

Arguably if you're shipping new fat binary code today, you should already have an Intel Mac around to test, because there might be subtle differences between Intel-on-Rosetta2 and Intel-on-Intel.

It works until that machine dies and you need to scramble for a solution (again).

Same way you test them now?

Reply on news.ycombinator.com