Apple Rejected My Dictation App for Using the Accessibility API. Here's What That Means for Developers.

At 9:47 AM on a rainy Tuesday, I got the email every indie developer dreads. Apple had rejected my dictation app — VoiceType Pro — from the App Store. The reason: I was using the Accessibility API, which Apple reserves for assistive technologies like screen readers and switch control.

It took me 18 months to build VoiceType Pro. Over 4,000 beta testers had used it. Dictation accuracy was 97.2% — beating Apple's built-in dictation by 8 percentage points according to my internal tests. The app literally could not function without the Accessibility API.

Apple's argument? The API was designed for accessibility tools, not "productivity enhancement." That distinction cost me $12,000 in developer costs and roughly 2,300 hours of work. But this isn't just my story — it's a story about how Apple's platform governance creates friction between its stated values and developer reality.

Apple's Accessibility API has been around since iOS 3.0 in 2009. It gives apps permission to read screen content, simulate taps, and control other applications — essential for voice-controlled navigation. By 2026, over 650 million people have used apps built on this API for accessibility, according to Apple's own data.

But here's the twist: Apple's own Shortcuts app uses the Accessibility API. Siri uses it. Even the Control Center uses it. In fact, 14 of Apple's own apps leverage accessibility features for general-purpose functionality. Yet when a third-party developer does the same thing for dictation, it's suddenly a violation.

This selective enforcement matters because the App Store generates roughly $85 billion annually. Apple takes a 15-30% cut on every transaction. But the real value isn't the commission — it's control over what users can do with their devices. The Accessibility API is a backdoor into that control.

The rejection rate for apps using accessibility features has jumped 340% since 2023, according to a survey of 200 independent developers I polled on Mastodon. Only 12% of those rejections were overturned on appeal. The message is clear: Apple wants to be the sole arbiter of what counts as "accessibility."

But why now? The answer might surprise you. In January 2026, Apple launched "Dictation Pro" — an upgraded version of its built-in dictation that now handles real-time transcription with 98.1% accuracy. My app's 97.2% was close enough to threaten their new product. When I submitted my update on May 15, the rejection came back in 47 hours — unusually fast for Apple's usually sluggish review process.

Coincidence? Maybe. But consider this: Apple rejected 1.7 million app submissions in 2025. Only 0.3% of those rejections cited the Accessibility API specifically. My app was one of roughly 5,100 that got flagged. The chances of hitting that exact clause with a product that competes with Apple's own new feature are... let's do the math: 0.3% of 1.7 million is 5,100. The odds of randomly being in that group while also competing with Apple's dictation product? Statistically negligible.

I appealed. Three times. Each time, Apple's response was identical boilerplate: "Your app uses the Accessibility API for a purpose other than providing accessibility functionality." I asked them to define "accessibility functionality." No response. I asked for a list of approved use cases. No response. I offered to add screen reader support to make it explicitly accessibility-focused. Still rejected.

The deeper issue here isn't my app — it's the asymmetry of power in platform economies. Apple controls the App Store, the API, the review process, and the definition of terms. They can change the rules overnight and there's no court of appeals. Developers like me have exactly two options: comply or leave.

But here's the counterintuitive part: I actually agree with Apple's core premise. The Accessibility API should be protected. If every app started using it for background automation, user privacy would degrade and device security would suffer. My app only reads the screen when I explicitly trigger it with a voice command, but not every developer would be that careful.

The problem is that Apple's enforcement is arbitrary and self-serving. They don't have a transparent rubric for what counts as accessibility. They don't publish guidelines for third-party developers. They just reject, reject, reject — and let the market figure it out.

What should Apple do instead? Three things. First, create a tiered API system — basic accessibility features for assistive apps, advanced features with additional review for productivity apps. Apple already does this with the Camera API and HealthKit. Second, establish an external review board with disability advocates and developer representatives. Third, publish appeal outcomes publicly so developers can learn from each other's cases.

None of this will happen, of course. Apple has no incentive to make the App Store more transparent. The current system keeps developers in a state of managed uncertainty, which maximizes Apple's control. It's not about user safety — it's about platform power.

For now, I'm doing what dozens of other rejected developers have done: launching VoiceType Pro on the web. It'll work on any device with a browser. Lower friction, no 30% tax, and no one telling me what counts as "accessibility." The irony is that my web app will actually be more accessible — it works on Android, Windows, and Linux too.

What should you watch for next? Keep an eye on the EU Digital Markets Act. In March 2024, the EU forced Apple to allow alternative app stores. By 2027, expect similar pressure around API access. The EU has already hinted at investigating platform lock-in for core APIs. If they do, my app — and thousands like it — might finally have a path back to the App Store.

Until then, I'm building for the open web. It might not have Apple's polish, but at least it's got something better: a rejection-proof distribution model.