Why Apple's App Store Kills AI Dev Tools That Use Accessibility APIs
Why Apple's App Store Kills AI Dev Tools That Use Accessibility APIs
Apple rejected millions of apps in 2024 alone, many through automated review systems that flag apps at the code level without understanding context or declared purpose. For AI developer tools that rely on accessibility APIs, this is not an edge case - it is the primary distribution risk.
What Accessibility APIs Actually Let You Do
macOS accessibility APIs expose the full UI tree of any running application as structured, machine-readable data. An AI agent using these APIs can:
- Read text content from any application window, including value fields, labels, and menu items
- Identify and interact with buttons, sliders, dropdowns, and custom controls by semantic role rather than pixel position
- Navigate between applications without simulating mouse movement
- Subscribe to UI change notifications to react to state changes in real-time
This matters because structured UI data is fundamentally more reliable than screenshot-based approaches. You do not need to OCR a screenshot to know a button says "Save" - the accessibility tree tells you directly that there is an AXButton with AXTitle = "Save". No computer vision pipeline, no coordinate guessing, no resolution dependency.
Why the App Store Is Hostile to This
Apple's review process has a stated purpose for accessibility APIs: assistive technologies. Screen readers, voice control for users with motor disabilities, switch access devices. That is the intended use case, and it is reflected in how the review guidelines are written.
Using the same APIs to build an AI agent that automates developer workflows occupies gray territory. Review teams - and increasingly automated review systems - flag this as misuse even when the technical implementation is identical to approved assistive technology.
The rejection reasons developers report are systematically frustrating:
- "Your app uses private APIs" - the accessibility APIs used are entirely public and documented at
developer.apple.com. They are not private. - "Your app duplicates system functionality" - this is applied when an app does something the OS can already do, but accessibility automation extends capability rather than duplicating it.
- "Your app does not meet guidelines" - the catch-all that provides no actionable path to approval.
Apple's own data shows a 20% rise in app rejections in 2024 compared to the prior year, driven largely by AI-adjacent applications that push the boundaries of what review systems expect. Apps with novel AI-driven experiences consistently confuse automated reviewers that expect predictable permission patterns.
The Specific Pattern That Triggers Rejection
The problem is not accessibility permission itself - many approved apps request it. The problem is the scope of what an approved app is expected to do with it.
A screen reader app requests accessibility permission and reads content aloud. Review understands this.
An AI coding assistant requests accessibility permission and then reads content from Xcode, Terminal, a browser, a documentation viewer, and several other apps simultaneously while taking autonomous actions. Review flags this as suspicious even if every individual action is technically permitted.
The intent - building a more productive development environment - is irrelevant to automated review. What matters is the permission footprint and the behavioral pattern.
Native Distribution: Not a Workaround, the Real Architecture
The tools that have always worked this way are instructive. Keyboard Maestro has distributed outside the App Store for over a decade. Hammerspoon is open source and direct-download only. BetterTouchTool, Alfred, Raycast (for its power user features) - all native distribution. These tools need to use system APIs freely, and they built distribution models that support that.
For AI development tools, this is not a compromise. Direct distribution via notarized DMG or Homebrew cask gives you:
- Full accessibility API access without review gatekeeping
- Faster iteration cycles - shipping a fix without a review queue that takes days
- Ability to use additional APIs that are off-limits in the sandboxed App Store environment
- No revenue share on paid products
The notarization process Apple provides for direct distribution still validates the app against malware and verifies code signing. You get the security assurance without the behavioral restrictions.
What You Give Up
Direct distribution means no App Store discovery. For consumer apps that benefit from browse traffic and featured placements, this is a real cost. For developer tools - where most adoption comes from GitHub readmes, documentation sites, Hacker News, and word of mouth in developer communities - the App Store contributes surprisingly little.
Developer tool adoption correlates with trust and capability, not storefront visibility. Developers who find a tool through a recommendation or a GitHub star are more likely to adopt it than developers who stumble on it in a category browse.
The Irony
Apple built some of the best accessibility APIs available on any desktop operating system. The documentation is detailed, the APIs are stable across OS versions, and the data quality is excellent. They clearly invested heavily in making programmatic UI access reliable and comprehensive.
Then they built a distribution system that makes it nearly impossible to ship apps that take full advantage of what they built.
The developers who want to use these APIs for legitimate power-user and developer tooling purposes end up distributing outside Apple's ecosystem entirely. That is not a great outcome for anyone involved.
Fazm is an open source macOS AI agent that uses accessibility APIs for desktop automation. Open source on GitHub.