StepGrab

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.

The offline part makes a lot of sense to me since screen recordings can get pretty sensitive. How are you handling apps that change their UI often? Do the generated guides still hold up after updates?

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=PHUNTThat 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