AutoClicker
AutoClicker was the first application I built that was outright rejected from the App Store.
It's a simple auto-clicker tool for macOS that lets users set up automatic mouse clicks at customizable intervals — useful for idle games, repetitive tasks, or accessibility needs.
Apple rejected it under Guideline 2.5.1 for using accessibility APIs in an "unapproved manner." Since the app can't be distributed through the Mac App Store, I'm making it available here as a direct download.
Project Purpose & Goal
The idea for AutoClicker came from a simple need: automating repetitive clicks on macOS. Whether you're grinding through an idle game, testing UI interactions, or have accessibility needs that require automated input, there wasn't a clean native solution available.
I wanted to build something lightweight and focused— no bloat, no ads, just a tool that does one thing well. Users can configure the click interval, set a target location on screen, and let the app handle the rest.
The app was fully functional and ready for release, but Apple's review team determined that using accessibility services for automated clicking doesn't align with their intended purpose — even though the app itself isn't malicious or harmful.
Stack & Explanation
For AutoClicker, I went fully native with Swift and SwiftUI to build a clean, performant macOS app.
The core functionality relies on macOS Accessibility APIs (CGEvent) to programmatically generate click events. This is the same system that powers assistive technologies like Switch Control and Voice Control — legitimate tools for users who can't interact with their devices conventionally.
The UI is minimal by design: a settings screen to configure click intervals and coordinates, a start/stop toggle, and visual feedback showing the click location. SwiftUI made it easy to build a responsive menu bar app that stays out of the way until needed.
Development was done in VSCode and in Xcode, with testing on both the simulator and physical devices to ensure the accessibility features worked correctly outside the sandbox environment.
Problems & Thought Process
The biggest challenge wasn't technical — it was navigating Apple's review process. The app worked exactly as intended, but Apple's Guideline 2.5.1 prohibits using public APIs in "unapproved" ways.
Their specific feedback was that "granting accessibility access to an auto tapper application does not align with the intended purpose of accessibility services."
This was frustrating because the accessibility APIs are the only way to achieve this functionality on macOS — there's no alternative approach I found that would satisfy both the technical requirements and Apple's guidelines.
On the technical side, I had to work through understanding how macOS sandboxing affects accessibility permissions, and ensuring the app requested the right entitlements.
Lessons Learned
This project taught me a lot about the realities of macOS development beyond just writing code.
Platform gatekeeping is real. You can build something fully functional, well-designed, and useful — and still get rejected because it doesn't fit Apple's vision for their platform. It's a reminder that when you build for someone else's ecosystem, you play by their rules.
Accessibility APIs are powerful but restricted. macOS gives developers access to some incredible system-level features, but Apple is protective about how they're used. Understanding the line between "intended" and "unapproved" use isn't always clear until you hit the review process.
Distribution alternatives exist. Just because an app can't go on the Mac App Store doesn't mean it can't reach users. Direct distribution outside the App Store is a viable option for macOS apps that Apple won't approve.
Despite the rejection, I'm proud of what I built. It works, I still use it all the time, and I learned a ton in the process.