The developer behind Whisper Pad, an offline dictation app for the Mac, built the software in part because of a hand injury that made typing painful. The app worked by using the macOS accessibility API to paste dictated text into whatever document the user was working on. Apple approved version 1.0 and let it go out free last winter. Then the developer added features, decided to charge for the app, and submitted version 1.5. Apple rejected it under Guideline 2.4.5, which governs the use of private and system APIs, and the rejection has become a case study in the murky boundary of who gets to use accessibility tools.
The core of the dispute is simple. Whisper Pad relies on the accessibility API to insert text, the same mechanism Apple restricts because it can be used to simulate user input, automate clicks and, in the wrong hands, bypass the security boundaries of the Mac. Apple’s position is that the API is reserved for assistive technologies and that a dictation app, however well intentioned, is using a system capability it was not designed to expose. The developer’s position is that dictation is itself an accessibility need, that his app exists precisely to help people who cannot type, and that the API is the only reliable way to deliver that help.
The rejection was delivered against an app that had already been approved once, which sharpens the frustration. The developer published the details of the exchange, including the guideline cited, and the story spread through the developer community as an illustration of the opaque, sometimes contradictory nature of App Store review. An app that was fine when it was free became a policy violation when it was priced, a sequence that reads to many observers as arbitrary enforcement rather than consistent policy.
The practical stakes are modest and the symbolic stakes are large. Whisper Pad has a path forward: a version that complies with Apple’s rules by using supported input methods, and a separate build distributed directly, outside the App Store, which macOS permits through notarization. Direct distribution is the escape hatch that iOS developers do not have, and it means the developer is not being put out of business. But the episode illustrates the cost of that escape: a split audience, two versions to maintain, and a developer spending energy on distribution mechanics instead of features.
The larger question is who owns accessibility. Apple has built a reputation as the industry’s leader in accessibility, shipping technologies like Voice Control, Switch Control and a built-in dictation engine that are genuinely best in class. That leadership creates a tension: the company can argue that third-party apps have no need to reach into accessibility APIs because Apple’s own tools cover the territory. The counterargument, made by the developer and his supporters, is that Apple’s tools do not cover everyone’s needs, and that the most innovative accessibility software has historically come from small developers working close to the users they serve.
The accessibility API’s dual nature is at the center of the policy. The same capability that lets a screen reader control an interface, or lets a dictation app paste text, is the capability that automation tools, bots and malware use to act without user consent. Apple has tightened access to the API repeatedly over the years, citing security, and any relaxation for one class of apps opens a door for others. That is the honest version of the company’s argument, and it is not a weak one, even if the rejection notice itself, terse and formulaic, did not make it.
The developer community’s reaction has been split along familiar lines. Some developers argue the App Store’s rules are the price of a curated platform and that direct distribution is a perfectly good outlet for apps that do not fit. Others argue that Apple’s review process has become a source of arbitrary power, wielded inconsistently, and that the company’s own interests shape the boundaries of what third parties are allowed to build. A dictation app rejected for doing exactly what a dictation app must do, after years of precedent, makes a compelling exhibit for the second camp.
The episode also highlights a structural difference between Apple’s platforms. On iOS, the App Store is the only game in town, and a rejection is effectively a ban. On the Mac, the walls are lower: notarization lets anyone distribute software, and the security model shifts the burden from review to the user’s own consent when granting accessibility permissions. Whisper Pad can survive, and the developer says it will, but the split-version reality it now faces is exactly the fragmentation that developers who fought for sideloading said would follow.
For Apple, the incident shows the delicate balance the company must strike repeatedly. The company wants to protect the security boundary of its operating systems, and it wants to be seen as the champion of accessibility, and it wants the App Store to remain the one trusted way to get software. Those three goals pull in different directions, and every rejection of a tool built for a disabled user puts the tension on public display. Whisper Pad will find its audience through direct distribution, and the policy argument will continue wherever developers gather, until Apple offers a more precise answer to the question the case poses: how does a developer prove the accessibility of a feature to the company that controls the door?
