That was the moment I decided my morning routine could wait.

The first emails about this issue had actually come in earlier, from free-tier users right after launch. I engage with free users too. Why not? They often give the most useful early signal anyway. But when the paying customer wrote in, there was a different kind of pressure. Someone trusted me enough to commit to a lifetime license. I needed to make that good.

When the first free-tier email came in, my honest first reaction was, oh no, this is a nightmare. That instant shock of did I just release something that wasn't ready. But I took a step back. I'd tested this thing across ten other Macs before launch. So I told myself, okay, hop back in the driver's seat and start diagnosing.

I've done this work before. I used to be a customer support agent, all of it over the phone. This time it's email, but the empathy and the acknowledging, that part is muscle memory. I could do it in my sleep. The funny thing is it feels better doing it for my own product. When I was getting paid to support someone else's thing, sure, I had some loyalty to it because I worked there. But it wasn't mine. And I think a lot of founders and engineers and designers get so far removed from the front line that they forget who they're actually building for. Sitting on the front line again was humbling. You get much faster signal on what's broken. You become the pattern detection.

What Tom did

I'll call him Tom. Tom was using the free version, so he didn't really owe me any debugging time. The first thing he did that I'm thankful for is he reached out at all instead of just bouncing, which is already more than most people do. Then I gave him some troubleshooting steps, and he actually did them. Some of those steps meant punching commands into the terminal, collecting logs, and sending the output back to me.

Here's the part that made me laugh. Tom opened up his own Claude Code to look at the logs, and his Claude pointed at a theory. So we had this back and forth where he's telling me, my Claude says it's this, and from the logs it wasn't definitive. Then my Claude agent took a look. What confirmed it was an actual bug was a second email, same issue. Then a third.

Even though Tom eventually found a workaround for his own machine, those initial logs gave me enough signal to go looking. And I found a real bug. The Direct-distribution build had shipped without a microphone entitlement. The Mac App Store version got the microphone entitlement automatically through the sandbox settings, but the Direct version disables the sandbox so it can do auto-paste, and I'd forgotten to manually add the entitlements file as a replacement. Without that entitlement, the app technically had no permission to access the microphone. Most people worked fine because macOS was lenient about checking. A few hit stricter enforcement and the app just failed silently. Tom helped me, not just himself.

The thing I was actually scared of

Watching it fail in front of the biggest one-day audience I've ever had was terrifying. But the fear was specific. I'm putting a product out there and I'm putting a price on it. I don't want to be embarrassed. I don't want to ship something pre-baked and burn goodwill by rushing to market. I've seen that happen a lot, and as a UX researcher it's a pattern I criticize constantly: teams ship features without testing and the users pay for it with a bad experience. I did not want to be that guy. I really don't like making users your guinea pigs unless they actually volunteered, with consent and compensation, not by downloading something they thought was finished.

To be fair, there were close to 200 direct downloads by that point, plus whatever came through the Mac App Store, and only three people hit this. It's rare. And they were chill about it. Nobody wants to create a bad experience for somebody else, but the people who ran into it gave me a way out.

Shipping the fix

The fix itself wasn't stressful. From the time I sat down to the time it was out the door was about an hour and twenty.

If this had happened to me back when I built websites by hand, it would have been a different night. Stuff like this did happen when I freelanced, and I'd be up at 1am on a customer's downed site, working for two hours, hunting for the right line of code, trying to calm myself down while something is actively broken. The hardest part was always just finding the file to touch. With Claude Code I find it fast, make the change, and ship. Honestly I spent more time writing emails to customers than I spent in the codebase.

And it wasn't stressful because I already knew what was wrong. The back and forth with Tom had handed me that. With the logs, I can track a bug down and squash it. Without them it's just "my mic didn't work, figure it out, it's on you."

To the people who wrote in: you gave my product a chance, and even when there was some turbulence, you reached out to help me fix it. Thank you.

This post was dictated using WhisperPad. The cadence is the way I actually talk.

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.