In this guide
The default trio
Web and application development converges on the same three windows: the editor, a terminal running the build or test watcher, and a browser showing the result. Integrated environments try to contain all three inside one window, which works until you need the terminal to be genuinely large or the preview at a real viewport width.
The layout that holds up over long sessions gives the editor the left portion — a half or slightly more — with the browser and terminal stacked on the right. The reason to stack rather than tile is that neither the terminal nor the preview needs full height, whereas code does. Three keystrokes with Rectangle and the arrangement is set for the day.
Debugging wants a different shape
Debugging inverts the priorities. Now the console, the network panel or the log stream matters more than the code, and the browser developer tools need real height. The workable arrangement is an even split: browser with tools open on one half, editor on the other. Terminal moves temporarily to a corner quarter or behind everything.
Being able to move between the two shapes in a couple of keystrokes is what makes them worth having. If switching from a writing layout to a debugging layout is a thirty-second drag operation, you will simply squint at a cramped console instead, which is how debugging sessions get longer than they need to be.
When reproducing a layout-related bug, resist the urge to maximise the browser. Snap it to a fixed fraction instead — thirds and halves give you repeatable widths, which is exactly what you want when the bug only appears at certain viewport sizes.
Code review and diffs
Reviewing a change is a comparison task and therefore wants two equal halves: the diff on one side, the running application or the related file on the other. Reviewers who work in a single maximised window tend to review the diff in isolation, which catches syntax problems and misses behavioural ones.
- Diff plus preview — pull request on the left, deployed branch on the right.
- Diff plus context — the change on the left, the file it calls on the right.
- Diff plus tests — the change on the left, the test output on the right.
- Diff plus spec — the change on the left, the issue or design on the right.
Each of these is two keystrokes with Rectangle app, and the difference between reviewing with context and reviewing without it is substantial.
Documentation and pair programming
Learning an unfamiliar library is a two-thirds problem: documentation on the larger portion, editor on the smaller, because you are reading more than writing. Once the API is familiar the allocation reverses. Being able to flip between the two allocations instantly is more useful than picking one and living with it.
Remote pairing adds a video window that must stay visible without stealing space. A corner quarter is the usual answer on a laptop; on a larger display a right third is more comfortable. If you are the one sharing, set the layout before you share — audiences do not benefit from watching someone arrange windows.
Terminal multiplexers and where the boundary sits
Developers who use tmux or a multiplexer already have splitting inside the terminal, and sometimes conclude a window manager is redundant. The distinction is clean: the multiplexer divides one terminal window into panes; the window manager decides where that terminal sits relative to the editor and browser. They operate at different levels and compose without conflict.
One practical caution. Terminal-based editors and multiplexers capture a large number of key combinations, and a few may collide with window shortcuts. Control-Option combinations are usually safe, but if a particular shortcut misbehaves only inside the terminal, that is the explanation. Rebind one side rather than trying to make both work.
Rectangle is free and open source
Halves, thirds, quarters and sixths from the keyboard, on any Mac. No trial, no account.
Download Rectangle for Mac →Frequently asked questions
Is this useful if I work entirely inside one IDE?
Yes, for the browser and terminal that sit outside it, and for the maximise-and-restore pair when you want the editor alone.
Does it work with terminal emulators like iTerm2 or Ghostty?
They are ordinary macOS windows and respond normally. Their internal splits are separate and unaffected.
How does this interact with tmux?
Not at all, in a good way. One arranges panes inside a window, the other arranges windows on screen.