The developer argues that his dictation app uses the Accessibility API exactly as Apple has documented it for over a decade, and that the rejection is selective enforcement of an unwritten rule. He points to the suspicious timing — Apple announced expanded system dictation and Apple Intelligence voice features at WWDC 2025 — as evidence that review is being weaponized to clear the field for Apple's own product.
The editorial frames this as a shift in the classic Sherlocking pattern: instead of merely out-competing third-party apps with built-in features, Apple is now denying them shelf space at review time. It notes that TextExpander, Raycast, Rewind, and Superwhisper all rely on the same API without being pulled, which makes the rejection look like targeted gatekeeping rather than principled policy.
The developer argues that Apple itself has shipped the Accessibility API for decades as the OS-level mechanism by which any assistive or automation tool reads and writes to other applications. A dictation tool — which lets anyone who prefers speaking to typing input text into any focused app — is a textbook use of that API, and the reviewer's narrower interpretation contradicts Apple's own documentation and a decade of accepted practice.
The high vote count and comment volume reflect widespread recognition among Mac developers that App Store rules are unwritten, selectively applied, and tend to land hardest on small shops who lack the leverage to push back. Commenters noted the pattern is familiar: incumbents and Apple-favored apps using the identical API continue to ship while a solo developer gets rejected for the same behavior.
A solo developer at MITM LLC built a dictation app for macOS and submitted it to the App Store. The app does one thing: it transcribes speech and inserts the resulting text into whichever app the user is focused on — Slack, VS Code, Mail, anything. To do that, it uses the Accessibility API, the OS-level interface Apple has shipped for decades so assistive tools can read and write to other applications on behalf of the user.
Apple rejected it. The reason given: the app was "misusing" the Accessibility API. The reviewer's interpretation was that Accessibility permissions should be reserved for users with disabilities, and that a dictation tool aimed at general users — even one that, by definition, helps anyone who'd rather talk than type — does not qualify.
This is the same API that powers TextExpander, Raycast, Rewind, Superwhisper, Loom, and roughly every productivity tool on the platform that has to talk to another app. None of those have been pulled. The developer's post on Hacker News hit 226 points in part because every commenter who ships on the Mac App Store recognized the pattern: the rule isn't written down, it's applied selectively, and it lands hardest on apps that overlap with a feature Apple is about to ship itself.
Apple announced expanded system-level dictation and on-device voice features at WWDC 2025, including deeper integration with Apple Intelligence. The timing here is not subtle. A category that was tolerated for ten years suddenly becomes "misuse" the same quarter Apple ships its own version of it. The community has a word for this, and it's been around since 2002: Sherlocked. What's new is that the mechanism has shifted from competitive feature parity to gatekeeping at review time.
The Accessibility API itself is worth understanding here. It exposes `AXUIElement` references that let one process inspect and manipulate the UI of another — read the active text field, get the cursor position, insert characters, click buttons. It requires explicit user grant in System Settings → Privacy & Security → Accessibility, and macOS prompts loudly when an app requests it. The threat model is already user-mediated. There is no technical definition of "assistive" use vs. "productivity" use — the API doesn't know, and Apple's own documentation has never drawn that line. Drawing it now, in 2026, in a single rejection email, is policy by fiat.
The HN thread surfaced developers from at least four other shipped apps who said they'd received similar rejections in the past six months, all for Accessibility-adjacent functionality, all overturned (or not) based on which reviewer they got. That's not a rule. That's a lottery. And a lottery you can't appeal is indistinguishable from a denial. Compare this to Google Play, where the Accessibility Service has a documented policy that explicitly enumerates allowed and prohibited uses, with a public appeals process. Android's policy is stricter on paper and far more predictable in practice.
There's a second-order effect worth naming. The Accessibility API is the only sanctioned mechanism on macOS for cross-app text manipulation. Every alternative — synthetic key events via `CGEventPost`, AppleScript bridges, private SPIs — is either banned for sandboxed apps or actively broken by the hardened runtime. If Accessibility is now reviewer-roulette, the entire category of "app that helps you type into other apps" no longer has a viable distribution path on Apple's store. Notion-style global capture tools, AI clipboards, voice-to-text overlays, snippet expanders — they either ship outside the store (which means no Sandbox, no notarization shortcuts, no App Store discovery) or they don't ship.
If you're building a productivity utility that touches another app's UI, three things change starting now.
First, assume the Mac App Store is no longer a viable distribution channel for this category. The serious players already left — Raycast, Rewind, Superwhisper, BetterTouchTool — and ship directly via their own download + Sparkle updates + notarization. The cost is real (you handle payments, licensing, update infrastructure), but the upside is no reviewer can kill you the week before launch. If you were planning App Store as your only channel, build the direct-download pipeline now, not after rejection.
Second, if you must ship through the store, minimize Accessibility surface area. Apps that touched Accessibility for one specific task (e.g., reading the frontmost window title for context) and got away with it tend to scope the entitlement narrowly and document it explicitly in the review notes. Apps that request blanket Accessibility for general text injection are the ones getting flagged. The reviewer is reading your `Info.plist` usage strings — make them sound surgical.
Third, watch what Apple ships in the OS in the next six months and assume those categories are closed. The pattern is consistent across a decade: Watch app → Sherlocked, Clipboard manager → Sherlocked, Window manager → Sherlocked at OS level, Password manager → Sherlocked. The category Apple announces at WWDC is the category that starts getting rejection emails in Q4. Voice dictation is now on that list. Likely next: AI-assisted writing overlays, screen-aware assistants, anything that mediates between you and another app's content.
The DOJ's Apple antitrust case and the EU's Digital Markets Act both turn on exactly this kind of behavior — opaque review policy applied selectively to apps that compete with first-party features. The MITM rejection is small in isolation; aggregated, it's evidence. Expect more developers to start publishing their rejection emails verbatim, because the regulatory pressure rewards documentation. For practitioners, the takeaway is older than the API itself: don't build a business that depends on a gatekeeper's interpretation of an unwritten rule. The Accessibility API will keep working. The App Store may not keep letting you use it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.