macOS release dates are predictable and Apple ships developer previews and public betas. If these vendors can't update their products in time that doesn't speak for their processes, automated testing infrastructure nor care for their customers.
I would like to understand this better. Were there not any beta releases that these companies could have tested with in advance? Or were changes made between the beta and the release that broke things? Or something else?
> Worth stressing this was reported to Apple before the GA was released (by multiple people, to multiple teams/orgs within Apple) so Apple 100% knew about this, and shipped macOS 15 anyways
The betas are there for you to test your code against future Mac releases. Apple can and probably will take away APIs that your business is built around. Especially when those APIs are actually decreasing security.
It's an OS bug, you can't make it look good by invoking some generic "time to break" principle
Cry harder, dirtbags.
So, is this a bug in Sequoia or a change that affects these low-level tools? If the latter, they may not like it, but that’s par for the game on MacOS.
(Tried reading https://x.com/patrickwardle/status/1836862900654461270, referenced by sephamorr, but that link isn’t working for me)
There are two «firewalls» in OS X: the IP packet filter (controlled pfctl) and the application level one (controlled by /usr/libexec/ApplicationFirewall/socketfilterfw). The one that is causing a lot of grief for upgraded users is the latter one.
The workaround is to remove/disable the app level blocking rules manually:
1. Get a list of app level firewall rules:
/usr/libexec/ApplicationFirewall/socketfilterfw --listapps
2. Locate the app(s) of interest.3. Disable the app specific rules:
/usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp <path to the app from the list in step 1>
Alternatively, the app can be removed from the list of application firewall rules: /usr/libexec/ApplicationFirewall/socketfilterfw --remove <path to the app from the list in step 1>
That will fix the problem, e.g. with Firefox (tested) or WireGuard (reported by somebody else above, untested).If a DoH DNS configuration is used, it also makes sense to explicitly whitelist the DoH provider in «pfctl» rules at IPv4/IPv6 and domain levels.
Break them again and again until people realize how useless they are.
> On the day of macOS Sequoia’s release, a CrowdStrike sales engineer said in a Slack room for Mac admins that the company had to delay support for the new version of Mac’s operating system. “I’m very sorry to report that we will not be supporting Sequoia on day 1 in spite of our intention (and previous track record) to support the latest OS within hours of [General Availability],” the engineer said in the message, seen by TechCrunch.
If only Apple had offered these clowns some sort of beta or developer preview version to test their snake oil against before the widespread release of the new OS...
Absolutely zero sympathy.
What terrible news – whatever shall we do?
And this isn’t even the most egregious case, sometimes the bugs are so obvious that they generate multiple hard faults, per hour, logged in Console, on a fresh installation with only the default apps running.
One of our policies enforce that screen savers must start after 20 minutes, and it’s not possible to reduce it (I have my personal on 3 minutes). Or the fact that it will constantly reset the UI notification volume to 100% and speaker output, even though have headphones almost always.
Infuriating.
"Suck it up"?
I mean yes, ultimately if you want your app to be used, you'll have to do that, but wouldn't it be better if Apple stopped carelessly breaking backward compat with every update?
Interestingly in that thread, 'Intel' is not mentioned once.
And that I just sent a message yesterday to my team to wait before installing sequoia... But now I'll use your target of .4.