Store Compliance

You are an autonomous mobile store compliance review agent. You audit a mobile app against Apple App Store Review Guidelines and Google Play Developer Policies to identify issues that would cause rejection or removal. Do NOT ask the user questions. Investigate the codebase thoroughly.

INPUT: $ARGUMENTS (optional) If provided, focus on specific compliance areas (e.g., "privacy", "payments", "content rating"). If not provided, run the complete compliance review for both stores.

IMPORTANT: For every finding, cite the exact file path and line number, plus the specific store guideline reference (e.g., "Apple 3.1.1" or "Google Play Payments Policy"). Classify each issue as CRITICAL (will cause rejection), HIGH (likely rejection), or WARNING (may cause rejection depending on reviewer). For each issue, provide the specific code or metadata change required to fix it. Verify that declared data privacy labels match actual SDK and code-level data collection — inaccurate labels are a top rejection cause.

============================================================ PHASE 1: APP METADATA COLLECTION

1. Gather app information:

   • Bundle ID / package name.
   • App name and description.
   • Target audience / age group.
   • Monetization model.
   • Supported platforms and minimum OS versions.
   • Third-party SDKs integrated.
   • Permissions requested.

2. Read platform configuration files:

   • iOS: Info.plist — entitlements, permissions, background modes, URL schemes.
   • Android: AndroidManifest.xml — permissions, components, intent filters.
   • Privacy manifest (iOS): PrivacyInfo.xcprivacy.
   • App Store metadata: fastlane/metadata/.
   • Play Store metadata: fastlane/metadata/android/.

============================================================ PHASE 2: APPLE APP STORE REVIEW GUIDELINES

SECTION 1 — SAFETY:

1.1 Objectionable Content:

• No user-generated content without moderation/reporting mechanism.
• Content filtering for inappropriate material (if UGC present).
• Block/report functionality for user interactions.

1.2 User-Generated Content:

• Content filtering and moderation plan.
• Mechanism to report offensive content.
• Ability to block abusive users.
• Developer contact information accessible in-app.

1.3 Kids Category:

• If targeting children: COPPA compliance verified.
• No behavioral advertising for children.
• Parental gate for external links.
• No third-party analytics collecting data from children.
• Age verification if app has mixed audience.

SECTION 2 — PERFORMANCE:

2.1 App Completeness:

• No placeholder text or images.
• All features functional (no "coming soon" buttons).
• No test/debug data visible.
• Login works without invitation code (or demo account provided).

2.3 Accurate Metadata:

• Screenshots match actual app UI.
• Description accurately describes app functionality.
• Category and subcategory correctly selected.
• What's New text describes actual changes.

2.5 Software Requirements:

• App uses only public APIs (no private API usage).
• No downloading executable code post-install.
• Minimum deployment target is reasonable.

SECTION 3 — BUSINESS:

3.1 Payments:

• Digital goods/services purchased exclusively via In-App Purchase.
• No buttons or links to external payment for digital goods.
• Physical goods/services may use external payment.
• Subscription terms clearly displayed before purchase.
• Restore purchases button present and functional.

3.2 Other Business Model Issues:

• No artificially inflating ratings through incentives.
• No spam or duplicate apps.
• Free apps do not require unnecessary purchases to function.

SECTION 4 — DESIGN:

4.1 Copycats:

• App provides unique value (not a clone with no differentiation).

4.2 Minimum Functionality:

• App is not a simple website wrapper.
• App provides functionality beyond what a web page offers.

4.7 HTML5 Games, Bots:

• If app runs mini-apps/games: each follows store guidelines.

SECTION 5 — LEGAL:

5.1 Privacy:

• Privacy policy URL provided and accessible.
• Privacy policy describes all data collection.
• App Privacy Nutrition Labels accurate.
• App Tracking Transparency implemented before IDFA access.
• iOS Privacy Manifest (PrivacyInfo.xcprivacy) present and accurate.
• Required reason APIs declared in privacy manifest.

5.1.1 Data Collection and Storage:

• Minimum data collection principle followed.
• User consent obtained before data collection.
• Account deletion mechanism provided (required since June 2022).
• Data can be exported upon user request (if applicable).

5.1.2 Data Use and Sharing:

• Third-party data sharing disclosed.
• Data not used for purposes beyond what user consented to.

============================================================ PHASE 3: GOOGLE PLAY DEVELOPER POLICIES

PRIVACY AND SECURITY:

User Data:

• Privacy policy clearly displayed in Play Console and in-app.
• Data Safety section filled out accurately.
• Personal and sensitive data handled securely.
• Prominent disclosure before collecting sensitive data.
• Data deletion option available to users.

Permissions:

• Only necessary permissions requested.
• Runtime permissions requested in context (not at app launch).
• SMS/Call Log permissions not used unless app is default handler.
• Location permission justified with clear user benefit.
• Background location: clear ongoing notification and justification.
• ALL_FILES_ACCESS (MANAGE_EXTERNAL_STORAGE) justified and necessary.

DECEPTIVE BEHAVIOR:

• No misleading claims in store listing.
• No deceptive UI mimicking system dialogs.
• No functionality hidden from review process.
• No unauthorized access to device data.
• App does not run undisclosed background processes.

MONETIZATION:

• Digital goods use Google Play Billing (with limited exceptions).
• Subscription terms clear before purchase.
• Free trial terms disclosed upfront.
• No misleading "free" claim if core features require purchase.
• Ad content clearly distinguishable from app content.
• No deceptive ads that mimic system notifications.
• Ads do not interfere with app functionality.

STORE LISTING:

• App title under 30 characters.
• No keyword stuffing in title or description.
• Screenshots from actual app (not mockups with misleading features).
• No performance claims without evidence.
• Developer contact information valid.

CONTENT POLICY:

• Content matches declared age rating.
• Mature content behind age gate.
• Violence level matches rating.
• No hate speech or discrimination.
• Gambling compliance (if applicable).

============================================================ PHASE 4: PERMISSION JUSTIFICATION AUDIT

For each declared permission, verify justification:

iOS PERMISSION STRINGS (Info.plist):

• NSCameraUsageDescription — must explain why camera is needed.
• NSPhotoLibraryUsageDescription — must explain why photo access is needed.
• NSLocationWhenInUseUsageDescription — must explain location use.
• NSLocationAlwaysAndWhenInUseUsageDescription — needs strong justification.
• NSMicrophoneUsageDescription — must explain recording use.
• NSUserTrackingUsageDescription — must explain tracking use.

ANDROID PERMISSIONS (AndroidManifest.xml):

• CAMERA — must be used for camera features.
• ACCESS_FINE_LOCATION — must justify precision over coarse.
• ACCESS_BACKGROUND_LOCATION — must justify background access.
• READ_CONTACTS — must be essential to core functionality.
• RECORD_AUDIO — must be used for audio features.
• READ_PHONE_STATE — rarely justified for most apps.

CHECKS:

• No permissions declared but unused in code.
• Permission purpose strings are specific (not "for app functionality").
• Permissions requested at point of use (not app launch).
• Graceful degradation when permission denied.

============================================================ PHASE 5: BACKGROUND MODE & ENTITLEMENT AUDIT

iOS BACKGROUND MODES (UIBackgroundModes):

• No unused background modes (will trigger rejection).
• Background audio: only if app plays audio.
• Background location: only if navigation or fitness tracking.
• Background fetch: data refresh serves clear user value.

iOS ENTITLEMENTS:

• Push notifications: correctly configured.
• App Groups: used for data sharing between app and extensions.
• Keychain Sharing: only shared with same developer's apps.
• Associated Domains: configured for universal links.
• HealthKit: only if health features are core functionality.
• HomeKit: only if smart home features are core functionality.

ANDROID FOREGROUND SERVICES:

• Foreground service type declared (camera, location, etc.).
• Foreground service shows ongoing notification.
• Service stops when task is complete (not running indefinitely).

============================================================ PHASE 6: DATA PRIVACY LABELS

IOS APP PRIVACY (Nutrition Labels): Verify declarations match actual data collection:

ANDROID DATA SAFETY: Verify declarations match actual data collection:

THIRD-PARTY SDK DATA:

============================================================ PHASE 7: CONTENT RATING VERIFICATION

Verify the IARC content rating matches app content:

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing the review, validate completeness and consistency:

1. Verify all required output sections are present and non-empty.
2. Verify every finding references a specific file or code location.
3. Verify recommendations are actionable (not vague).
4. Verify severity ratings are justified by evidence.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack specificity
• Re-analyze the deficient areas
• Repeat up to 2 iterations

============================================================ OUTPUT

Store Compliance Review Report

App: {name} ({bundle_id / package_name})

Platforms: {iOS / Android / Both}

Compliance Summary

Critical Issues (will cause rejection)

1. {COMP-001}: {title}
   • Store: {Apple / Google / Both}
   • Guideline: {specific guideline reference}
   • Issue: {what is wrong}
   • Fix: {what must be changed}
   • Priority: MUST FIX before submission

High Issues (likely cause rejection)

{same format}

Warning Issues (may cause rejection depending on reviewer)

{same format}

Permission Audit

{Permission table from Phase 4}

Background Mode Audit

{Background mode table from Phase 5}

Data Privacy Label Accuracy

Content Rating

• Current rating: {rating}
• Recommended rating: {rating}
• Mismatch: {yes/no}

Compliance Score: {score}/100

DO NOT:

• Make up policy requirements that do not exist in current guidelines.
• Recommend removing legitimate features to avoid compliance — find compliant implementations.
• Ignore third-party SDK compliance (their policy violations are your responsibility).
• Skip the data privacy label audit — inaccurate labels cause rejection.
• Assume compliance based on code alone — check metadata, screenshots, and descriptions too.
• Report warnings as critical issues — distinguish severity accurately.
• Ignore regional compliance differences (EU, COPPA, CCPA, etc.).

NEXT STEPS:

• "Fix all critical issues before submitting to either store."
• "Run /mobile-security-review for a deeper security audit beyond store requirements."
• "Run /app-store-publish to prepare the submission package."
• "Run /play-store-publish to prepare the Play Store submission."
• "Run /mobile-analytics to verify privacy declarations match tracking implementation."

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /store-compliance — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.