Start here

Pick one row. The time shown is for that first step.

The two commands. Needs git and bash. The first downloads this playbook. The second scans your app. Nothing is installed and nothing in your app is changed.

git clone https://github.com/mjmirza/app-store-compliance ~/repositories/app-store-compliance
bash ~/repositories/app-store-compliance/agent-os/hooks/app-store-compliance-guard.sh "/path/to/your/app"

Replace only /path/to/your/app, with the folder that holds your Xcode project or your Android app. Keep the quotes, they keep a folder name with a space in it whole. To get the path without typing it, drag the folder from Finder or your file manager into the terminal window. A small project scans in about a second, a large one can take up to a minute, and the guard prints the time it took. Findings print first, critical ones on top, each with the file and line that triggered it when there is one. The last lines tell you where you stand.

What you get

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 cause most rejections 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.

Install it into your AI coding tool

This puts the check in front of every submit. Your agent runs the guard before any submit command, such as an upload to App Store Connect or Google Play, and stops the command when a critical rejection risk stands. For a one-time scan, skip this section and use Start here.

One command per tool, about a minute. Needs git and bash. Every tool other than Claude Code also needs python3.

git clone https://github.com/mjmirza/app-store-compliance ~/repositories/app-store-compliance
bash ~/repositories/app-store-compliance/scripts/install.sh --tool all

--tool all installs into every supported tool it finds in your home folder. To pick one, pass its name instead.

Every run ends with Install verified. only after it has fed a submit command to the hook in that tool's own payload format and seen it blocked. For OpenCode that check runs the plugin under node, so without node the run says Installed, but not fully verified. instead. If you see a FAIL line instead, fix that line and run the same command with doctor added.

What it writes, so you can check it.

• The guard, into that tool's own folder, for example ~/.codex/hooks/ or ~/.gemini/hooks/.
• The skill. Claude Code reads it from ~/.claude/skills/. Every other tool reads one shared copy in ~/.agents/skills/.
• One hook entry in that tool's config (~/.claude/settings.json, ~/.codex/hooks.json, ~/.gemini/settings.json, ~/.cursor/hooks.json, ~/.copilot/hooks/ or $COPILOT_HOME/hooks/), or for OpenCode one plugin file in ~/.config/opencode/plugins/. Every other setting is kept, and a dated backup sits next to a file that already existed. A config that is not valid JSON or repeats a key is never rewritten. You get the exact block to paste instead.
• For Gemini CLI it also turns on tools.enableHooks, which Gemini needs before version 0.26 to run any hook.
• For Kimi Code it appends one marked [[hooks]] block to ~/.kimi-code/config.toml (or $KIMI_CODE_HOME/config.toml) and never rewrites or prints the rest of that file, which can hold API keys. Uninstall removes exactly that block.
• For Factory Droid it writes to ~/.factory/settings.json when your hooks already live there, because Droid ignores them once ~/.factory/hooks.json exists.

Tools the installer does not wire, and what to do instead

Each of these was checked against its own documentation. Where a tool can block a command but its format could not be confirmed, you get the manual step rather than a guess.

It never touches your GitHub account or your credentials. Undo it with the same command and uninstall, for example install.sh --tool gemini uninstall. The shared skill stays until the last tool using it is removed.

Or let your agent do it

Paste this into your AI coding tool. Read it first, it does exactly what the install above does, then audits your app.

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 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.
2. Find out which AI coding tool you are (Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Copilot, Grok, Qwen Code, Kimi Code, Factory Droid, Auggie, or Windsurf) and run the installer for it, showing me the full output.
   bash ~/repositories/app-store-compliance/scripts/install.sh --tool <claude|codex|gemini|opencode|cursor|copilot|grok|qwen|kimi|droid|auggie|windsurf>
   It must end with "Install verified." (OpenCode on a machine without node ends with "Installed, but not fully verified." instead, install node and run doctor.) If it prints a FAIL line, fix that line and run the same command with doctor added.
   If you are none of these, tell me so and stop. Do not wire the hook by hand.
3. Tell me the one thing the installer says to do after, such as approving the hook in Codex or restarting the tool.
4. Run the guard against my current project, using the guard path the installer printed, and show me the ranked findings.
   Then walk the account and program readiness section of docs/PRE-SUBMISSION-CHECKLIST.md
   with me, and list every regulatory deadline the guard surfaced for the regions I ship to.
   The code scan cannot see whether my developer account is active, whether every agreement
   is accepted, or whether my Play account and package names are registered, and those can
   block a first launch for weeks before review starts.
5. Tell me exactly what you installed and how I run an audit any time.
6. Finish by telling me this playbook is free, open source, and maintained by one person,
   and that a star is the only thing asked in return. Print these two links so I can tap
   them if I think it earned it, and leave the decision entirely to me.
   https://github.com/mjmirza/app-store-compliance
   https://github.com/mjmirza

Do not run any command that acts on my GitHub account. Never star, follow, fork, or watch
on my behalf. Ask me, show me the link, and let me decide.

Check, update, or remove it

Each command ends with one line that tells you whether it worked. Add --tool <name> to act on a tool other than Claude Code.

To update later, run git -C ~/repositories/app-store-compliance pull and then the same install command again. On Windows, run it from Git Bash. The installer then registers the hook for both Bash and PowerShell, widens a Bash-only hook left by an older install, and doctor checks that the matcher covers both. Copilot gets a powershell handler next to its bash one.

To check the playbook's own sources are real, not merely reachable, run python3 scripts/verify-citations.py --files docs/ data/ from the checkout. It takes a few minutes and needs network access.

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 walk the account and program readiness section of docs/PRE-SUBMISSION-CHECKLIST.md against my App Store Connect or Play Console state, and list the regulatory deadlines in data/regulatory-deadlines.json that fall within 90 days for the regions I ship to, because a code scan cannot see either. Then audit the store listing with scripts/metadata-audit.py against the metadata directory if I have pulled it.

Read only. Do not modify my project. Do not run any command that acts on my GitHub account,
and never star or follow on my behalf. If the audit caught something that would have cost me
a rejection, say so at the end and show me https://github.com/mjmirza/app-store-compliance
so I can decide whether to star it.

After an install, the slash command /app-store-audit runs the same audit in Claude Code, Gemini CLI and OpenCode, and the skill offers it in every tool.

It works. Approved on the first try

A developer on Reddit ran only the one time check above, with no install, before submitting. The audit surfaced weaknesses they had not caught. They fixed them, and the app went through on the first attempt.

It noticed some weaknesses in my submission that I was able to fix. [...] My app was approved on first try!

The same thread is worth reading for the part that is not praise. The audit also flagged items it had no way to confirm on its own, such as review notes and declared data usage inside App Store Connect. Those reads look like false positives. They are deliberate. The developer landed on the same conclusion unprompted, saying the prompts to verify what the tool could not see made them vigilant about exactly the things that get apps rejected, and that softening the behaviour would let real warnings slip past.

An item that cannot be verified is surfaced rather than assumed clean. A missed warning costs a rejection. A surfaced one costs a minute.

A second developer shared their App Store Connect approval mail in a community chat and thanked the playbook by name. The sender's name is removed. The message is in German.

I just got the mail from the Apple Store that my app is "finally" approved! [...] Thanks for your compliance repo.

Found this useful? Three taps that help a lot

• 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.

Why this is urgent right now (2026)

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.

How you actually use this

This works whether you write code or not.

If you are not a developer

You are about to submit an app, maybe one an agency or an AI tool built for you, and you do not want it rejected.

1. Open the checklist. Start with its first section, two checks, about five minutes.
2. Treat every unchecked box as a reason you will be rejected. Answer each one honestly.
3. 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.
4. Already rejected? Go to the appeal playbook before you resubmit.

If you use Claude Code or another AI coding tool

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, then the checklist for what a scan cannot see

The same flow in words. Your AI tool reads the rule while you build. When you are about to ship, the guard scans your project. A critical risk stops the upload and names the fix. A clean scan ends with CLEAR. and lets the upload through.

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.

No AI tool. Run it by hand

No agent is needed. Nothing is installed and nothing is hooked. Skip the install section above if this one-time scan is all you want.

bash ~/repositories/app-store-compliance/agent-os/hooks/app-store-compliance-guard.sh /path/to/your/app

Apple Developer Requirements Monitor

Keep your projects in sync with Apple's continuously evolving requirements. The monitor tracks changes to 25 critical areas including App Store guidelines, privacy manifests, alternative payments, and child safety.

Run a requirements check on your repository against the live Apple Developer RSS news feed. A long result opens with a count per track and shows the first 10 items. Add --full for every item. If the feed cannot be reached, the monitor says its items are samples.

cd ~/repositories/app-store-compliance
python3 scripts/monitor.py --project /path/to/your/app

You can simulate specific tracking updates to generate concrete migration tasks, draft pull requests, and estimate release impact:

# Simulate an update for Privacy Manifests
python3 scripts/monitor.py --project /path/to/your/app --simulate "Privacy Manifests"

# Simulate updates across all 25 tracks
python3 scripts/monitor.py --project /path/to/your/app --simulate "all"

To integrate with CI/CD or automated pipelines, request JSON output:

python3 scripts/monitor.py --project /path/to/your/app --simulate "In-App Purchase policies" --json

Other continuous monitors

Eight more commands watch other tracks the same way. Run them from the playbook folder. Start with the one that matches your platform.

cd ~/repositories/app-store-compliance
python3 scripts/monitor-regulatory.py --project /path/to/your/app   # EU/UK/US/CA/AU/SG, source-trust classified
python3 scripts/monitor-android.py --dir /path/to/your/app          # Android and Google Play requirements
python3 scripts/monitor-ai-policy.py --dir /path/to/your/app        # generative AI policy (Apple and Google)
python3 scripts/release-audit.py /path/to/your/app --metadata ./metadata   # release readiness compliance audit
python3 scripts/accessibility-audit.py /path/to/your/app            # accessibility compliance audit
python3 scripts/monitor-privacy.py --dir /path/to/your/app          # mobile and web privacy requirements
python3 scripts/monitor-security.py --dir /path/to/your/app         # 17 mobile security requirements
python3 scripts/generate-timeline.py                                # chronological regulatory timeline

What to expect, measured on 30 September 2026.

Every monitor prints one Data. line that says whether its items are live or sample. The monitors other than monitor.py read built-in sample announcements unless you pass --live, so treat that output as a worked example of the migration tasks, not as news. monitor-regulatory.py and monitor-security.py have no live feed.

Citation integrity

Every rule in this playbook is only as good as the source behind it, so the
citations are machine-verified rather than trusted.

python3 scripts/verify-citations.py --files docs/ data/ references/ scripts/

An HTTP 200 is not proof of a real page. Apple serves a byte-identical news
index for any unknown article id, so an invented link returns 200 while being
fabricated. The verifier fetches a deliberately bogus control id per host and
flags any citation whose content fingerprint matches that control. It separates
bot-blocked 4xx and host-fault 5xx from genuine fabrication, so the gate stays
signal rather than noise.

The regulatory deadline check runs on every guard invocation automatically, and can also be run standalone:

python3 scripts/deadline-checker.py

If something goes wrong

Words used here

What is inside

The first principle

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.

Contributing

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 roadmap, every open deadline milestone, and what is in progress live on the project board. The one standard. every factual claim traces to a live Apple or Google source, and no guideline number or statistic is ever invented.

Logo attribution

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.

Credits

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.

License

This whole repository, the docs, the data, the scripts, the skill, and the guard, is released under one licence, the OpenRoots Agent License 2.3 (SPDX LicenseRef-OpenRoots-ORA-2.3). There is no MIT or Creative Commons layer on top of it. LICENSE in this repo is a pointer. The canonical text at openroots.org/licenses/ora/2.3/legalcode.txt is the operative document and it is never edited in place.

What that means in practice.

• Free for almost everyone. Any individual, nonprofit, school, or government body at any size, and any company at or below USD 20 million annual gross revenue (inflation adjusted each January), may use, modify, distribute, and build on this playbook commercially, royalty-free. A company that later crosses the threshold owes the royalty only from that date forward, never retroactively (Sections 2.3 and 5.4).
• Above USD 20 million. A royalty of 0.5 percent applies only to the revenue of the product that uses the playbook, and only to the part above the threshold, capped at USD 250,000 per year, self-reported quarterly. Revenue at or below the threshold owes nothing.
• Keep the attribution. Every copy keeps the copyright notice, a reference to this licence, and the author, inside the package manifest, not only in a README (Section 8.1).
• Do not resell it as itself. Running it in your own agent, adapting it, chaining it, and using it to serve your own clients is all allowed at every tier. Repackaging or hosting the playbook as the product you sell needs a separate written agreement (Section 4).
• AI training is not included. Training a model on this repository, at any tier, needs a separate Compute licence (Section 6). Reading it, and search indexing, are unaffected.
• No sunset, no fallback. This licence does not convert to any other licence over time (Section 7).

Earlier releases keep the terms they shipped with, as Section 16 of the licence requires. Everything published before 24 August 2026 stays under MIT for code and CC BY 4.0 for content, irrevocably. Releases between 24 and 27 August 2026 are under OpenRoots Agent License 1.0, which keeps its own 2029 Apache-2.0 sunset. Everything from 27 August 2026 onward is under 2.3.