Apple rejected my dictation app for using the accessibility API

App Store Rejection & Accessibility API

  • The app’s Mac App Store version was rejected under guideline 2.4.5 for using the Accessibility (AX) API to auto-paste into other apps via synthesized keystrokes (CGEventPost).
  • A cut‑down App Store version that only writes to the clipboard (no AX permission; user presses Cmd+V) was accepted.
  • The full-featured version is distributed directly from the developer’s site, signed and notarized by Apple, so the restriction is App Store–specific, not OS‑wide.
  • Some note similar experiences: accessibility-based dictation or automation apps often get blocked on macOS but sometimes pass on iOS, or vice versa, with inconsistent review outcomes.

Security, Privacy, and Apple’s Rationale

  • Many commenters argue Apple is justified in tightly policing the Accessibility API because it effectively grants control over the entire system: keystrokes, cursor, screenshots, and cross‑app data paths.
  • Concerns include malicious apps pasting into sensitive fields (e.g., banking) or exfiltrating data. Some emphasize that naive users would grant permissions too easily.
  • Others argue that users already must explicitly grant AX permissions and should be allowed to opt in to powerful tools; banning whole classes of apps is seen as overreach and possibly anti‑competitive.

Design of the Accessibility API

  • Multiple comments criticize the API as overly broad; it forces apps to request more power than they actually need.
  • A proposed fix: break AX into narrowly scoped, individually grantable capabilities (e.g., paste, screenshot, cursor control) instead of one “superpower” permission.
  • Counterpoint: for some disabilities, full arbitrary control via one interface is exactly what is needed, so breaking it up must not make enabling assistive tech onerous.

Platforms, Walled Gardens, and Alternatives

  • This case fuels wider debate about closed ecosystems. Some see it as another example of Apple’s controlling, inconsistent App Store regime and argue for open platforms and side‑loading.
  • Others defend curated stores as valuable for security and say users can choose different OSes if they dislike these constraints.
  • Several advocate Linux desktops as flexible, with flatpaks, app stores, and good hardware support, but acknowledge compatibility gaps (e.g., Microsoft Office, some games) and migration friction for many users.

Workarounds, Business Impact, and Developer Strategy

  • Suggestions include:
    • Treat the Mac App Store as a “discovery + license anchor” for a more capable direct-download version.
    • Offer a limited/trial App Store build and upsell to a separate “pro” app outside the store.
  • Some share that they maintain separate “App Store-safe” and “full” versions of utilities, especially those relying on AX.
  • There’s frustration with opaque and inconsistently enforced rules, but also pragmatic acceptance: many developers expect multiple rejections and learn to design around Apple’s constraints.