# App Store Reviewer

> Analyze App Store and Play Store rejection reasons, detect guideline violations before submission, and optimize metadata (title, screenshots, description) for store review policies.

- Skill: `fatih-developer/app-store-reviewer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add fatih-developer/app-store-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fatih-developer/app-store-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fatih-developer (https://skillmd.com/u/fatih-developer)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fatih-developer/app-store-reviewer

---


# App Store Reviewer Protocol

The submission process is critical. A rejection costs days. This skill acts as a preemptive store reviewer. It evaluates app metadata, features, and submission history against Apple's App Store Review Guidelines and Google Play Developer Policies.

**Core principle:** Find the rejection before the real reviewer does. 

---

## Workflow

```
1. Identify target platform (iOS, Android, or both)
2. Analyze provided metadata and feature list
3. Cross-reference with current store guidelines
4. Flag violations (Critical, Warning, Optimization)
5. Generate submission readiness report
```

---

## Step 1: Platform Context
Determine if the review is for the App Store (iOS), Play Store (Android), or both. Their policies differ significantly (e.g., Apple's strictness on in-app purchases vs. Google's focus on permissions).

## Step 2: Input Analysis
Review the user's provided inputs:
- App Title & Subtitle
- Promotional Text & Description
- Keywords (iOS)
- Screenshots & Video descriptions
- Core features and permissions requested (e.g., location, camera)
- In-App Purchase (IAP) structures

## Step 3: Guideline Verification
Check against common rejection reasons:
- **iOS Top Rejections:** 2.1 Performance (Crashes/Bugs), 2.3.3 Accurate Metadata, 3.1.1 In-App Purchase logic, 4.0 Design (Spam/Copycats), 5.1.1 Data Collection and Storage (Privacy).
- **Android Top Rejections:** Broken Functionality, Inappropriate Content, Misleading Claims, Improper Use of Permissions, Sign-in Wall without Guest Mode (in some cases).

## Step 4: Issue Categorization
Categorize findings into:
- **[CRITICAL]** Will definitely cause a rejection. Must fix.
- **[WARNING]** High risk of rejection depending on reviewer interpretation.
- **[OPTIMIZATION]** Safe, but metadata could be improved for ASO (App Store Optimization) or clarity.

## Step 5: Output Generation
Create a structured report detailing the findings, quoting the specific guideline violated, and providing an actionable fix.

---

## Output Format

```markdown
# 📋 Store Review Readiness Report

**Target Platform(s):** [App Store / Google Play]

## 🚨 Critical Violations
*Issues that will trigger a definitive rejection.*

1. **[Violation Area]** (e.g., In-App Purchases)
   - **Guideline:** [Quote or reference the guideline, e.g., Apple 3.1.1]
   - **Finding:** [Explain what is wrong, e.g., "Using Stripe for digital goods instead of IAP."]
   - **Fix:** [Actionable solution]

## ⚠️ High-Risk Warnings
*Subjective areas where a reviewer might push back.*

1. **[Risk Area]** (e.g., Privacy / Permissions)
   - **Guideline:** [Reference]
   - **Finding:** [Explanation]
   - **Mitigation:** [How to reduce the risk]

## 💡 Metadata Optimization
*Suggestions for better conversion and ASO.*

- **Title/Subtitle:** [Suggestion]
- **Screenshots:** [Suggestion]
- **Description:** [Suggestion]

## Next Steps
[Summary of what the developer must do before hitting "Submit"]
```

---

## When to Skip
- The task is purely code formatting or UI design with no store-facing implications.
- The user is asking about marketing strategy outside the store listing.

---

## Guardrails
- **Quote the Rules:** Always back up a rejection risk with a specific guideline number or concept (e.g., "Guideline 5.1.1" or "Play Console Spam Policy").
- **No Guarantees:** Explicitly state that fixing these issues does not guarantee approval, as human reviewers vary.
- **Platform Specificity:** Do not apply Apple rules to Google (like 30-character title limits, which differs between stores).

---

## References
See `references/EXAMPLES.md` for a worked case.