Apple abandoned any commitment to QA as soon as they committed to mid-September becoming a magical date, practically written in stone.
Too bad their competition is worse. It's not like they're good any more.
Btw I just checked and the assholes preselect the update to Tahoe, not the update to 15.7.1.
That way, they never have to deal with fallout from breaking a 20 year old program like Microsoft got for breaking whatever version of GTA. There's no way a 20 year old program still runs on current macos, so nothing to worry about.
The Windows team never faced anything like this. Not only did Windows change slowly and with backward compatibility, but the users didn't upgrade right away, even if they were buying brand new laptops. But in the Mac world, a laptop bought in September/October is going to have the new macOS on it no matter what.
In any case, Tim Cook clearly doesn't have the same standards as Steve Jobs did. Cook will never complain, "This is shit!" As Jobs reportedly lamented, Cook is a not a product person. So QA problems are not necessarily a problem for him. I suspect that Cook actually believes everything is mostly going well, and perhaps some "metrics" tell him so, though the metrics likely ignore the fact that developers have been disillusioned and alienated by Apple's hostile bug reporting system. If I thought Apple cared and would do something, I'd file literally thousands more bug reports.
I usually google where a particular setting is now since I don't use the exact same words and the settings search is very literal.
I use spotlight constantly for everything, but I admit I don't use the search feature in settings all that often.
I see a lot of "ugh, Tahoe is just the iOS-ification of macOS" on HN, which, on the surface, I get -- the visual changes by and large make things worse, and ironically I think they're actually not as good as the changes on iOS. But the Mac got stuff that the iPad didn't, and there's still a lot you can't do on the iPad that you can on the Mac. I don't think the two are merging any time soon, even if they're becoming more visually similar. (Actually, I don't think the two will ever merge, strictly speaking, but that's another post.)
like, you learn to work around this, mostly by just using raycast, but it's just unacceptable that they've spent BILLIONS on useless ai shit, while stuff THAT HAS WORKED CORRECTLY ALREADY IN THE PAST gets broken and goes unfixed for literal years
https://github.com/electron/electron/issues/48311#issuecomme...
You're right in the purest sense: use a private API, get burnt. But when it's something this widely used and depended upon you could argue Apple should have made it into a public API by now.
I get it. I’ve used private APIs in some of my Apple apps. But when you do, you take on a certain level of risk and responsibility when you’ve got customers.
The bigger question is why none of these Electron app developers, particularly larger outfits like Slack, didn’t catch this issue in the last 3 months they had access to Apple OS betas.
Do they have a QA process? Perhaps they should start.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (https://www.hyrumslaw.com/)
This doesn't exactly instill confidence in Apple's competence.
Electron used non-public pieces to workaround an issue with Apple code which Apple knew about and was not interested to address, now it's broken after it changed. Nothing new.
Each program contains its own version of Electron. How is Apple going to know the version of Electron your particular version of your particular app that you installed on one particular date perhaps years in the past works?
n apps in the world × n versions of Electron
The problem isn't Apple. It's that the developer of your program is using an outdated version of Electron, or it's put out an update and you haven't updated.
There are patches out now, but only after Apple released the OS to the entire team world and people reported the issue to the Electron team.
Imo, Electron is sufficiently popular that somebody should test at least one Electron app on a major new OS version sometime before releasing it as done! Any app would've worked, and there's plenty of popular ones, as this post shows.
That's why they release betas early -- that gives each project an opportunity to run their own test suites, however comprehensive they may be.
It's a little hard to hold Apple responsible when there are a lot of app teams in a better position to catch this than Apple, and apparently none of them did.
(Maybe it was a late change in Tahoe? Still, no one found it in the RC either it seems.)
Why measure if it's going to be ignored.
Yes, but this is a straw man
> even "popular" ones.
No, this is possible, but again, just drain the bathwater of "all, everything, comprehensive 100%" while blocking the baby of glaringly obvious system-wide visible bugs any good 9x% testing would've caught.
Yet the electron team didn't catch it, nor any of the many apps that use electron, despite beta access. Hm...
Sigh
It doesn't show up with a laggy Electron version.
I didn't use homebrew, but that version is also up-to-date: https://formulae.brew.sh/cask/ollama-app
spotify
slack
discord
figma
microsoft teams
postman
signal
chrome?
good luck!
Im surprised whatsapp showed up for you, its not for me. I had thought whatsapp was a native app
I am not sure if the old electron-based whatsapp is still available, maybe the one from the website, vs the one from app store, is still electron?
[0] https://9to5mac.com/2024/09/04/whatsapp-discontinue-electron...
Althought Electron uses the same core components as Chrome, the Chrome UI is not built with Electron.
Then I wondered - is WhatsApp Electron based? Not only it didn't turn up in the script result, I had heard they migrated to Catalyst and have the same iOS app running on Mac. Isn't that so?
Man I'm not doing too bad!
I prefer Zed over VS Code, or just flat out Visual Studio proper (2026 has gotten snappy!), as for Slack, I rarely use it, but I can use the browser, they are forcing non-profits out of Slack and into Discord anyway.
edit: that missed some of them. This works better:
find /Applications -name "Electron Framework.framework" 2>/dev/null | sed 's|/Contents/Frameworks/Electron Framework.framework||'
I cleaned a few as well.
X Docker.app: Electron 34.5.4 (Contents/MacOS/Docker Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)
X Docker.app: Electron 37.2.6 (Contents/MacOS/Docker Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)It uses an automatically update package listing the hashes of all files in electron releases: https://github.com/captn3m0/electron-fingerprints
I’ve been meaning to improve the detector to use ELF info.
Big shock.
Show dock instantly:
defaults write com.apple.Dock autohide-delay -float 0.0001; killall Dock
Undo:
defaults delete com.apple.Dock autohide-delay; killall Dock
It’s a waste of space; everything you need from it can be accomplished with your keyboard.
Apple has always changed the behaviour of private APIs. That is why they are private. This has always happened in the lifecycle of MacOS X. This is not unexpected at all.
pier25•4mo ago
dylan604•4mo ago
Mashimo•4mo ago
Could be for a small part of the UI, for example the start page / project selection thing.
dylan604•4mo ago
Mashimo•4mo ago
Austizzle•4mo ago
I wonder if instead there's small parts that are done in electron but most of it is qt
fxtentacle•4mo ago
zdragnar•4mo ago
__jonas•4mo ago
The docs about this are not on the web so I can't link to it, but you can access them in the App's help menu.
Quote from those docs:
> Users can write their own Workflow Integration Plugin (an Electron app), using Resolve Javascript’s API, and Python or Lua scripts. For more information on how to create a Workflow Integration Plugin go to Help > Documentation > Developer, and open up the Workflow Integrations folder for technical details and sample code.