Launched this week
StepGrab
Turn any Mac task into a step-by-step guide
188 followers
Turn any Mac task into a step-by-step guide
188 followers
Documenting a workflow means screenshots, cropping, arrows, and typing out every step. StepGrab does it for you: hit record, do the task once, and every click comes back as an annotated screenshot with the step already written. Native Mac menu bar app, on-device, no account, nothing uploaded. Export as GIF, PDF, MP4, clickable HTML, Markdown, or vertical video — one recording, your brand color. Free tier is real. Pro $2.99/mo, $12.99/yr, or $44.99 once.
StepGrab
I'm the person people come to when they can't figure out how to do something. Where's that setting, how do I export the report, why did the button move.
For years my answer was the same ritual: take screenshots, crop them, draw arrows in Preview, paste it all into a document, send it off. Then three weeks later someone asks the same question, the app has updated, and half my screenshots are wrong.
StepGrab came out of six months of fixing that for myself. It lives in the Mac menu bar. You hit record, do the task once, and stop. Every click comes back as an annotated screenshot with an arrow on what you clicked and a step description written by a model running on your Mac. Export it as a GIF, a PDF or an MP4.
Worth being clear about: the app is Mac-only, the guides aren't. Most of what any of us documents sits in a browser or a web app, so a guide I record on my Mac reads exactly the same for the colleague on Windows who asked me. I need the Mac. My reader doesn't.
The offline part matters to me more than anything else here. No account, no upload, nothing leaves your machine. Scribe and Tango are genuinely good tools, but they're web-first and subscription-only, and I didn't want my screen recordings living on someone else's server. That's also why there's a one-time option ($44.99) next to the yearly one.
Sorry, the offer field up there is too short for a link, so here it is properly. The code is PHUNT, and this opens the redeem screen straight away instead of making you dig for it in the App Store:
https://apps.apple.com/redeem?ctx=offercodes&id=6760129490&code=PHUNT
That brings Lifetime to $34.99 instead of $44.99. It only works on Apple accounts that haven't bought anything in the app yet, so if you already own Pro it will refuse. That's Apple's rule, not mine.
What I'd actually love from you: push the step descriptions and tell me where they get vague.
There's a real constraint behind that one. To describe a click you need to know what was clicked, and on macOS that lives in the Accessibility API. I have shipped a build that used it, but approval for that entitlement is inconsistent enough that I can't put a core feature on top of it. So I reconstruct from OCR and cursor position instead. When a control carries visible text that works well. When it's an unlabelled toolbar icon it doesn't, and that layer is still very much in development. The image foundation model coming in macOS 27 should close most of the gap, and until then I'm grateful for any ideas.
On that: I'm staying fully native either way. No web wrapper, no cross-platform layer, because the whole point is that the app reads the Mac properly. I have thought about selling it directly alongside the App Store, which would lift some of those sandbox limits, and I might still do it one day. For now the App Store is the rounder package for a one-person operation, with updates, payments, refunds and a bit of borrowed trust all handled in one place
Two things, both aimed at the asks in your comment rather than the launch.
On vague descriptions for unlabelled toolbar icons: you're trying to name the control, and OCR can't. You might not need the name. You already capture the frame after the click, and an unlabelled icon almost always announces itself by what it opens. A panel appears with a title, a sidebar toggles. Describing the step by its effect ("open the Inspector panel") is more useful to a reader than the label would have been anyway, and it needs nothing from the Accessibility API. The cases where the effect is invisible are rarer than the cases where the label is missing.
On drift, you may already have the thing that detects it, without adding a monitoring feature. Every guide you've made is a stored sequence of screens with OCR text attached. Every new recording anyone makes in the same app is a fresh sample of those screens. Fingerprint screens at record time and you can flag old guides containing a screen whose text no longer matches anything you've seen recently. It falls out of ordinary use instead of being a background job you'd have to justify. It'll be noisy, and it won't catch a button that moved without changing text, but "three of your guides touch a screen that has changed" beats nothing.
The reason I'd push on that one: a stale guide isn't neutral. A missing guide sends someone to ask you. A confidently wrong one sends them down a path that doesn't exist, and they burn twenty minutes before they start doubting the document. I keep a set of written procedures for my own build and release work, and the only one that ever really cost me was the one that stayed authoritative after the thing it described had moved. Nothing warned me. The reader trusts the artifact more than the author does.
StepGrab
@narek_keshishyan Thanks for reading the asks instead of the launch.
The diff idea I should have seen myself. I already keep the frame from just before each click, so the next step's screenshot is the after state. Every click has its pair sitting right there. And describing the effect is better writing anyway: "open the Inspector panel" tells the reader what they're aiming at, "click the third toolbar icon" tells them where my mouse happened to be. Toggles and focus changes stay a hole, but falling back to position text only when the diff comes up empty beats doing it by default, which is what happens now.
Drift is harder for a reason you couldn't get from the post: there's no server. Nothing leaves the machine, so "screens seen recently" only ever means screens this one user recorded. Narrower than what you describe. Possibly still enough, since whoever maintains ten procedures about the same three apps is also recording in those apps every other week. Noise is what I'd expect to fight. Different window width, different document open, and the OCR shifts without anything having changed, so probably fingerprint the stable chrome rather than everything on screen.
Your last paragraph is the part I'll be thinking about tonight. I had stale guides filed under annoying. Confidently wrong is something else, and the reader can't tell which one they're holding.
None of it is built. The diff one I'll probably just try this weekend.
StepGrab
Update from the maker, eleven hours in.
I badly underestimated who I'd be sharing today with. ngrok, Framer, Cloudflare, X Money, ElevenLabs. Companies with teams, audiences and actual launch plans behind them.
I have a Mac app I built next to a working student job, an email list of about 25 people, and no company. I went into today assuming I'd be invisible by lunchtime.
So sitting where I am right now genuinely surprises me, and it's down to people who had no reason to look and looked anyway.
If StepGrab is useful to you, today is the day it counts most. And if you'd rather open it and tell me what's wrong with it instead, that's been the more valuable half of this thread anyway.
Still here, still answering.