When Apple's App Store Rules Collide With Accessibility Needs
Apple has spent years marketing itself as the accessibility company. Its Voice Control, VoiceOver, Switch Control and Live Captions features are genuinely industry-leading, and the company regularly trots them out at WWDC keynotes as proof that good design is design that works for everyone. But there is a quieter story playing out underneath the marketing — one that affects the small group of independent developers who build the niche assistive tools Apple itself doesn't make. When those developers run into App Store review, the company's public commitment to accessibility can look very different from the inside.
The latest flashpoint: a dictation app rejected by App Review for the very thing that made it useful — its use of Apple's accessibility APIs. For a disabled user who relies on third-party software to fill the gaps in Apple's own tools, that rejection isn't an abstract policy debate. It's the difference between being able to use a Mac and not.
Why developers reach for the accessibility API in the first place
Accessibility APIs on macOS and iOS exist so that assistive software — screen readers, switch controllers, voice tools, magnifiers — can read what's on screen and act on a user's behalf. They are, by design, powerful. A well-built dictation app needs to know where the text cursor is, what window is active, and how to insert text into an arbitrary application. The accessibility API is the legitimate, documented way to do all of that.
The trouble is that the same APIs that enable assistive tech also enable automation tools, productivity launchers and, theoretically, surveillance software. App Review's rules treat the accessibility API with suspicion: apps that use it have to justify why, and reviewers can — and do — push back if they decide the use case doesn't fit. For an indie developer building a tool explicitly for disabled users, being told their accessibility tool can't use the accessibility API is a Kafkaesque experience.
Apple's own Voice Control shows the gap
Apple has been steadily improving its built-in dictation and Voice Control features. 9to5Mac recently reported that Apple quietly added a valuable new capability to Mac Voice Control — a welcome improvement, but one the publication noted still leaves "more work needed." That phrase captures the situation exactly. Voice Control is good. It is not, for many users, good enough.
People with RSI, motor impairments, or conditions like ALS often need features Apple hasn't shipped: custom vocabularies for technical work, smarter punctuation handling, integration with specific writing apps, faster correction flows, or simply a different mental model than the one Apple has chosen. Third-party developers fill those gaps. They always have — going back to the days when Dragon NaturallySpeaking was the only serious option on the Mac.
When Apple's first-party tool covers 80% of users and a third-party tool covers the remaining 20% who have more specialised needs, blocking that third-party tool doesn't just inconvenience a few customers. It removes the only viable option for the people who need assistive tech most.
The platform-holder problem
This is where the structural problem sits. Apple is simultaneously the platform owner, the maker of the built-in accessibility features, and the gatekeeper deciding which competing accessibility tools are allowed to exist. Every decision App Review makes about a third-party assistive app is, whether Apple intends it or not, also a competitive decision against its own Voice Control or Dictation.
That doesn't mean reviewers are acting in bad faith. More often, the issue is that App Review is a high-volume process applying broad rules to edge cases. The reviewer looking at a dictation app may have no context for who uses it or why a workaround built on the accessibility API is the only way to make it work. The rule says "justify your use of this API," the developer justifies it, and a rejection lands anyway because the use doesn't match a pre-approved template.
The irony is sharp. At WWDC, when Apple announced iOS 17 with Journal, StandBy, FaceTime voicemail and a long list of headline features, accessibility improvements were also part of the pitch — Personal Voice, Live Speech, Assistive Access. Apple genuinely cares about this stuff at the platform level. The disconnect is between that vision and the day-to-day reality of App Review.
Why this matters more in Australia than people think
For Australian users, the stakes are quietly higher than in larger markets. Australia's assistive tech ecosystem is small. The NDIS funds devices and software for participants, but the catalogue of supported tools tends to follow what's commercially viable on global platforms. If a niche dictation app can't survive App Review, it doesn't reach Australian users at all — there is no local alternative waiting in the wings.
Australians also can't easily turn to sideloading. The EU's Digital Markets Act has forced Apple to allow alternative app marketplaces in Europe, meaning a rejected accessibility app there can still find users through another store. No equivalent regulation exists here. For an Australian with a motor impairment whose preferred dictation tool gets pulled from the App Store, the App Store rejection is, effectively, the end of the conversation.
What a fairer process would look like
None of this requires Apple to abandon App Review or wave through anything that touches the accessibility API. A few targeted changes would go a long way:
- An accessibility track in App Review. Apps that self-identify as assistive tech could be routed to reviewers trained in disability use cases, with the authority to approve legitimate uses of the accessibility API without escalation roulette.
- A documented carve-out. Apple's guidelines could explicitly state that assistive apps targeting users with disabilities are permitted broader use of accessibility APIs, with audit requirements rather than blanket prohibitions.
- Transparency on rejections. When an accessibility app is rejected, the developer — and ideally the public — should get a clear explanation. Right now, rejections often arrive as boilerplate citations of a clause, leaving developers to guess at the real objection.
- A direct channel for disabled users. Apple's accessibility team is responsive and capable. Giving them formal input into App Review decisions affecting assistive tech would close the loop between Apple's accessibility vision and its store policy.
The bigger principle
The point isn't that Apple is uniquely hostile to disabled users. By most measures it does more for accessibility than its competitors. The point is that when one company controls both the platform and the only distribution channel, even well-intentioned policies can quietly shut out the people who can least afford to lose options.
Built-in features like Voice Control will keep improving — Apple's recent additions show that. But "more work needed" will always be true for somebody. The third-party developers who chase those edge cases aren't competitors to be managed; they're the long tail that makes a platform genuinely usable for everyone. Treating their use of the accessibility API as a red flag rather than the whole point gets the priorities exactly backwards.
If Apple wants the accessibility story it tells on stage to match the one disabled users actually experience, the fix isn't another keynote feature. It's making sure the next developer building a tool for a user Apple hasn't thought of can actually ship it.