# Skill: Clear App Store Review Guidelines to pass Apple's review on the first try

> Lets an AI coding/design agent prepare an iOS app against Apple's top rejection causes — crashes, incomplete features, misleading metadata, IP violations, In-App Purchase bypass, and privacy consent gaps — before the build is submitted to human review.

Source: sodigi·learn — publish/trebovaniya-app-store · https://sodigi.io/learn/publish/trebovaniya-app-store

## When to use
- An iOS build is being prepared for first submission to the App Store.
- A build was rejected and the rejection cites a Guideline number (2.1, 3.1.1, 5.1, etc.).
- Performing a pre-submission self-audit to reduce rejection risk.
- The app includes AI features that send user data to external services.

## Core rules
- Apple uses real human reviewers who manually open the app and test it — nothing slides through on autopilot.
- A crashed screen during review = instant rejection, no discussion; stability is the highest-priority check.
- The app must be a finished product: no "Coming soon" screens, no lorem ipsum placeholders, no dead buttons, no test data visible on any screen the reviewer can reach.
- The store listing (description, screenshots, keywords) must exactly match what is inside the submitted build — any gap is grounds for rejection under metadata accuracy rules.
- Digital goods and subscriptions sold inside the app MUST go through In-App Purchase (IAP); routing users to an external payment site for digital content bypasses rule 3.1.1 and causes rejection.
- Physical goods and real-world services (food, taxis, physical products) are exempt from the IAP rule and may use any payment method.
- Third-party content (logos, music, video, fonts, characters) requires documented rights; Apple may ask for proof.
- Every app that sends user data to an external AI service must show an explicit consent screen naming the provider (e.g., OpenAI, Anthropic) before any data is sent — "third parties" is not specific enough.
- Provide a working demo account with full access in the App Review Information field whenever the app has a login screen.

## Procedure
1. Install a clean build on a device with no pre-existing app data. Walk through every screen the reviewer can reach. Fix any crash or freeze before submitting.
2. Search for and remove all placeholders: lorem ipsum text, "Coming soon" labels, buttons that navigate nowhere, gray image placeholders, and test/seed data visible on any screen.
3. Open the store listing side by side with the running app. Every feature mentioned in the description and shown in screenshots must be present and working in the submitted build. Rewrite or remove anything that is not.
4. Audit all third-party assets in the project (images, music, fonts, UI components). Confirm you hold a license or explicit permission for each one.
5. Identify all digital goods and subscriptions sold inside the app. Confirm each goes through StoreKit/In-App Purchase. Remove or redesign any flow that routes the user off-app to pay for digital content.
6. Add a data consent screen that appears before any user data is sent off-device. If data goes to an AI provider, name the provider explicitly on this screen.
7. In App Store Connect, create a demo account with full access to all paid and gated features. Enter the login and password in the App Review Information field. Verify the demo account works from a clean device with no captcha or SMS step.
8. Submit the build. In the review notes, add a short guide for any non-obvious flows so the reviewer does not have to guess.

## Ready-to-use prompt
```
Audit my iOS app against the App Store Review Guidelines before I submit it. Check for each of the following and give me the exact fix for every issue found:

1. Crashes and bugs: install on a clean device, walk all main screens, first launch, login, empty states, offline behavior. List any crash or freeze.
2. Placeholders: find "Coming soon" labels, lorem ipsum, dead buttons, blank tabs, test data visible on screen. List every instance and its file/line.
3. Metadata accuracy: compare the store description and screenshots to the current build. List any promised feature that is missing or broken.
4. Third-party content: list all logos, fonts, images, music, and UI components not created by me. Flag any without a confirmed license.
5. Payments: identify every purchase flow. Confirm digital goods go through In-App Purchase. Flag any digital payment that bypasses IAP.
6. Privacy and AI consent: check for a consent screen before any data leaves the device. If data goes to an AI service, confirm the provider is named explicitly.
7. Demo account: confirm a working login and password exist for the reviewer. Test sign-in from a clean device — no captcha, no SMS, no email confirmation required.

For each finding: location in the code, severity, and the minimum change to resolve it.
```

## Pitfalls
- Submitting a "near-final" build to move faster — Apple's reviewer will find the unfinished parts and the rejection costs more time than finishing would have.
- Padding screenshots with features not yet in the build — metadata deception is one of the fastest paths to rejection.
- Sending users off-app to pay for digital content, citing the post-lawsuit changes — the IAP exception is narrow, geographically limited, and can be revoked; do not build a business model around it.
- Forgetting the demo account — "reviewer could not log in" is the most common beginner rejection; always test the demo credentials from a clean device.
- Vague AI consent ("we share with third parties") — Apple now expects the provider's name on the consent screen; vague language triggers rejection.
- Assuming the Guidelines do not change — Apple revises them regularly; check the current App Store Review Guidelines on Apple's developer site before every release.