The post is from the maker of WhisperPad, a Mac dictation app built for people who want local speech-to-text and hands-free text entry. The direct-download version can transcribe audio and automatically paste the result into whatever app is active. That requires macOS Accessibility permission and synthetic keyboard events. Apple rejected that version from the Mac App Store under guideline 2.4.5, so the store build was cut down to a safer clipboard-only workflow where the user pastes manually. The app can still ship outside the store because Apple notarization and App Store review are different gates.
For platform-dependent startups, the lesson is blunt: if your product needs broad OS hooks, assume the App Store is a marketing channel with policy risk, not the canonical distribution path.
Frustrated and resigned. Most commenters think Apple’s security concern is real because Accessibility is massively overpowered, but they are tired of opaque review rules, inconsistent enforcement, and a platform setup that forces legitimate apps to choose between degraded App Store versions and full-featured direct downloads.
01 The root problem is not this app.
It is that macOS Accessibility is doing the job of several narrower permissions at once. That makes Apple’s rejection logic structurally broken. Developers must ask for far more access than they actually need, then hope a reviewer agrees their use case is “accessible enough.” At the same time, commenters with direct accessibility experience pushed back on the idea that the API itself should be weakened. Full computer control is exactly what some disabled users need. The missing piece is a split model where true assistive tools can still get broad control, while ordinary automation apps request smaller capabilities.
Apple is trying to solve a permissions design failure with review policy. That leaves both accessibility users and developers with a bad compromise.
02 The Mac and iPhone should not be lumped together here.
Several commenters strongly preferred Apple’s lockdown on iOS because they treat the phone as their one trusted personal computer where third-party apps should not inspect or control anything else. On macOS, that argument weakens because Accessibility already requires explicit user consent and because desktop software has long depended on cross-app control. The useful framing is not “open versus closed.” It is that users want stricter defaults on phones and more delegated trust on desktops.
Platform policy should follow platform expectations. A desktop that cannot host trusted automation feels broken in a way a locked-down phone does not.
03 The workable distribution pattern is already settled.
Keep the App Store build inside the lines and ship the real version directly. Multiple developers said they use the same approach for dictation or automation tools, and the author clarified that the direct build is still signed and notarized by Apple. The App Store is therefore acting less like the platform and more like a constrained storefront with its own product limitations.
For Mac utilities that need system control, direct distribution is not a fallback. It is the primary product path.
04 Simulating paste is not just a policy problem.
It is a reliability trap. A commenter pointed out that hardcoding the V key breaks on Dvorak, Colemak, and AZERTY. The author confirmed the bug immediately. That sits alongside other failure modes the author mentioned, like focus changes and slow-loading fields. Synthetic input sounds simple until international layouts, app timing, and state changes make it fragile.
Even if Apple approved this path everywhere, input emulation remains operationally brittle. Products built on it inherit constant edge-case work.
01 Breaking Accessibility into tiny permissions is not an obvious win.
Commenters argued that broad control is the whole point for many assistive tools, and over-fragmenting it could make essential software harder for disabled users to enable and use. The better answer may be layered permissions rather than a total breakup of the current model.
Least privilege is good engineering, but accessibility software sometimes genuinely needs full privilege. Policy has to preserve that path.
02 The Mac App Store may be less important than developers assume.
One commenter said they avoid it entirely and would rather install a direct download or even choose a slightly worse alternative than use the store. If that view is more common among Mac power users, then the commercial damage from rejection is smaller for this category of software than it would be on iPhone.
For some Mac audiences, App Store presence is optional. Distribution pain does not always equal demand loss.
03 Apple’s line may be defensible even if its execution is sloppy.
A few commenters accepted that auto-pasting into arbitrary apps creates obvious abuse potential, especially around sensitive fields, and argued the deeper problem is not the existence of a boundary but the lack of a clear, consistently enforced one. One person also noted that ergonomic hardware solved their own typing pain without needing software that controls other apps at all.
Not every accessibility-adjacent need should automatically grant cross-app control. Some of this demand can be met by clearer policy or by non-software alternatives.