Scraib
A small Mac utility that rewrites any selected text with ⌃R, and the year and a half I spent figuring out how to make it feel obvious.
The problem I was actually having
I’m not a native English speaker, so my writing isn’t always perfect. At some point my most-used AI prompt became “rewrite this text, fix all mistakes, and make it sound natural.” But the process of opening a chat, asking for a rewrite, and then copying and pasting back into Slack took too long.
Of course I tried other solutions. Grammarly, WordTune, a few other products. There was always something that didn’t quite fit my workflow.
What I wanted was a keyboard shortcut. Select the text I’d just typed, press something, and get a better version right there, without switching context.
So in August 2024, I built v1 for myself.
v1: primitive, private, and used every day for a year
The first version looked pretty primitive. I could have made it nicer, but the goal was a working tool that solves the problem, not a beautiful one. I didn’t intend to share it. And it worked. I could select text anywhere on macOS, press ⌃R, and get a rewrite back in place.
I did try to ship it on the App Store. But there were so many issues and requests on their side. For example, one of the requests was that I shouldn’t distribute an app whose only paid feature is unlocking it with your own API keys for AI models. At the time I didn’t have the time, the capacity, or even the desire to deal with it, because, like I said, my goal was just to solve my own problem.
So I kept using it privately. A year later I was still reaching for ⌃R whenever I wrote a message to someone. It had quietly become a natural part of my workflow.
The restart: September 2025
My daughter started daycare and I got a few hours back that I hadn’t had in a long time. By then AI was capable enough to be a real co-developer. We were in the ChatGPT 4.5 era, very cool but not yet February 2026. The app I’d been using for a year was still primitive, un-shippable, and still the thing I reached for every day. And since I liked it so much, I figured I’d try to share it with others.
I only had those few hours, so I wanted to keep things as simple as possible: development, distribution, and the number of services I’d have to manage. I decided to distribute through the Mac App Store because it was supposed to be easier for both me and my users.
The Electron detour
There was a lot of work to do to make the product ready for distribution. At the very least I had to make it look good, build a decent onboarding experience, improve the UI, and add a few features here and there. It was actually easier to start from scratch than to improve what I’d made for personal use.
At that point I knew JavaScript and React much better than Swift, and AI was also meaningfully better at JavaScript than at Swift (or so I thought). I figured I’d build it in Electron. I got a working v2 prototype quickly, but then I hit a wall.
Scraib needs to do two things that look simple and aren’t:
- Read the text the user has selected, in any app.
- Replace it with a new version, also in any app.
On macOS, the clean way to do that is through Apple’s official APIs for accessibility and text input and Electron can’t reach those. The workaround I tried was AppleScript. Apparently Apple doesn’t allow it’s usage for Mac App Store apps, and generally isn’t a fan of Electron apps.
My whole chosen distribution method was blocked, but I really didn’t want to go with anything else and set up all the updates, selling, and licensing myself.
Oh well. Thanks to AI it was painful, but not critical. I threw Electron version away and started again in native Swift.
UX puzzle: how do you show progress in an app with no UI?
I’ll skip the part about building it since it isn’t very interesting. I mostly just used Cursor and played around with different models, building on top of the code I already had from the first version of the product.
The interesting part was getting feedback from my friends and family who tested the app.
One of the issues they found was that they couldn’t easily see the rewrite happening, which meant that when they hit the shortcut they didn’t know whether the rewrite was in progress or something was stuck. I’d gotten so used to the original version of the product that I just didn’t see this problem.
Scraib has almost no interface. It lives in the menu bar. The whole point is that you press the shortcut and the rewrite happens. But “the rewrite happens” takes a second or two, sometimes longer if the text is long or the model responds slowly. During that time, two things can go wrong:
- The user starts typing something else, and the new text ends up in an unexpected place.
- The request fails silently (no internet, out of tokens, bad API key) and the user is left staring at their original text, not knowing whether anything happened at all.
So I needed a way to communicate states like something is happening or something failed without putting up a window that would yank the user out of whatever they were doing.
I explored a few surfaces:
Centered overlay. A small status panel in the middle of the screen. But it turned out to be distracting. The whole point of Scraib is that it stays out of your way, and a popup in the middle of your monitor breaks that promise.
Toolbar / menu bar indicator. Already there, nothing new to introduce, but it’s far from where the user is looking. People kept missing it entirely.
A static Wispr-style island near the menu bar. Better than the toolbar but still in the wrong place.
The cursor. That’s where user’s attention already is.
I went with the cursor. The first version was just a spinner attached to the pointer while the rewrite was in flight. That solved the “is anything happening?” problem on day one. And to communicate status better, I added a short message close to it.
This solution scaled well. When I added translation, I used the same cursor text to show what kind of rewrite was happening (“Translating”, “Rewriting”, and so on). When I added custom rules per app, I could tell the user that the app’s custom rules were being applied. And the app still stayed out of the user’s way and let them keep their context.
Tooling: building it with AI
I built v2 mostly through Cursor. The thing Cursor gave me that mattered most was the ability to switch models mid-project and see which one was actually better at the task in front of me.
The surprise was that Gemini was meaningfully better at Swift and SwiftUI than anything else I tried. ChatGPT and Composer handled Node.js and the server much better, and were cheaper than the rest. I rarely used Claude back then because of how pricey it was.
Launch: November 14, 2025
After a few rounds of trying to publish on the App Store, I finally launched on Product Hunt on November 14, 2025, and finished #3 product of the day with 314 upvotes ( Product Hunt page↗︎).
And with that, Scraib became a thing other people were actually using.
Where it stands now
I have a small but loyal user base of around 200 users. People who installed Scraib at launch still send me feedback, feature requests, edge cases, and the occasional bug. These days I mostly use it as a playground for new ideas and a way to learn about building with and on top of models. Right now I’m building the next version of the product, this time for distribution outside the Mac App Store.
If you want to try the app, check it out here: scraib.app↗︎, there is a 7 day free trial.
Feel free to reach out on LinkedIn↗︎ or X↗︎.