The short version: if you rebuild the same window arrangement every morning, you're doing manually what a rule could do once. Per-app layouts in Rectangle Pro assign each application a home — this app takes the left two-thirds, that one the right third, chat goes to the second display — so windows land correctly without you snapping them. The free approximation is a script driving Rectangle's URL scheme, which produces the same result on demand but won't fire by itself.
The ritual this replaces
Watch someone start their working day. Open the editor, snap it left. Open the browser, snap it right. Open the terminal, snap to a corner, resize because the corner is wrong. Open chat, throw it to the second monitor. Realize the browser ended up behind the editor, fix that.
Ninety seconds, maybe two minutes, repeated daily. It's not a lot on any single day, which is exactly why nobody fixes it — the cost is invisible per instance and only obvious in aggregate.
The more interesting cost is attention rather than time. You're making a dozen small spatial decisions before you've started thinking about work, and every one of them is a decision you already made yesterday.
Per-app layouts encode the answer. Each application has a defined home; opening it puts it there.
How the rules work
Conceptually simple: you associate an application with a position, and the position is expressed in the same vocabulary as everything else in the app — halves, thirds, quarters, a specific display, a custom size.
The interesting part is that positions stay proportional rather than absolute. A rule saying "left two-thirds" is meaningful on any display, which is what separates this from macOS's own habit of restoring windows to saved pixel coordinates that stop making sense the moment your screen setup changes.
Building a working set is less about the mechanics and more about deciding what your layout actually is — which is harder than it sounds, because most people have never articulated it. A useful exercise: at the end of a normal working day, look at your screen and write down where everything is and why. That description is your rule set.
The specific interface for defining these rules changes between Pro releases; check the current version rather than following a screenshot from an older article.
Where automatic placement goes wrong
Three failure modes, worth knowing before you build a large rule set.
Docking and undocking. A rule that puts chat on the second display can't be honored when there's no second display, so the window falls back to whatever screen exists. Then you reconnect and it doesn't automatically go back, because nothing re-triggered the rule. People who move between docked and undocked several times a day often end up preferring a shortcut they press deliberately over a rule that fires on its own.
Apps that open many windows. A rule keyed to an application applies to that application's windows, which is fine for a chat client and unhelpful for a browser where one window is your main work and three others are references. Blanket rules on multi-window apps produce a pile of windows in the same place.
Task-dependent layouts. If your editor belongs on the left when you're coding and full-screen when you're writing, a single per-app rule can't express that. Rules encode a stable answer; if your answer varies by task, you want a layout you invoke rather than a rule that fires.
None of these make the feature bad. They define its shape: it works best for applications with one main window and one right place.
Start with three rules, not thirty
The temptation on day one is to define a rule for every application you own. Resist it.
Pick the three apps you open every single day, whose position never varies. For most people that's a communication tool, a primary work application, and one reference window. Set rules for those, work for a week, and notice what irritates you.
The reason for restraint is that a wrong rule is worse than no rule. No rule means a window opens somewhere and you move it — mildly annoying, entirely predictable. A wrong rule means a window is confidently placed somewhere unhelpful, and you first have to work out why it went there before you can fix anything. Automation that's mostly right is more frustrating than no automation.
Add rules only when the same manual correction happens three times. That threshold keeps the set small and every rule earned.
The free version of this idea
Everything above is a Pro feature, but the useful part of it — arriving at a known arrangement without manual snapping — is reachable free.
The Rectangle app responds to URLs of the form rectangle://execute-action?name=left-half, and any action can be fired that way. So a script that activates each application in turn, waits for its window to appear, and fires the appropriate action produces the same end state.
The difference is the trigger. A rule fires by itself when a window opens; a script fires when you run it. In practice that gap is smaller than it sounds — bind the script to a hotkey or a hardware button and your layout is one press, which for most people is functionally equivalent to automatic.
The genuine drawback is fragility. The script depends on applications launching within the delays you allowed, and it breaks quietly when one is slow. Building a version that polls for the frontmost window rather than sleeping a fixed duration solves most of it, at the cost of an evening.
Two notes for anyone going down either path. Pro reads its preferences from com.knollsoft.Hookshot rather than com.knollsoft.Rectangle, so terminal commands copied from guides need the domain swapped. And whichever route you take, get the arrangement stable by hand first — automating a layout you haven't settled on means encoding a decision you're still making.
Whether the upgrade makes sense
Per-app layouts are the clearest Pro justification, more than pinning or custom sizes, because the thing they replace is a daily ritual rather than an occasional task.
The test is repetition and stability together. If you build the same arrangement every morning from the same applications on the same hardware, the feature removes a recurring cost and pays back quickly. If your setup varies by task or your hardware changes through the week, rules will fight you, and a deliberate layout shortcut — Pro's or a script's — serves better than automatic placement.
And there's an honest floor: plenty of people who think they need automatic layouts have never tried binding a single shortcut that snaps their current window where it belongs. A dedicated window manager for Mac solves a surprising amount before any automation enters the picture, and it's worth exhausting that first.
Frequently asked questions
Doesn't macOS already remember window positions?
Partially and unreliably. Apps restore their own positions with varying quality, and it breaks whenever a display is connected or disconnected, since the saved coordinates referred to a screen setup that no longer exists. A rule is applied fresh rather than restored.
What happens when I undock my laptop?
A rule pointing at a display that isn't attached can't be satisfied, so the window falls back to the remaining screen — and reconnecting doesn't re-fire it. This is the main practical limitation for people who dock frequently.
Can I do this without paying?
Approximately. Free Rectangle's URL scheme lets a script activate each app and snap it into place, giving the same end state on demand. What scripting can't easily do is fire automatically whenever a window opens.
