An App Store rejection checker that runs in Claude Code
I built this Claude Code skill to catch App Store rejection risks before I submit my own apps. Point it at your iOS repo and it reads the code, the project config, and your store copy the way a reviewer would, then reports what is likely to get rejected: the guideline number, the evidence it found, a fix, and how confident it is. Every run fetches the App Store Review Guidelines from Apple's site first, so a finding quotes the guideline as it reads today. It runs in Codex, Cursor, and Gemini CLI too.
> Install the skill from github.com/dabodamjan/app-store-rejection-checker and check this app for App Store rejection risks.
✓ Fetched the live App Store Review Guidelines
✓ Inventoried the project targets, plists, entitlements, dependencies
✓ Static checks
✓ Semantic review
→ Report ready: findings by severity, then confidence, each with evidence and a fix
What a finding looks like
Every finding in the report has this shape, headed by the guideline number it cites or the upload validation it trips. This one is the example from the repository README. The launch post has the story of running it on my own app.
### [5.1.1(v)] Account creation without in-app account deletion Confidence: review-risk Evidence: FirebaseAuth in Podfile.lock; SignUpView.swift implements registration; no account deletion UI or deleteUser call anywhere in Sources/. Why it matters: "If your app supports account creation, you must also offer account deletion within the app" (live guideline text). Deactivation-only flows are explicitly insufficient, and support-email routes are only acceptable in highly regulated industries. Scaffolded codebases often wire up auth without a delete flow. Fix: add a delete-account action in settings that removes the Firebase user and all associated backend records, then re-run this audit.
What it checks
Nine audit areas. The chip is the guideline section where there is one.
Completeness signals
Demo account and review notes quality, placeholder content.
Metadata accuracy
Description vs actual code, screenshots, name and keyword rules, age rating answers.
Payments
Digital goods outside IAP, restore purchases, subscription disclosure, loot box odds.
Minimum functionality
Web-wrapper fingerprints, thin AI-wrapper patterns.
Differentiation
Saturated-category exposure, template output signals.
Login services
Social login without a privacy-protecting alternative.
Privacy
Purpose strings, privacy manifest, account deletion, App Tracking Transparency, third-party AI data sharing.
Special categories
Kids, medical, gambling, VPN, crypto, finance, user-generated content obligations.
Recent rule changes
Privacy manifests, AI disclosure, the age rating overhaul, EU DMA.
Guideline numbers in the bundled references were verified against the live text on 2026-08-20.
How it works
Fetch the live guidelines
Before any checklist runs, the skill fetches the current App Store Review Guidelines from developer.apple.com and scans Apple’s news feed for review-related changes. The bundled references say where rejections usually come from. The live text is what a finding cites.
Inventory the project
It locates the Xcode project or Swift package, reads every Info.plist, entitlements file, privacy manifest, and lockfile, and reads enough source to know what the app does: accounts, payments, user content, AI features, web content, kids targeting. That classification decides which checks carry weight.
Static checks, then semantic review
The mechanical surface first: purpose strings against the APIs you link, required-reason declarations, export compliance, IAP and restore wiring, account deletion, tracking consent. Then the judgment calls: does the store description match the code, is the app differentiated enough for its category, will the review notes get a reviewer to the core flow.
Report with confidence
Findings come ordered by severity, then confidence, each with the guideline number, the live wording, evidence, a fix, and one of three confidence levels: validator-certain, review-risk, judgment-call. A Not checked section lists what the audit cannot see.
Why I built it this way
Current guideline citations
Apple updates the guidelines. A checker with last year's rules baked in drifts wrong without telling you. Every finding quotes the wording fetched during that run, and the report notes any section the fetch could not confirm.
Review of the code and the copy together
Pattern rules catch a missing purpose string. They cannot tell you that your description promises a feature the code does not ship, or that your review notes will strand a reviewer at the login screen. Those are the checks that need the store listing and the source read side by side.
A confidence label on every finding
Each finding says how sure it is and why. There are no approval odds and no invented statistics in the report.
Works in Claude Code, Codex, Cursor, and Gemini CLI
The skill is a SKILL.md plus reference files in the open Agent Skills format. It is markdown, a SKILL.md plus reference files, nothing to build. Cursor, Codex CLI, and Gemini CLI read the format natively, though support varies by agent. Copy the skill folder into the directory your agent loads skills from. Agents without native skill support can be pointed at the SKILL.md and asked to follow it.
$ git clone https://github.com/dabodamjan/app-store-rejection-checker.git
$ mkdir -p ~/.claude/skills
$ cp -R app-store-rejection-checker/skills/app-store-rejection-checker ~/.claude/skills/
> /app-store-rejection-checker
Claude Code install. Use .claude/skills/ inside one project instead of ~/.claude/skills/ to install for that project only.
How it compares
Rejection Checker vs fastlane precheck
precheck runs text-pattern rules over your App Store Connect metadata. It is fast and belongs in a CI lane. It does not read your code, and it does not fetch the App Store Review Guidelines on each run. Run both: precheck on the listing in CI, this skill on the repo and the copy before you submit.
Rejection Checker vs greenlight
greenlight is the strongest mechanical checker I found: an offline Go CLI, plus a Revyl-backed tier that runs key flows on cloud simulators, which this skill cannot do. It works from a bundled rule set. This skill re-fetches the guideline text at audit time and reads what the code and the store copy say. If you want runtime coverage, run both.
Rejection Checker vs appstore-precheck and the App Review skill sets
berkayturk/appstore-precheck combines static checks with LLM analysis and ships an eval harness. cruisediary/apple-app-review-skills and dpearson2699/swift-ios-skills are skill collections in the same format as this one, the latter under a source-available license. Compared with those, this one fetches the guidelines at audit time, labels every finding with a confidence level, and is MIT licensed.
Honest limits
- The skill sees your repository, the metadata you share, and the live guidelines. It cannot verify runtime behavior: crashes, broken links, restore-purchase flows, OAuth round trips, server-driven content. The report lists those as unchecked.
- Findings are risk assessments with stated confidence, not verdicts. App Review is run by people. No tool can guarantee approval, and this one does not claim to.
- An independent project of mine, not affiliated with or endorsed by Apple or Anthropic. App Store, Xcode, and related marks belong to Apple Inc.
FAQ
Is App Store Rejection Checker free?
Yes. It is open source under the MIT license. Claude Code, Codex, Cursor, and Gemini CLI are separate products with their own pricing.
Does it guarantee my app gets approved?
No. App Review is run by people. A clean audit means the report has no findings; its Not checked section says what it could not inspect.
Does it send my code anywhere?
The skill adds no network calls of its own beyond Apple’s public pages (the guidelines, the news feed headlines, and auxiliary policy pages when a finding depends on them) and, when a guideline fetch truncates, a web search for the missing wording. Whether your code leaves your machine depends on the agent and model you run it in, the same as for any other task in that agent.
Do I need to paste my App Store Connect metadata?
The audit runs without it, but the store listing is a real rejection surface. Paste the description, keywords, age rating, review notes, and demo account when asked and the metadata checks run too. Skip it and the report marks them as not audited instead of guessing.
Which model should I use?
The most capable one available to you. The static checks are mechanical, but the semantic review of metadata accuracy, differentiation, and review notes is a judgment task, and those findings vary with the model.
Can it run in CI?
It can, if your agent runs non-interactively; the repository does not ship a CI integration. With no user to ask for metadata, the report marks the metadata checks as not audited and continues.
Does it cover macOS, watchOS, or visionOS?
It audits the iOS and iPadOS surface. If the project also builds for other Apple platforms, the report says those targets are out of scope.
Try it
Paste this into Claude Code or Codex inside your app repo:
> Install the skill from https://github.com/dabodamjan/app-store-rejection-checker and check this app for App Store rejection risks.
I'm Damjan Dabo, an indie developer in Croatia. I've shipped Itemlist, QRGenie, and BarcodeCraft on the App Store since 2022, and this skill distills what those submissions taught me. Before publishing it, I ran it on Itemlist's 2.1 release candidate. It found small, real issues in an app I had been shipping for four years. The launch post has that story, and more of what I'm building is on the projects page.