Rectangle vs. AeroSpace: Manuelles Snapping vs. i3-artiges Tiling ohne SIP
AeroSpace, entwickelt von Nikita Bobko, besetzt eine bestimmte Nische in der Landschaft der macOS-Fenster-Manager: Es bringt das automatische Tiling-Modell von Linux’ i3-Fenster-Manager auf macOS, tut das aber, anders als yabai, ohne dass System Integrity Protection deaktiviert werden muss. Genau diese eine Design-Entscheidung ist das Wichtigste, was man verstehen sollte, bevor man es mit Rectangle app vergleicht.
Was AeroSpace tatsächlich ist
Laut der eigenen GitHub-README ist AeroSpace ausdrücklich von i3 inspiriert: Fenster werden automatisch in ein baumbasiertes Layout eingeordnet, statt einzeln auf Befehl eingerastet zu werden, wie es bei Rectangle mac der Fall ist. Wichtige dokumentierte Merkmale:
- Eine Tiling-Engine nach dem Baum-Paradigma, dem gleichen konzeptionellen Modell folgend wie i3 unter Linux.
- Eine eigene Emulation virtueller Arbeitsbereiche, statt native macOS-Spaces zu nutzen, die README nennt das eine bewusste Entscheidung wegen dessen, was sie die „erheblichen Einschränkungen” von Spaces nennt.
- Reine Textkonfiguration im TOML-Format (
default-config.toml), ausdrücklich für Leute gedacht, die sich mit Dotfiles wohlfühlen, statt mit einer Einstellungs-GUI. - CLI-first, inklusive Manpages und Shell-Completion, mit dem erklärten Design-Prinzip, dass AeroSpace niemals eine GUI zur Konfiguration bieten wird, die README argumentiert, dass das Bearbeiten einer Textdatei für fortgeschrittene Nutzer einfacher sei als das Navigieren durch Checkboxen.
- Ordentliche Multi-Monitor-Unterstützung, die demselben i3-artigen Paradigma folgt, das auch für einzelne Monitore gilt.
Installation über Homebrew (die bevorzugte Methode, da sie automatische Updates ermöglicht):
brew install --cask nikitabobko/tap/aerospace
Der SIP-Unterschied: die wichtigste Abgrenzung zu yabai
AeroSpaces README stellt direkt klar, dass es keine Deaktivierung von System Integrity Protection erfordert, ausdrücklich im Gegensatz zu yabai, das SIP teilweise deaktiviert braucht für seine tieferen Funktionen. Das ist der mit Abstand größte praktische Unterschied zwischen den beiden Linux-artigen Tiling-Optionen unter macOS: AeroSpace hat bewusst einen Teil von yabais Fähigkeiten auf Ebene des Fenster-Servers (Schattenentfernung, Transparenzsteuerung und Ähnliches) eingetauscht, im Austausch dafür, vollständig innerhalb von Apples Standard-Sicherheitsmodell zu arbeiten.
Eine ehrliche Anmerkung zur Notarisierung, vom Projekt selbst
AeroSpaces README enthält eine ungewöhnlich direkte Offenlegung: „Mit der Nutzung von AeroSpace erkennst du an, dass es nicht notarisiert ist.” Die eigene Erklärung des Maintainers, die in der README enthalten ist, lautet, dass Notarisierung Apples Verfahren zur Verifizierung einer Binärdatei ist und dass das Projekt Notarisierung als Konzept nicht ablehnt, sie aber nicht durchlaufen hat. Das ist es wert, gegen Rectangle app abzuwägen, dessen offizielle Builds notarisiert sind, für ein Tool mit Bedienungshilfen-Zugriff auf deine Fenster ist das ein bedeutender Unterschied darin, was sich bei einem gegebenen Download überprüfen lässt, zusätzlich dazu, dass beide quelloffen sind.
Wo sich AeroSpace in der Praxis von Rectangle app unterscheidet
Dauerhaft aktives Tiling versus Snapping auf Abruf. Genau wie beim Amethyst/yabai-Vergleich ist das die zentrale Trennlinie: AeroSpace verwaltet fortlaufend die Position jedes Fensters, sobald es läuft, und berechnet den Tiling-Baum jedes Mal neu, wenn Fenster geöffnet, geschlossen oder verschoben werden. Rectangle app handelt nur, wenn du eine Tastenkombination auslöst oder an einen Rand ziehst; alles andere bleibt unangetastet.
Konfigurationsphilosophie. AeroSpaces README bezieht eine konkrete Position, dass niemals eine GUI zur Konfiguration hinzugefügt wird, als bewusste Design-Haltung, nicht als fehlende Funktion, die noch gebaut werden soll. Rectangles Einstellungsfenster ist minimal, existiert aber, und die alltägliche Anpassung von Tastenkombinationen geschieht durch Klicken, nicht durch Bearbeiten von TOML.
Entwicklungsstand. AeroSpaces eigene README beschreibt es, Stand der aktuellen Dokumentation, als in der öffentlichen Beta, warnt ausdrücklich, dass bis zu einem 1.0-Release mit breaking changes zu rechnen ist, und listet konkrete ungelöste Architektur-Arbeiten (eine Neufassung seiner Kern-Baumdatenstruktur, ein bekanntes Problem, bei dem Fenster zufällig in den fokussierten Arbeitsbereich springen können) als Blocker für dieses Release. Rectangle dagegen ist seit Jahren stabil und wird schrittweise versioniert, ohne eine vergleichbare „noch nicht 1.0″-Einordnung.
CLI- und Skripting-Tiefe. AeroSpace kommt mit einer eigenen Kommandozeilen-Schnittstelle, Manpages und Shell-Completion von Haus aus, gerichtet an Leute, die Fensterverhalten ausgiebig skripten wollen. Rectangles Entsprechung ist sein rectangle://-URL-Schema, funktional, um Aktionen aus anderen Tools heraus auszulösen, aber keine vollständige CLI mit eigener Befehlssprache, wie es bei AeroSpace der Fall ist.
Für wen AeroSpace tatsächlich gedacht ist
Nach der eigenen Einordnung des Projekts richtet sich AeroSpace klar an Leute, die bereits in i3-Begriffen denken, Arbeitsbereich-pro-Projekt-Tiling, tastaturgesteuerte Fensterverwaltung, Klartext-Konfiguration statt GUI-Einstellungen, und die speziell SIP nicht deaktivieren wollen, um dorthin zu gelangen. Das ist eine engere Zielgruppe als bei Rectangle: Bedeutet dir „i3-artiger Tiling-Fenster-Manager” aufgrund vorheriger Linux-Erfahrung nicht schon etwas, löst AeroSpaces gesamte Design-Philosophie ein Problem, das du vielleicht gar nicht hast.
Kurzübersicht
| Rectangle | AeroSpace | |
|---|---|---|
| Modell | Manuelles Snapping auf Befehl | Automatisches i3-artiges Tiling, immer aktiv |
| Erfordert Deaktivieren von SIP | Nein | Nein |
| Notarisierte offizielle Builds | Ja | Nein (direkt in der eigenen README offengelegt) |
| Konfiguration | Einstellungsfenster mit GUI | Klartext-TOML-Konfiguration, keine GUI geplant |
| Entwicklungsstand | Seit Jahren stabil und versioniert | Öffentliche Beta, breaking changes vor 1.0 zu erwarten |
| Am besten für | Feste Positionen auf Abruf, minimale Lernkurve | i3-/Linux-Tiling-Nutzer, die dieses Modell auf macOS wollen, ohne SIP anzufassen |