Apple App Store Review Guidelines: What Every Developer Must Know

Apple App Store Review Guidelines: What Every Developer Must Know

Getting your app rejected by Apple after weeks of development is one of the most frustrating experiences in mobile development. Apple's App Store Review Guidelines are extensive, frequently updated, and enforced with varying strictness. Understanding them before you build — not after — saves enormous time and prevents last-minute pivots. This guide covers the guidelines that trip developers up most often.

How the Review Process Works

When you submit a build, Apple assigns it to a human reviewer (with automated pre-checks first). Review times average 24–48 hours for initial submissions, though expedited reviews are available for genuine bugs or legal issues. Rejections come with a specific guideline number and a brief explanation. You can respond to the reviewer through App Store Connect's Resolution Center.

Guideline 2: Performance

2.1 — App Completeness: Apple rejects apps with placeholder content, demo screens, or lorem ipsum text. Your app must be production-ready with all features functioning before submission.

2.3 — Accurate Metadata: Your screenshots, description, and preview video must accurately reflect the current version of your app. Screenshots showing a different UI from what ships, or describing features that do not exist, will get the app rejected.

2.4 — Hardware Compatibility: Your app must support the minimum OS version you declare in your Info.plist and must not crash on any supported device.

Guideline 3: Business

3.1.1 — In-App Purchase: Digital goods and services sold inside an iOS app must use Apple's In-App Purchase system. This is non-negotiable and one of the most commonly enforced rules. You cannot direct users to a website to purchase something they will then unlock in the app.

3.1.3 — Reader Apps: Apps whose primary purpose is delivering previously purchased digital content (Kindle, Netflix, Spotify) may link to their external website for account creation but cannot promote pricing or link directly to purchase flows.

3.2.2 — Unacceptable Business Models: Apps that function solely as marketing materials, run lotteries, or charge for features freely available elsewhere without added value are rejected.

Guideline 4: Design

4.0 — Design: Apple expects apps to use standard UI controls correctly, follow platform conventions, and provide a polished experience. Custom UI is fine, but it must feel intentional and consistent.

4.2 — Minimum Functionality: Apps must provide meaningful functionality. A simple web wrapper with no offline capability or platform-specific features is a common rejection reason. If your app is essentially a website, the reviewer will ask what value the native app provides.

4.8 — Sign In with Apple: If your app allows third-party social login (Google, Facebook, Twitter), you must also offer Sign In with Apple. This is strictly enforced.

Guideline 5: Legal

5.1.1 — Data Collection and Storage: You must have a privacy policy linked in your App Store listing and must describe all data you collect in your App Privacy section (the privacy nutrition label). Inaccurate privacy labels are a growing rejection reason.

5.1.2 — Data Use and Sharing: You cannot use data collected for one purpose to serve an unrelated purpose without explicit user consent. Analytics data cannot be shared with ad networks without disclosure.

5.3 — Gaming, Gambling, and Lotteries: Apps with real-money gambling require specific Apple entitlements and must be geographically restricted to jurisdictions where the activity is legal.

Common Pitfalls and How to Avoid Them

Hidden features: Reviewers test the exact binary you submit. Attempting to hide features behind server-side flags that are enabled after approval is a violation and can result in removal from the store and loss of developer account.

Incomplete account deletion: As of June 2023, apps that allow account creation must provide in-app account deletion. The flow must fully delete the account and associated data, not just deactivate it.

Missing entitlements: Features like push notifications, iCloud, Sign In with Apple, and HealthKit require specific entitlements in your provisioning profile. Missing entitlements cause binary rejection before human review.

Third-party SDKs: You are responsible for the behavior of every SDK you include. If an analytics SDK collects data beyond what you declared in your privacy label, your app is in violation even if you did not write the SDK code. Audit your SDKs' data collection practices.

Responding to Rejections

When rejected, read the guideline number and explanation carefully. Common responses:

1. If the reviewer misunderstood the app's functionality, reply in the Resolution Center with a clear explanation and offer a TestFlight build with demo credentials
2. If the rejection is valid, fix the issue, increment the build number, and resubmit
3. If you disagree with the interpretation, you can appeal to the App Review Board

Conclusion

Apple's guidelines exist to protect users and maintain the perceived quality of the App Store. Treating them as constraints to work around is the wrong mindset — most of them reflect legitimate user experience and privacy concerns. Read the full guidelines at least once, subscribe to Apple's developer news to catch updates, and test your submission against the guidelines checklist before submitting. A clean first submission is always faster than iterating through rejections.