Get rid of separate binaries (install step) for scripting addition

[koekeishiya]

I am thinking of removing support for older versions of macOS later this year, when macOS 13 is released. The new supported versions would be 11 (Big Sur), 12 (Monterey) and 13.

This would allow me to remove the need for users to manually install the scripting addition every time yabai is updated.
The code for the scripting-addition could just be loaded directly out of the yabai binary.

There appears to be one caveat as of now; the binary would have to consist of an x86_64 image and an arm64e image.
The issue is that arm64e is still in preview mode for non-Apple signed binaries, complicating the setup for users that wish to run yabai without the scripting addition, as they would probably not want to (or do not have permissions to) change the boot-args.

[koekeishiya]

Obviously I forgot that it isn't actually all that simple:

Application Specific Information:
XXXXXXXX bear trap: NSApplication initialized in Dock. Please log a bug.

The yabai binary links with Cocoa.framework which leads us straight back to the issue that was worked around years ago (by making sure the payload does not link to Cocoa/AppKit in the first place):

0   AppKit                        	       0x1aadc2c38 +[NSApplication load] + 164
1   libobjc.A.dylib               	       0x1a8059398 load_images + 828
2   dyld                          	       0x101107ab4 dyld4::RuntimeState::notifyObjCInit(dyld4::Loader const*) + 164
3   dyld                          	       0x10110de5c dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 204
4   dyld                          	       0x10110de44 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 180
5   dyld                          	       0x10110de44 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 180
6   dyld                          	       0x10110df34 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 124
7   dyld                          	       0x10111d9e4 dyld4::APIs::dlopen_from(char const*, int, void*) + 520
8   ???                           	       0x103cf008c ???
9   libsystem_pthread.dylib       	       0x1a81d026c _pthread_start + 148
10  libsystem_pthread.dylib       	       0x1a81cb08c thread_start + 8

I assume that whatever functionality yabai uses can be linked dynamically at runtime instead to avoid this, but maybe there are better ways to handle this situation and achieve the same goal.

[koekeishiya]

It may be more realistic at this point to have --load-sa automatically verify the existence of the scripting-addition through hash or byte-comparison, and install/upgrade if necessary before performing a load. The --install-sa and --check-sa options would be removed.

The reason it does not do this at the moment is that I like the fact that there is full transparency; any change to the users filesystem is something that they have explicitly decided to do -- not something that is done by simply running the software.