TL;DR
- Rectangle & Magnet gives you 100 different window tiling options, but you need to remember 100 different shortcuts.
- Raycast gives you a 100 different window tiling options, but it's no more a shortcut but a phrase away.
- GridTile gives you a 100 different window tiling options, and you need to remember one shortcut. Using Claude and your (not-main) project itself as a tutorial, is an amazing way to get started with learning a new language
Download GridTile here for FREE
Window management is an essential requirement. Moving to macOS made me realise just how much I relied on it. On Linux, I used the amazing Tactile extension for grid-based tiling.
Coming to MacOS, I tried a few options - Raycast, Magnet, Rectangle. That's when I ran into a problem.
Keyboard shortcuts - They're fast, they keep my hands on the keyboard, and once something becomes muscle memory, they are hard to beat.
So the first window-management tools I tried made perfect sense to me. Give every action a shortcut.
Left half. Right half. Top-left. Top-right. Bottom-left. Bottom-right. Maximize. Center. Move to another display. One-third. Two-thirds. And so on.
The problem is that window layouts don't stop at the layouts someone thought of when building the application.
I might want a window to take up the left 40% of my screen and another 60%. Or I might want a particular arrangement across two monitors. The moment I want something slightly different, I either need another shortcut or I need to start interacting with the application in some other way.
The shortcut problem
Keyboard shortcuts aren't free. (cue conflicts)
Utilities like Magnet, Rectange give you keyboard shortcuts to tile your windows and my keyboard has a finite number of combinations that I'm comfortable using. Other applications have their own shortcuts. The operating system has its own shortcuts. Other utilities are competing for the same combinations.
Everything is competing for the same pool of keyboard shortcuts. Imagine being a developer and discovering that the shortcut you use every day conflicts with your window manager.
Raycast solves this problem from another direction, if you want. Tiling is no more a few keys away, it's an entire phrase away.
Tiling is no more a few keys away, it's an entire phrase away
Bring tactile to MacOS
Having gotten used to grid-based tiling, I thought: why not bring the same interaction to macOS? I could implement the whole thing as a simple script.
I would have one shortcut.
Not one shortcut for the left half, another for the right half, another for the top-left, another for the second monitor, and another for some obscure 37% layout I might use once a month.
Just one. Press it, and a grid appears. (I mapped it to the Stage Manager key, since I don't use Stage Manager anyway.)
Then use the keyboard to select two tiles on that grid.
Those two points describe the rectangle where the current window should go. That's it.
It started as a Hammerspoon experiment
The first version wasn't a Mac application. It was a Hammerspoon Spoon that I built for myself.
I was mainly trying to answer one question: Could I bring Tactile's interaction model to macOS, and would it actually solve my problem?
The prototype put a keyboard-addressable grid over the screen. One key selected a cell, and a second key defined the opposite corner. The focused window would then be moved to the resulting region.
The important part wasn't the implementation. It was the interaction.
Two keypresses could describe a huge number of possible window positions without requiring a huge number of shortcuts.
The original Hammerspoon project was deliberately small and configurable. The grid itself was defined in Lua, with configurable rows, columns, weights, and key assignments.
You can download the spoon for your hammerspoon configuration here
And, to my surprise, I wasn't the only person who liked it. I put it on GitHub. People starred it. People forked it. People started using it.
Someone even specifically requested for the spoon after I built the native version. even specifically requested for the spoon after I built the native version.
Then there were responses on Reddit from people who understood exactly why I had built it. That was the point where the project stopped feeling like a weird little script that solved a problem on my laptop.
Maybe it was worth turning into an actual application.
The reason for a native version
I wasn't a Swift developer, so Hammerspoon was the natural choice for the first version. It became my primary — and eventually my only — tool for managing windows.
But over time, I started noticing the limitations. Occasionally, it would lag or feel sluggish. I tried fixing it several times, but whenever Hammerspoon got into that state, restarting hammerspoon was often the easiest solution.
At the same time, I wanted to add more layouts and make the experience feel faster and more responsive. Those two things pushed me towards building a native version.
I wasn't particularly interested in spending six months first learning Swift and then eventually getting around to rebuilding GridTile.
And this was 2026. So I did something that would have felt almost absurd a few years ago.
I asked Claude to help me build it. Actually, "help me build it" is understating it.
Claude wrote a lot of the code.
The current application is a native Swift/SwiftUI/AppKit implementation, with macOS Accessibility APIs handling the actual window movement. It is a proper menu-bar application rather than a Hammerspoon script.
But there is an important distinction in how I approached this. I wasn't trying to get Claude to produce an application that I didn't understand. I was trying to learn Swift while Claude wrote the code.
You can download the native version here
Let Claude write the code. Make myself understand it.
So whenever Claude introduced something I didn't understand, I stopped and asked. When something broke, I tried to understand why before asking it to fix it. The goal wasn't to write every line myself, but to make sure I could follow the code I was shipping.
That turned out to be a surprisingly effective way to learn. I was learning Swift, AppKit, SwiftUI, and macOS APIs because I had a real problem in front of me—not because I was working my way through a textbook.
And that became the part of the project I found most interesting.
My Insights
Looking back, this changed how I think about learning to program.
Whenever I've thought about teaching someone programming, I've always felt that it would be more interesting to start with a small project they actually want to build, rather than making them learn the basics first, then the language, then the framework, and only eventually letting them build what they wanted in the first place.
I've been taught both ways, and more often than not, it is the latter. You spend your time learning syntax, concepts, and frameworks without always knowing why you need them. For me, that can make learning feel unnecessarily boring.
Building GridTile was the opposite. I was learning Swift because I needed Swift. I was learning macOS APIs because I needed them. Every new concept had an immediate purpose.
I probably learned less breadth than I would have through a traditional, textbook approach. But I had much more fun learning, and what I did learn felt much more relevant because I had a reason to remember it.
That, for me, was the most interesting part of building GridTile with AI.
Claude helped me write the application. But more importantly, it gave me a way to learn a language by building something I actually wanted to use.
Top comments (0)