




Before I built StepGrab, my process looked like this: take a screenshot, paste it into a doc, crop it, draw an arrow, type out the instruction. Repeat eleven times. Then three months later someone asks the same question and I can't find the doc anyway.
I'm curious how everyone else handles this, because I suspect the honest answer for a lot of people is "I don't." You explain it over a call, the other person takes notes, and then the next new hire asks the exact same thing.
No wrong answer here, and I'm not fishing for anyone to tell me my approach is better. I want to see what the actual split looks like, especially how big the "I just explain it again" group is next to the people already using a documentation tool.
If your answer is messier than the options, put it in the comments. The messy ones are the useful ones.
it lives quietly in the menu bar and just works when i need it. i record a task once and get back a clean set of annotated screenshots with the click arrows already drawn on, which used to be the most tedious part of writing internal docs for me. the fact that nothing leaves the machine matters too, since some of what i document has account settings and pricing info i wouldn't want uploaded anywhere.
the step descriptions get vague on toolbar icons that don't have visible text - it reads the label fine when there is one, but an unlabeled icon button just gets described generically. would love better handling there as the underlying model improves
looked at scribe briefly but it's web-first and subscription only, and i didn't want screen recordings of internal tools sitting on someone else's server
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.
@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.
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.



StepGrab
Thank you, and your second paragraph is the reason the app has the shape it does. A lot of what I document has account settings in it too, which is why I never built a server. There's nothing to upload because there's nowhere for it to go.
On the unlabeled icons, you've found the real weak spot. The step text comes from reading what's visible on screen plus whatever label the control exposes. When a toolbar icon has neither, there's nothing left to describe and it falls back to something generic.
The clean fix would be the Accessibility API, because an unlabeled icon usually still carries a description the developer set. That's where it gets murky. Apple restricts that API on the App Store to genuine accessibility use, so I work with a narrower permission instead. I could ship outside the App Store and have full access tomorrow, but then the privacy claim becomes "trust me" rather than something the sandbox actually enforces. For your kind of content that's the wrong trade, so I'm not making it.
The route I'm taking instead is the on-device vision model coming in macOS 27, which can look at the icon itself rather than asking the app what it's called. That's the 2.0 plan. Slower, but it doesn't cost you the thing you came for in the first place.
Thanks for writing this up properly. It's more useful than most of what I get.