This is not true. The private api's we use are not hacks to work around macos spaces and are actually the basis of how appkit and the os in general works. They are essentially guaranteed to be stable and also not to be removed because they have been in use for many many years with no change.
The private api's that have been broken (as experienced by yabai) are strictly related to things that rift does not interact with like moving windows between macos spaces(since we use a virtual workspace system).
Only in abandonware software private APIs stay the same. In current, living technologies, they always change. Apple can simply issue an update to all consumers of the API so that they start using different symbols. If you have the energy to play this game, then it's fine. Just remember that Apple doesn't have any problem with killing the whole kernel extension market (this among lots of other things).
At my work I'm also forced to use private APIs on macOS and it's always a mess. Each update is a source of stress. Sometimes there's no work to be done, sometimes I need to spend a month to figure out what's happening.
I generally discourage people from using private API and I always say that if the platform doesn't allow doing some kind of software using public API, then don't do this software for this platform. Select a different platform. Use feedback forms to request functionalities. But using private APIs is asking for trouble. Again, if you want to play the game then it's fine. But if you offer software for users, then you're in some way responsible for those users as well.
yabai uses native macos spaces and generally requires sip to be disabled to have a good experience(windows can't be moved between spaces without)
rift is essentially aerospace but implemented in a yabai style. yabai style meaning using low level, private apis and generally focusing more on performance. whereas aerospace prides itself on only using one private api.
usage wise, aerospace and rift both use a virtual workspace system where all of your (work)spaces are in one macos space so no red tape has to be cut in order to move windows from ws -> ws and so forth
Does rift handle native MacOS tabs like the ones ghostty and finder use? I might give it a shot. I have been having a couple of issues with Aerospace lately.
No, rift also has problems. For example, if I have Calendar on the left, and Finder on the right, and I open a tab in Finder, then it looks like it works.
However if I close the 2nd Finder tab, then Calendar maximizes below Finder.
Also I am wondering if you could estimate how difficult it would be to implement something like Niri? I much prefer the scrolling style tiling, but none of the MacOS WMs seem to be going that route (other than PaperWM.spoon which is not for me).
to answer both comments:
i've been working on a way to handle tabs but it's hard to find a solution that isn't half-baked due to the lack of info on tabs given by the os (there are no events or anything, just on a11y attribute that give info on tabs)
as for a scrolling layout, its possible, but does not fit that well with rifts layout, even thought you can get something similar using trackpad swipes to switch between workspaces
Aerospace readme says they have a solution for tabs in mind based on their big refactor.
Haven’t looked into what this looks like, but understandable that it hasn’t made its way to rift yet. I will be trying out rift and report any issues on Github.
Interesting, thanks for sharing. My only concern is that it seems to use native MacOS workspaces which Aerospsace and Rift actively avoid. MacOS workspaces are hell to deal with, so I don't think this is for me.
