Why Apple Rejects Apps (And How to Avoid Every Common Reason)

1. Incomplete or Broken Functionality

The #1 rejection reason. Apple's reviewer creates an account, tries to use the app, and hits a crash, an error, or a feature that doesn't work. Common causes: using placeholder content, having features that require a server that's not set up, or submitting a build in a partially-finished state. Fix: create a demo account for the reviewer with all features accessible. Test every flow on a physical device. Submit only when the app is production-ready.

• Provide demo account credentials in App Review notes
• Test on physical device — Simulator misses real device bugs
• Check all error states — reviewers deliberately enter wrong data
• Don't submit with placeholder content or 'coming soon' screens

2. Missing Privacy Policy

Required for any app that collects user data (which is almost every app). The Privacy Policy must be accessible from within the app AND linked in your App Store metadata. It must specifically mention what data you collect, why, and how it's used. A generic template doesn't cut it — it must be specific to your app's actual data practices.

3. In-App Purchase Issues (Guideline 3.1.1)

If your app sells digital goods or services, they must go through Apple's IAP system. You cannot direct users to a website to purchase something they'll use in the app. You cannot mention lower prices on other platforms. You cannot have a 'Purchase on our website' button. These are hard rules. Use RevenueCat to implement StoreKit correctly — it handles all the edge cases that trip up custom implementations.

4. Poor User Interface (Guideline 4.0)

Apple rejects apps that don't follow iOS Human Interface Guidelines. Common UI rejections: non-standard navigation patterns, small tap targets (<44×44pt), placeholder text left in production, no loading states, and apps that look unfinished. Use standard UIKit or SwiftUI components where possible, especially for navigation and tab bars. If you're using React Native, test that native behaviors (back gestures, pull-to-refresh, keyboard handling) work correctly.

5. Sign In With Apple (Guideline 4.8)

If your app offers any third-party login (Google, Facebook, Twitter), you must also offer Sign In With Apple. This is a hard requirement with no exceptions. Implement it before you submit — it's a guarantee rejection without it. In React Native, use `@invertase/react-native-apple-authentication`. In Expo, use `expo-apple-authentication`.

6. Permissions Without Clear Purpose

Every permission request (camera, location, contacts, microphone) must have a clear usage description string explaining exactly why you need it in plain English. Vague descriptions like 'for a better experience' get rejected. Be specific: 'Your location is used to show service providers near you.' Request permissions at the moment they're needed, not all at once at app launch.

How to Appeal a Rejection

If you disagree with a rejection, you can appeal via the Resolution Center. Rejections based on factual errors (reviewer missed a feature, didn't see your demo credentials) are usually resolved in 1–2 days. Rejections based on guideline interpretations require a more detailed response. Frame your appeal as: 'The reviewer noted X. Here is why our app complies with Guideline Y: [specific explanation].' Don't be defensive — be helpful. In persistent cases, the App Review Board can be escalated to, though this takes 1–2 weeks.