Stop getting your iOS and Android apps rejected. The enterprise reference and automated guard that turns App Store and Google Play rejection into a designed out failure mode.
If this saves you even one rejection, leave a star, fork it, and follow along. That is the whole ask.
Star this repo | Fork it | Follow on GitHub | Follow on X | next8n.com
A rejection costs a week. You submit, you wait days in review, you get a one line rejection, you guess at the fix, you resubmit, you wait again. This playbook turns that loop into a check you run before you ever submit.
- You catch the rejection before Apple or Google does. The guard runs against your project and names the risk while you can still fix it cheaply, not after a reviewer has already said no.
- You stop guessing at the cause. Every rejection pattern maps to the exact guideline and the exact fix, so a one line rejection email becomes a known problem with a known answer.
- The two checks that sink most submissions are covered first. A working demo account with a live backend, and a privacy declaration that matches what your app actually does at runtime, including every SDK. These are the top modern rejection causes and the playbook holds them above everything else.
- It works whether or not you write code. A developer wires the guard into the build. A non developer reads the plain English checklist and walks the submission safely.
- Every claim is real. Guideline numbers and statistics trace to a live Apple or Google source, never invented, so you are acting on the actual rules, not a guess.
If it saves you one rejection, it has paid for the ten minutes it takes to read.
No setup effort. Copy the block below, paste it into your AI coding tool, and it installs the whole playbook and wires the guard into your flow.
Set up the App Store Compliance Playbook from https://github.com/mjmirza/app-store-compliance so that from now on any iOS or Android app I build is automatically checked against Apple App Store and Google Play rejection rules before I submit it.
Steps:
1. Clone https://github.com/mjmirza/app-store-compliance into ~/repositories/app-store-compliance. If you cannot clone, read the files over the GitHub raw URLs instead.
2. Install the audit skill: copy agent-os/skill/SKILL.md plus the docs/, data/, references/, templates/, and scripts/ folders into your agent's skills directory. For Claude Code that is ~/.claude/skills/app-store-compliance/. The references/ folder is the structured tree the agent loads slices from, and scripts/ holds the guard and the metadata-audit engine.
3. Install the pre-submission guard: copy agent-os/hooks/app-store-compliance-guard.sh into your hooks directory (for Claude Code, ~/.claude/hooks/), make it executable, and register it as a PreToolUse hook on the Bash tool in settings.json so it runs before app submission commands (fastlane, eas submit, gradle bundleRelease, xcrun altool, bundletool, xcodebuild archive) and blocks on a critical rejection risk.
4. Add a standing instruction to your agent config: for any iOS or Android work, always adhere to the Apple App Store Review Guidelines and Google Play policies, run the audit before submission, and never say an app is clear to submit while a critical risk stands.
5. Run the guard against my current project and show me the ranked findings:
bash ~/.claude/hooks/app-store-compliance-guard.sh /path/to/my/app
6. Tell me exactly what you installed and how I run an audit any time.
Want only a one time check, no install? Paste this instead.
Read https://github.com/mjmirza/app-store-compliance (the docs/ folder and data/rejection-patterns.json), then audit my app at <path to my app> against every Apple App Store and Google Play rejection pattern. Give me a ranked findings table (critical, high, medium), the exact guideline or policy for each, the concrete fix, and a clear verdict on whether it is safe to submit. Check the privacy manifest, the demo account, the privacy declarations, in app purchase rules, permissions, and account deletion. Then audit the store listing with scripts/metadata-audit.py against the metadata directory if I have pulled it.
If you are inside this setup already, the slash command /app-store-audit runs the same audit.
- Star the repo so more developers find it before they get rejected.
- Fork it and adapt the checklist to your own stack.
- Follow for more practitioner grade playbooks. GitHub @mjmirza, X @MirzaJhanzaib, and next8n.com.
Sharing it with one teammate who is about to submit an app is the highest compliment.
AI coding tools changed the math. Anyone can build a mobile app in an afternoon now, and they are. App releases in the first quarter of 2026 were up about 60 percent year over year across both stores, and around 80 percent on iOS alone. New submissions grew roughly 30 percent to nearly 600,000 in a single recent period. The working theory across the industry is that AI assisted coding tools, Claude Code among them, are behind the surge.
Here is the trap. The stores did not loosen the rules to match the flood. They tightened them. Many AI built apps now fail before they ever reach a user.
- Apple reviewed about 7.77 million submissions in a recent year and rejected roughly 1.93 million of them, nearly one in four.
- In one year Apple rejected more than 320,000 submissions for spam, copying, or being misleading, removed over 17,000 for bait and switch, and stopped more than 37,000 potentially fraudulent apps.
- Google blocked more than 1.75 million Play submissions in 2025 for policy violations and stopped over 255,000 apps from gaining excessive access to sensitive data.
- Since late 2025, an app that sends personal data to an external AI without a consent modal naming the provider is rejected. No disclosure, no approval.
- The top modern Apple upload rejection is a missing privacy manifest, enforced since 2024, and most people building fast with AI have never heard of it.
You can ship an app in an afternoon. You can also burn a week of rejection cycles, or a suspended developer account, the same afternoon. This playbook is the difference.
Sources. TechCrunch on the AI driven surge, Apple App Store Review Guidelines, Google Play policy center, and the rejection statistics cited inline in the docs.
This works whether you write code or not.
You are about to submit an app, maybe one an agency or an AI tool built for you, and you do not want it bounced.
- Open
docs/PRE-SUBMISSION-CHECKLIST.md. - Treat every unchecked box as a reason you will be rejected. Answer each one honestly.
- The two that catch most people. A working demo account with a live backend, and a privacy form that matches what the app really does.
- Read
docs/MISTAKE-PATTERNS.mdfor the appeal playbook if a rejection already landed.
The playbook installs as an agent skill plus a guard, so your tool carries the rules for you and stops a bad submission before it leaves your machine.
Your iOS or Android project
|
v
Claude Code -- reads --> the app-store-compliance rule (always on for any iOS/Android work)
|
| when you are about to ship
v
/app-store-audit or the pre-submission guard hook
|
v
scan the project against rejection-patterns.json
|
+-- critical rejection risk found --> BLOCKED, with the exact guideline and fix
|
+-- clean --------------------------> clear to submit
The guard fires automatically before submission commands such as fastlane, eas submit, gradle bundleRelease, and xcrun altool. If it finds a critical risk, it stops the upload and tells you the exact fix. Your AI tool now refuses to help you ship a rejection.
Run a manual audit any time.
bash agent-os/hooks/app-store-compliance-guard.sh /path/to/your/app
| Path | What it holds |
|---|---|
docs/APPLE.md |
Apple rejection map, sections 1 to 5, every guideline with the trigger and the fix, plus the 2026 age rating and AI disclosure changes |
docs/GOOGLE-PLAY.md |
Google Play rejection map across every policy, plus the four level enforcement ladder from rejection to account termination |
docs/ADVANCED-2026.md |
The modern upload time layer (privacy manifests, export compliance), payments and DMA depth, the full legal layer (GDPR, EU AI Act, DSA, COPPA), gambling depth, AI content policy, and Android specifics |
docs/EU-REGULATORY-2026.md |
The EU legal hard rules with dated sources. the EU AI Act (Article 50 transparency by 2 August 2026, Article 4 literacy, Article 5 prohibitions, penalties), the Digital Markets Act and the Core Technology Fee, DSA trader status, the European Accessibility Act and EN 301 549, and the Apple 2025 and 2026 platform changes |
docs/GLOBAL-REGULATORY-2026.md |
The USA and other-global legal hard rules with dated sources. US COPPA and the state app-store age laws, the external-link rules, plus the UK, Australia, Brazil, and other jurisdictions, and what Apple tells developers to do per region |
docs/PLATFORM-MECHANICS-2026.md |
The platform-mechanics and newer-policy hard rules with dated sources. macOS notarization, Guideline 4.2 and 4.3 with the June 2026 saturation tightening, reader-app entitlement, France ANSSI encryption, visionOS and watchOS and tvOS specifics, plus Android developer verification, Foreground Service types, Play Integrity, Play Billing v8, target API, Health Connect, and the cross-cutting CSAM, UGC, accessibility, sanctions, and PCI items |
docs/BY-APP-TYPE.md |
The rejection map routed by app type. Universal, subscriptions, social, kids, health, games, macOS, AI, crypto and finance, VPN |
docs/COMPETITIVE-GAP-ANALYSIS.md |
A survey of the other open source compliance repositories, what each publishes and why, the gaps they surfaced, and what was folded in here |
docs/OPEN-SOURCE-PATTERNS.md |
What the community already codified. The fastlane precheck metadata rule set, the Android Play Policy Insights and security lints, community rejection repositories, and the Google Play pre-launch report, folded in |
docs/OTHER-STORES.md |
Huawei AppGallery, the Chinese stores, Samsung, Amazon, Microsoft, and RuStore, plus the cross store patterns worth adopting |
docs/GAMBLING-MATRIX.md |
Per country loot box and real money gambling rules, for games that ship worldwide |
docs/MISTAKE-PATTERNS.md |
The eight root cause patterns, the top mistakes, and the appeal playbook |
docs/PRE-SUBMISSION-CHECKLIST.md |
Exhaustive pre submission checklists for both stores, every item a verifiable check |
data/rejection-patterns.json |
Machine readable taxonomy of rejection patterns with detection signals and fixes. Drives the guard |
agent-os/skill/SKILL.md |
An agent skill that runs a full pre submission compliance audit |
agent-os/hooks/app-store-compliance-guard.sh |
The tested pre submission guard, usable standalone or as an agent hook |
scripts/metadata-audit.py |
Audits the live store listing (name, subtitle, keywords, description, URLs) against the metadata rejection rules, with a propose and re validate loop. A large share of rejections live in the listing, not the code |
scripts/pull-metadata.sh |
Pulls the live App Store Connect listing into a metadata directory via the asc CLI, with the Play API path documented |
references/ |
A structured, AI loadable reference tree. Rules by category (metadata, privacy, payments, design, performance, entitlements, safety, Android) and guidelines by app type, each with a detection command, generated from the taxonomy. Load the slices that match the task |
templates/REVIEW-NOTES-TEMPLATE.md |
A fill in the blanks App Store review notes template, the six sections that clear most 2.1 rejections |
docs/CREDITS.md |
Attribution for every open source repository and tool this playbook learned from |
Treat the store reviewer as an adversarial integration test that runs once, on a real device, with no access to your intentions and no patience for setup. Everything the reviewer needs has to be present, working, and obvious at submission time. A missing demo account, a backend that is not live, a permission string with no real reason, a privacy form that does not match runtime behavior. Each is a deterministic rejection, and each is preventable before you press submit.
Contributions are welcome and wanted. App store rules change constantly, and this playbook stays accurate only when many practitioners keep it current. Open an issue or a pull request, and look for issues labelled good first issue. See .github/CONTRIBUTING.md. The one standard. every factual claim traces to a live Apple or Google source, and no guideline number or statistic is ever invented.
Apple and Android logos in this README are by Flaticon under the Flaticon free license. The Apple logo and the Android robot are trademarks of their respective owners and are used here only to indicate the platforms this playbook covers.
This playbook learned from the open source community and credits every source in docs/CREDITS.md. If you reuse a pattern here that came from another project, keep that project's credit too.
Free to use, including commercially. Attribution is required. Code is MIT, content is CC BY 4.0. See LICENSE and keep a link back to this repository.
If you read this far, you are exactly who this is for. Leave a star, fork it, and follow @mjmirza.