I built WhisperPad because I needed it. In the fall of 2024 the joints in my fingers started to hurt when I typed. Maybe the bill came due for spending most of my life on a keyboard: a childhood of video games, then 10 years working in tech. It got worse throughout the winter, and by early 2025, I could not type for sustained stretches without triggering an unsustainable level of pain. It was a progressive injury, so there was no single dramatic moment; just a slow narrowing of how much I could do in a day.

That narrowing arrived at an inconvenient time. I was between jobs and trying to decide what came next, and I had landed on applying to a master's program in human-computer interaction. My biggest fear about it was not whether I could keep up mentally. It was whether my hands would let me produce the work fast enough to keep pace.

What WhisperPad does (or did, anyway)

WhisperPad lives in your menu bar. You press a keyboard shortcut, you talk, it transcribes what you said locally on your Mac, and it places the text into whatever field your cursor is in. Nothing is sent to a server. If you have clicked away by the time it finishes, the text is on your clipboard and you can paste it wherever you want. That is the whole app. The point was to make getting words out of my head and into the computer cost as few hand movements as possible.

In April, Apple rejected an update to my Mac dictation app, WhisperPad, under Guideline 2.4.5. Their position was that I was using the accessibility API in a way that wasn't an accessibility use. The app exists because I have a hand injury. Apple had approved earlier versions doing the same thing. This time they did not.

I had used Apple's built-in dictation first, and the experience was a particular kind of frustrating. The transcription was close but rarely right, and every correction meant going back in with the keyboard, deleting, retyping. I was hurting my hands to fix the tool that was supposed to be saving them. That is the specific problem I wanted to solve: not "transcribe my voice," but "transcribe my voice well enough that I am not constantly typing corrections."

I will be honest about how I approached this. I did not do much market research. There were probably good tools out there already, but most sent your audio to a server somewhere, and I wanted one that didn't. When I want something, my first question is usually "can I just build it," not "what can I buy."

The first version was rough, but I used it every day and kept improving it. I shared it with a couple of classmates and watched them fold it into their own daily workflows. Seeing other people quietly come to rely on it made me want to release it properly.

The rejection

Version 1.0 shipped in the winter, and it was free to download from the App Store. Next I added features early users asked for, and I decided to make it a paid app. That update was version 1.5.

Apple rejected it under Guideline 2.4.5. The rejection was specifically about the accessibility permission. WhisperPad uses it to inject transcribed text into other applications, and Apple's position was that this was not an approved use of that API. Earlier, approved versions of the app already did the identical thing with the identical permissions, so this was hard to swallow.

The rejection explanation had some fair feedback, too. I fixed those issues, but the 2.4.5 issue was the real wall. So I appealed, explaining that WhisperPad functioned as an accessibility tool, that I had a repetitive strain injury, and that the whole reason the app injected text the way it did was to spare the hands of people who, like me, could not afford the extra keystrokes. I asked Apple to look at it in that light.

They responded that they would take a closer look. They told me not to reply in the thread, and said they would come back with a decision. That was April 21st.

Then it went quiet. By May 21st I had heard nothing, so I sent a short, polite note asking about the status. I have worked in customer support. I know tickets fall through the cracks, and I wanted to nudge it back onto the pile.

They responded quickly, and the answer was another rejection.

The decision to split

That second rejection is what forced a real decision, and I want to explain, because it would have been easy to make a worse one.

I spent some time weighing two options: comply with Apple's restrictions and release a version that fit their rules on the App Store (sacrificing the direct paste), or release WhisperPad through direct distribution. I decided I couldn't sacrifice the reach of the App Store. So I would build a version that complied with their rules and put it there, and at the same time move ahead with direct distribution to deliver the full version I had originally set out to build.

Here is the thing about the constraint. Apple's guideline, as far as I can tell, is meant to govern apps injecting text into themselves for accessibility, rather than into other apps. That is my assumption, since I never got a perfectly clear explanation. (If you understand this guideline better and can correct me, reach out — I want to hear it.) Either way, an app reaching into every other app on your system is something to be careful about, and I can see how WhisperPad sits in an awkward spot relative to that line.

So I split WhisperPad into two versions.

The version on the Mac App Store does not auto-paste. It puts your transcribed text on the clipboard, and you press Command-V to place it. That takes the core flow from roughly four steps to six. That does not sound like much, and for most people it is not. The entire design goal of the app was to remove hand movements for people who need to be economical with them, so a 50% increase in steps is significant. It is a compromised version of the idea. But it is a real, useful app, and it is on the store where people with or without accessibility needs can stumble onto it. The App Store makes it discoverable.

The original vision, the one that pastes directly where your cursor is, I shipped myself — outside the App Store.

Shipping it directly

Shipping software outside the App Store means rebuilding the things the store normally does for you. There's a new trust hurdle, too. You're asking people to trust you to process their credit card on your own site.

For payments I went with Paddle, after some research into the options. For updates I am using Sparkle, the long-standing framework for keeping Mac apps up to date outside the store. Licensing is handled with license keys checked against a small server. None of this is exotic, it is the well-worn path for independent Mac software, but it was all new to me, and getting it right took real work. Practically, I forked the app into separate build targets: one configured for the App Store, one for direct release. I finished wiring up the direct release pipeline on May 27, the morning I started writing this.

What I took from this

What first looked like an obstacle turned into a constraint that pushed me to build a better-organized product. I now understand my own build configuration, my update path, and my payment flow far better than I did in March, because Apple's "no" forced me to learn all of it. Apple's guidelines exist for defensible reasons, even if I wish my particular app had landed on the other side of the line.

When a platform tells you no, you usually have more options than the moment makes it feel like. The choice is rarely "comply or quit." It is often "comply here, and do the fuller thing somewhere else." Shipping two versions, each one serving its channel as well as that channel allows, was not a defeat. It was just the next piece of work.

WhisperPad is on the Mac App Store now, with a free tier of 120 minutes a month so you can find out whether it fits how you work before paying for anything. The direct version, with full auto-paste, is available at mitmllc.com/whisperpad. If you want to talk to me about it, I am Rene Zelaya, and you can reach me at [email protected].