I let it go to voicemail.

When I checked later, the auto-transcription Apple does on incoming voicemails gave me the gist. A member of Apple's App Review team said he wanted to talk about WhisperPad. He didn't say why. I tried to call back at 9:30 Barcelona time and it was already after his working hours in Pacific. I told my classmates Apple was calling me. It felt unreal. Apple is giving me a phone call. That was the framing in my head all weekend.

The wait

I had a long weekend ahead of me wondering what the call was about. I let myself hope it was a reversal. I'd been very public about the original rejection. Part of me was nervous Apple might be calling for a different reason. Maybe they wanted to communicate something firm in private rather than in writing.

The call

On Monday I was in class. They called during a break. I picked up.

The conversation was three or four minutes. The Apple reviewer was calm and friendly. He told me the App Review board had taken a closer look at my original rejection and decided to reverse it. WhisperPad's use of the Accessibility API was approved. I could resubmit the version they'd previously rejected, using the same method, and reference our conversation in the review notes.

He said: "Sometimes a single reviewer's call gets revisited by the board, and the decision flips." I thanked him for his time. End of call.

What I felt

Mostly confused, then thankful. I'd been operating for two weeks on the assumption that this path was permanently closed. I'd forked the app into two separate SKUs. I'd stood up direct distribution with Paddle for payments and Sparkle for updates. I'd written architectural decision records explaining why the fork was permanent. And now, with one phone call, all of that had changed.

Ultimately, I'm happy Apple reached out. They approved the app. I'm stoked about it. The story is closed in the best possible way.

The work of un-doing the fork

The reversal sounded simple on the phone. Resubmit the version you originally built. In code, it was anything but simple.

When I split WhisperPad into two versions in May, I'd guarded the differences behind a compile flag called MAS_BUILD. The flag had quietly come to mean two unrelated things. One: legitimate, permanent exclusions required by the App Store sandbox, like the in-app crash reporter that reads files the sandbox blocks. Two: feature reduction to dodge the 2.4.5 rejection — the clipboard-only paste path, the disabled transcription modes, the abbreviated onboarding. With the reversal, I needed to keep the first kind and undo the second.

Restoring the full app meant unwinding MAS_BUILD guards across seven files. Core insertion logic. App startup permissions. Settings UI. The onboarding flow. The FAQ. The result panel. Most of the work was deleting code. The compliance changes had added complexity, and the reversal removed it.

Net result: forty-four lines fewer than before.

The Sparkle dance

The trickier piece was the auto-updater. Sparkle, the long-standing framework that handles updates for non-App-Store Mac apps, ships helper executables that are incompatible with the sandbox by design. The sandbox exists to keep apps from escaping into the rest of the system. Sparkle's whole job is to escape and replace the parent app. The App Store will reject any bundle that contains a non-sandboxed executable.

So Sparkle has been toggled in and out of the codebase four times in two weeks. Out for the compliant 1.7. Back in for the direct launch. Out again on Monday, briefly, because the moment I tried to upload the 1.8 App Store build the validation failed with the exact error from before — Sparkle's helpers were back in the bundle because Sparkle is linked as a Swift Package and embeds automatically. Restored immediately after the MAS upload cleared.

That dance is fragile and manual. The permanent fix is conditional framework linking or revisiting the single-target decision, both of which are on the list. For now, git is the safety net.

What this means for the studio

The direct-distribution channel from mitmllc.com still exists. I'm keeping it. People who want to save the App Store markup can buy direct. People who want Apple's trusted purchase flow can buy from the App Store. The same product, two channels, neither one a compromise.

Without the original rejection, I never would have built the direct channel. Sometimes the workaround you're forced to build becomes the thing you're glad you have. I learned a lot in two weeks I wouldn't have learned in two months of straight App Store work. The infrastructure I now have for direct distribution will outlast WhisperPad. It's there for whatever I ship next under MITM LLC.

What I'd say to other developers

Build your own distribution channel anyway. Not because it'll force Apple to reverse a rejection ...though, hey, maybe it will, who knows. Build it because it's an asset you'll want to have regardless. And triple-check your work when you do. The biggest headache I had during the launch wasn't anything Apple did. It was that some users downloaded a version with a broken auto-updater and a stale purchase link, and they couldn't get to my payment page. That cost me real customers and a lot of email apologies. Sparkle, entitlements, license-key delivery etc.

Closing

Overall I'm thankful this saga happened. I made real connections answering emails from customers, from people reaching out about RSI in general, from other Mac developers who'd hit the same wall. It was good to see those connections form and to talk with people dealing with similar issues. I learned a lot.

It's been an interesting two weeks. Super hectic, super fun, and all of it on top of writing a master's thesis and building my final presentation. June is going to be a busy month.

WhisperPad is now what it was always supposed to be, in both places it was supposed to be. The loop is closed.

If you want to try it, the direct version is at mitmllc.com/whisperpad. The Mac App Store version is also live with the full auto-paste functionality now. The free tier is 120 minutes a month either way. If you want to write to me here: contact@mitmllc.com

This post was dictated using WhisperPad.

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 contact@mitmllc.com.