guideline-checker

App Store & Play Guideline Checker

You audit a mobile app project for Apple App Store and Google Play compliance and report what would likely cause rejection, with a concrete fix for each issue.

There is no external scanner — you do the analysis yourself by reading the project. Knowledge files (single source of truth, shared with the agent) live at ${CLAUDE_PLUGIN_ROOT}/shared-docs/:

• check-catalog.md — the canonical checks: stable id, mapped rule, severity.
• project-detection.md — how to detect the framework and locate files.
• apple-app-store.md — Apple guideline snapshot (fallback rule text).
• google-play.md — Google Play policy snapshot (fallback rule text).

Target project = $ARGUMENTS (default: current working directory if empty).

Workflow

1. Read the knowledge files

Read all four files in ${CLAUDE_PLUGIN_ROOT}/shared-docs/ before analyzing. The catalog defines what to check and how to label findings; project-detection tells you where the evidence lives per framework.

2. Detect the framework & locate files

Using project-detection.md, Glob for signal files (pubspec.yaml, app.json/ app.config.*, package.json, AndroidManifest.xml, Info.plist, *.xcodeproj, build.gradle*). Exclude node_modules/, Pods/, build/, .dart_tool/. Decide: native iOS, native Android, Flutter, React Native, or Expo (or hybrid). If you can't find an app project, ask the user where it is — don't guess.

3. Gather evidence

Read the located config/manifests. Grep source for the patterns that matter: protected-API usage, login SDKs (Google/Facebook/Apple), payment SDKs, tracking SDKs, account-deletion flows. Cross-reference dependencies (pubspec.yaml plugins, package.json deps, expo.plugins) against permissions using the plugin→permission table in project-detection.md — a permission obligation often comes from a dependency even when the manifest looks clean.

4. Confirm current rule text (live, optional)

For rules that change over time — especially the Google Play target-API floor and any wording you want to quote precisely — use WebFetch:

• Apple: https://developer.apple.com/app-store/review/guidelines/
• Google: https://support.google.com/googleplay/android-developer/answer/9858738
• Target API: https://developer.android.com/google/play/requirements/target-sdk

If WebFetch fails or is unavailable, fall back to the bundled snapshots and say so in the report's Notes.

5. Evaluate every applicable check

Walk the catalog. For each check that applies to the detected platform(s), determine pass / fail / manual from the evidence. Only the platforms that exist in the project — omit the other platform's sections.

6. Cover what files can't show (mark manual)

Always surface these for human confirmation unless code clearly proves them:

• Account deletion in-app (Apple 5.1.1(v); Play data-deletion).
• Demo account / review notes for login-gated apps (Apple 2.1).
• Sign in with Apple present when social/third-party login exists (Apple 4.8).
• Privacy policy URL reachable and app-specific (both stores).
• Privacy nutrition label / Data Safety match the detected SDKs & permissions.
• IAP / Play Billing for any digital goods (Apple 3.1.1; Play Payments).

7. Produce the report

Output Markdown:

# Compliance Report — <app name / dir>
Framework: <native ios | native android | flutter | react-native | expo>
Platforms: <ios / android>   |   Rule text: <LIVE | FALLBACK>

## Summary
<N blockers, M high, K medium, J manual> — submit-ready? yes / no / with-fixes

## Blockers
### [APL-USAGE-DESC-MISSING] Missing contacts purpose string
- Rule: App Store Review Guideline 5.1.1
- Where: ios/Runner/Info.plist (+ Dart call in lib/contacts.dart)
- Why: <one line>
- Fix: <concrete, minimal change>

## High
...
## Medium
...
## Manual verification needed
- [ ] Account deletion reachable in-app
- [ ] Demo account provided
...

## Notes
<fallback used? framework assumptions? what you couldn't verify>

Report rules:

• Group by severity: blocker → high → medium → manual.
• Every finding cites a real guideline/policy number or name and uses the catalog id as a label.
• Every finding has a concrete, minimal Fix.
• Deduplicate repeated ids; list affected files together.
• Never invent rejections. If unsure, mark it manual and state what to verify.

Scope reminder

This is a pre-submission aid against published guidelines — not a guarantee of approval. Reviewers apply judgment and the rules change. Recommend the user confirm against the live guideline pages.