I saw on macadmins.news about the release of FruitMenu Redux 1 and Xounds Redux 1.
I remember using the Unsanity Haxies on my system and a few systems at work back in the day, but remember that whenever I was testing software or had software issues, those were the first things that got removed when something went awry.
I’m looking at FruitMenu and hoping it’s not a destabilizing force any longer.
I was a user of the original FM, so I tried this. Seems to stop Bartender revealing the hidden menu bar items when you click on the menu bar.
They shouldn’t.
Classic MacOS had only minimal resource protection, so a rogue app/utility could corrupt the system.
Since Mac OS X (10.0), the Unix kernel and other system services do a great job of protecting services from each other. A bug in a “haxie” could mess up the system service it hooks into, but it shouldn’t be able to destabilize the whole system.
Thank you. This is just the missing fun that we talked about in another thread not long ago.
Bought them both instantly 
In the classic Mac days developers could create extensions that could essentially override anything in the Mac operating system. After OS X was released none of those methods worked, but in 2002-2003 for OS X 10.2 (Jaguar) and 10.3 (Panther), developers found a way.
One type of hack used an InputManager dynamic library, which OS X loaded into every application’s process for text handling. Using that hook, in 2003 Mike Solomon created SIMBL (Smart InputManager Bundle Loader) to inject his ad-blocking plugin PithHelmet into Safari. SIMBL was designed as an open source loader for other developers to use.
Once the InputManager library was loaded, the next trick it used was method swizzling, where the library could override the methods in the Cocoa applications.
Eventually Apple killed the InputManagers vector, forcing SIMBL to switch to exploiting Scripting Additions (.osax).
Meanwhile Unsanity released Application Enhancer (APE) in 2002. It used method swizzling for Cocoa applications – same as SIMBL – but it could also change Carbon applications. The Carbon code was changed by aggressive, low-level techniques, such as replacing the memory addresses of Carbon functions with the haxie’s functions (Import Address Table Patching) and directly overriding code.
You know what else uses these techniques? Malware.
And in fact the Carbon IAT patching sounds a lot like a technique that was used to compromise Linux systems in 2024, that almost succeeded. Look up the XZ Utils backdoor (CVE-2024-3094), which exploited a GNU C Library (glibc) feature called IFUNC (Indirect Function) resolvers.
Both are doing the same thing: dynamically patching a function routing table in memory so that the calls are redirected to the injected code.
With System Integrity Protection (SIP) in El Captain, and other changes, these runtime process injection attacks are harder.
Which gets to the point: How do the new Haxies work? They’re not using the old techniques. It looks like they are (ab)using Accessibility features.
Unfortunately, not working on Intel makes them DOA for me. I am almost finished going from my Mid-2011 iMac maxed out at MacOS 10.13.6 to a 2020 iMac 27" running MacOS 26.7.1. It arrived with MacOS 12.x.x on it but today I installed 26.7.1.
Yes, they are using Accessibility features. I find my Mac much more accessible and fun now (and even have the colored Apple back in the menu :-)
Of course you have to trust the developer, but that is the same as with any other app. No special features neccessary to wipe your personal files.
No disagreement here, but as @mschmitt wrote, malware uses the same vectors for nefarious purposes. So you can expect that Apple will close, or at least restrict, the vector in the future.