The post is from the developer of WhisperPad, a Mac dictation app that records speech, transcribes it, then inserts the text into whatever app the user is currently using. Apple approved a Mac App Store version that only copies text to the clipboard, but rejected the fuller version that uses Accessibility permission and CGEventPost to simulate paste into other apps. The developer’s complaint is not that Apple blocks the app entirely. The direct version is signed, notarized, and installable from the web. The problem is that App Store review treats this kind of system-wide control as crossing guideline 2.4.5, while similar utilities outside the store ship normally.
The strongest discussion landed on a simple point: this is less about dictation than about a badly scoped power tool. macOS Accessibility permission gives very broad control over the system. It can inspect
UI elements, move focus, and synthesize input. That breadth is exactly what many accessibility tools need, especially for people who cannot use a keyboard or mouse normally. It is also why Apple is wary of letting ordinary productivity apps claim it. The failure is structural. Apple has not provided narrower permissions for common use cases like pasting text, reading UI context, or controlled automation. Developers are pushed to request a permission that looks much scarier than what they actually need, and reviewers then make opaque calls about which uses count as legitimate.
People with experience shipping similar apps said the practical pattern is already established. If you want full functionality on macOS, distribute directly. If you want App Store discoverability, ship a reduced version. Several pointed out that Wispr Flow, Soniox, Handy, and other dictation or automation tools avoid the Mac App Store for exactly this reason. Others said the line is not completely arbitrary. A system that can inject text or control other apps can be abused, and some users want Apple to be strict here, especially on iPhone where the expectation of app isolation is much stronger. What annoyed even sympathetic commenters was not the existence of a boundary but how unclear and inconsistently enforced it feels. Similar CGEvent-based apps have been approved, rejected, or quietly routed around review depending on wording, reviewer, and distribution path.
The side threads added two useful bits. First, the direct-download path on macOS is better than many readers assumed. Apple notarization still lets users install the app without hacks, so the app is not dead, only barred from the App Store. Second, the developer got a concrete bug report out of the conversation. The auto-paste path hardcoded the
QWERTY key for V, which breaks on layouts like
Dvorak,
Colemak, and
AZERTY. That reinforced the broader point that once you simulate user input at this layer, you inherit all the messy edge cases of real desktop automation.
mitmllc.com