If you are a developer working on macOS, your daily workflow probably looks like a high-stakes game of digital Tetris. On any given Tuesday, you have a terminal window tailing logs, a browser displaying your local dev server, a VS Code instance stretched across two-thirds of the screen, and Slack hovering somewhere in the background, constantly begging for attention.
We live in our IDEs and terminal emulators, but the OS we use to run them is failing us in one critical area: window management. While macOS is beloved by developers for its Unix-like underpinnings, its window management paradigm hasn't changed substantially since the days of Aqua in macOS X 10.0. The recent news that "macOS needs its grid back" has sparked a massive debate in the developer community. With Apple finally dipping its toes into basic window snapping in macOS Sequoia, it is time to talk about why basic snapping isn't enough, why developers desperately need a native, keyboard-driven grid system, and how we can build or configure the ultimate developer workspace today.
The Cognitive Load of Overlapping Windows
Every time you use your mouse to resize a window, drag a border to see a stack trace behind it, or command-tab through six identical-looking terminal windows, you are paying a cognitive tax. In software engineering, we talk a lot about minimizing context switching. We hate slow CI/CD pipelines and bloated IDEs because they break our flow state. Yet, we tolerate manual window manipulation—a physical context switch that occurs hundreds of times a day.
The core issue is that macOS is fundamentally built on a "floating window" paradigm. This was great in 1984 when users only ran one or two apps at a time on a 9-inch screen. But in 2024, running on a 16-inch liquid retina display or a 49-inch curved ultrawide, the floating window model breaks down. Windows overlap, get lost in the z-axis stack, and require manual "fiddling" to organize.
What developers actually need is a grid-based system. A grid ensures that every pixel of high-density display real estate is utilized. It prevents windows from overlapping, keeps documentation side-by-side with code, and—most importantly—allows for instantaneous layout manipulation using keyboard shortcuts instead of precise trackpad dragging.
The Evolution (and Failure) of macOS Window Management
To understand why we need a grid, we have to look at how Apple has treated this problem over the years:
- Spaces (Virtual Desktops): Great for separating "Work" from "Personal" or "Frontend" from "Backend", but it doesn't solve the layout issue within a single space.
- Split View: Introduced in OS X El Capitan, this allowed two apps to share a screen in full screen. It is slow to initiate, hides the menu bar, restricts you to exactly two windows, and feels clunky for developers who constantly need to reference three or four sources of information.
- Stage Manager: Apple's recent attempt at window organization. While visually interesting for casual users, it is highly inefficient for developers. It wastes massive amounts of screen real estate on sidebar previews and actively discourages dense, multi-window developer layouts.
- Sequoia's Window Snapping: macOS Sequoia finally introduced basic window snapping (dragging to edges to tile). While a welcome copy-paste of Windows 7 features from 2009, it is still mouse-centric and lacks the grid customization that power users require.
The Architecture of a Tiling Window Manager
Because native macOS solutions fall short, developers have turned to third-party tools to impose order on the chaos. To understand how to build the perfect setup, we need to understand the architectural difference between floating, tiling, and grid-based window management.
A pure tiling window manager (like i3 or bswm on Linux) treats windows as nodes in a binary tree. When a new window is opened, the tree splits, and the existing windows automatically resize to accommodate it. A grid-based manager, on the other hand, maps the screen to an $X \times Y$ coordinate system (e.g., a $12 \times 12$ grid) and fits windows into specific cell spans.
For macOS developers, we can achieve this level of control using open-source tools. Let’s look at how to configure the gold standard of macOS window management: Yabai (a tiling window manager) paired with skhd (a simple hotkey daemon).
Step-by-Step: Building a Keyboard-Driven Grid with Yabai
Yabai bypasses the default macOS window server (WindowServer) using accessibility APIs to force windows into a strict, non-overlapping grid or binary-space partitioning (BSP) tree. Here is how you can set it up to reclaim your screen real estate.
First, install Yabai and skhd via Homebrew:
brew install koekeishiya/formulae/yabai
brew install koekeishiya/formulae/skhd
Next, we configure Yabai to use a BSP (binary space partitioning) layout. This ensures that whenever you open a terminal or an IDE, it automatically tiles itself without you touching a mouse. Create a configuration file at ~/.config/yabai/yabairc:
# ~/.config/yabai/yabairc
# Global settings
yabai -m config layout bsp
yabai -m config top_padding 10
yabai -m config bottom_padding 10
yabai -m config left_padding 10
yabai -m config right_padding 10
yabai -m config window_gap 10
# Rule to exclude certain apps from tiling (e.g., System Settings, Calculator)
yabai -m rule --add app="^System Settings$" manage=off
yabai -m rule --add app="^Calculator$" manage=off
yabai -m rule --add app="^Activity Monitor$" manage=off
echo "yabai configuration loaded successfully!"
Now, we need to map keyboard shortcuts to manipulate this grid. This is where skhd comes in. Create a configuration file at ~/.config/skhd/skhdrc to define your hotkeys. We will use the hyper key concept (mapping Ctrl + Alt + Cmd) to avoid conflicting with existing IDE shortcuts:
# ~/.config/skhd/skhdrc
# Focus windows using Vim-like keys (Ctrl + Alt + Cmd + h/j/k/l)
ctrl + alt + cmd - h : yabai -m window --focus west
ctrl + alt + cmd - j : yabai -m window --focus south
ctrl + alt + cmd - k : yabai -m window --focus north
ctrl + alt + cmd - l : yabai -m window --focus east
# Swap windows (physically move them in the grid)
shift + ctrl + alt - h : yabai -m window --swap west
shift + ctrl + alt - j : yabai -m window --swap south
shift + ctrl + alt - k : yabai -m window --swap north
shift + ctrl + alt - l : yabai -m window --swap east
# Toggle window fullscreen zoom (great for diving deep into code)
ctrl + alt + cmd - f : yabai -m window --toggle zoom-parent
# Balance the sizes of all open tiled windows
ctrl + alt + cmd - e : yabai -m space --balance
Once these configurations are in place, start the services:
yabai --start-service
skhd --start-service
With this setup, the moment you open your terminal and your browser, they split the screen perfectly down the middle. Open another terminal, and it splits the right-hand side horizontally. Need to maximize your editor? Hit Ctrl + Alt + Cmd + F. Need to jump back to your docs? Move focus instantly with Ctrl + Alt + Cmd + H. Your hands never leave the keyboard.
The Lightweight Alternative: Rectangle Pro & Grid Snapping
If disabling System Integrity Protection (SIP) to get Yabai's advanced features feels like too much friction, or if you prefer a hybrid approach where you still use the mouse occasionally, you don't have to settle for Sequoia's barebones snapping.
Tools like Rectangle (open-source) or Rectangle Pro offer a compromise: a custom-defined grid overlay. You can press a hotkey to bring up a visible $3 \times 3$ or $12 \times 12$ grid on your screen, drag your mouse across the cells you want the window to occupy, and let go.
This "grid mapping" architecture is highly efficient for multi-monitor setups. For instance, on an ultrawide monitor, a standard 50/50 split makes browser windows too wide and lines of code too long to read comfortably. A custom grid allows you to easily establish a "three-column" layout: VS Code in the center (60% width), terminal on the right (20% width), and Slack/documentation on the left (20% width).
Why Native Grid Support Matters
While third-party tools are fantastic, they are ultimately band-aids. Every major macOS update threatens to break Yabai's integration with the WindowServer APIs. Apple's Accessibility APIs are not designed with fast, fluid window tiling in mind, leading to occasional screen flicker or lagging transitions.
A native grid system built directly into macOS would yield massive benefits for the developer ecosystem:
- Performance: Native window management would run directly inside the Metal-accelerated WindowServer, eliminating the micro-stuttering associated with third-party window manipulation.
- Siri Shortcuts & Automation: Developers could write scripts to programmatically arrange layouts based on the current project. Imagine running
npm startand having a script automatically arrange your IDE, local server preview, and terminal into a predefined "Frontend Workspace" grid. - Multi-Display Stability: macOS is notoriously bad at remembering window positions when plugging and unplugging external monitors. A native grid engine could save and restore precise layouts based on the active display configuration.
Conclusion: Reclaim Your Pixels
Our screens are bigger and higher-resolution than ever, yet we are still managing them with concepts invented in the era of CRT monitors. macOS needs its grid back, but as developers, we don't have to wait for Apple to realize that productivity isn't just about stage-managing single apps—it's about managing complex, interconnected workspaces.
By implementing a keyboard-driven tiling manager like Yabai, or utilizing grid-centric utilities like Rectangle, you can eliminate the constant micro-distractions of dragging, resizing, and hunting for windows. Your code, your logs, and your docs should live exactly where you expect them to, leaving your brain power free to solve actual programming problems.
Over to you: What does your macOS desktop look like? Are you team "pure tiling" with Yabai/Amethyst, do you rely on classic snapping with Rectangle, or are you hoping Apple brings a robust, native grid system to the next version of macOS? Let me know in the comments below, or share your custom skhd configurations!