Why apps get rejected by the App Store (and how to fix them)
Most App Store rejections come from a handful of predictable issues. Learn what Apple reviewers look for and how to fix each problem before you hit submit.
An App Store rejection is frustrating, especially when a launch date is already announced. The good news is that most rejections are predictable. Apple's reviewers work from the published App Review Guidelines, and the same handful of issues account for the majority of rejections. Fix them before you submit and your first review is far more likely to pass.
This guide covers the most common themes, what triggers them and how to fix each one. Apple revises its guidelines regularly, so always check the current version on Apple's developer site before submission.
Common rejection reasons at a glance
| Rejection theme | Typical trigger | Fix |
|---|---|---|
| Crashes and bugs | App crashes on launch or during a core flow on the reviewer's device | Test release builds on current iOS and multiple devices via TestFlight |
| Incomplete information | No demo account, broken login, backend not live | Provide working credentials and review notes; keep servers running |
| Privacy | Inaccurate privacy labels, tracking without permission, missing policy | Audit SDKs, update labels, add ATT prompt where required |
| In-app purchase | Selling digital goods through an external payment flow | Use Apple's in-app purchase for digital content unless an exception applies |
| Minimum functionality | Website wrapped in a webview, or too little value | Add genuine native features and app-specific value |
| Account deletion | Users can sign up but not delete their account in the app | Add an in-app account deletion flow |
| Misleading metadata | Screenshots or description do not match the app | Use real screenshots and accurate descriptions |
| Login options | Third-party social login offered without an equivalent privacy-focused option | Offer Sign in with Apple or another compliant option |
1. Crashes, bugs and broken features
App completeness is consistently one of the most cited rejection areas. If the app crashes, shows placeholder content, has dead buttons or displays "lorem ipsum", it will be rejected.
- Test the exact release build through TestFlight, not a debug build from Xcode.
- Test on the latest iOS version and at least one older supported version, on both a small and a large iPhone, and on iPad if your app runs there.
- Test with poor network conditions. Reviewers do not always have perfect connectivity, and apps that hang indefinitely on a spinner fail.
- Remove any "coming soon" sections or hide them until they work.
2. Incomplete information and missing demo access
If your app needs a login, the reviewer needs a working account. Rejections for missing or expired demo credentials are extremely common and completely avoidable.
- Create a dedicated review account with realistic sample data, and enter the credentials in App Store Connect's review information.
- If login uses an OTP sent to a phone, provide a demo mode or a fixed test number and code for the reviewer, and explain it in the notes.
- If features depend on hardware, location or a specific region, explain how to test them, and provide a short demo video if helpful.
- Keep your backend running and stable during review. A staging server that sleeps at night will cause a rejection.
3. Privacy labels, tracking and App Tracking Transparency
Privacy is a strong focus of App Review. Three things matter most.
Accurate privacy nutrition labels
The App Privacy section in App Store Connect must describe all data your app and its third-party SDKs collect. Analytics, crash reporting, advertising and login SDKs all count. Apple also requires privacy manifests for many commonly used SDKs and for certain APIs that could be used for fingerprinting, so keep SDKs current.
App Tracking Transparency
If your app tracks users across other companies' apps or websites, such as for targeted advertising or sharing data with data brokers, you must ask permission with the ATT prompt before tracking. You cannot gate app features on the user accepting, and you cannot use workarounds like fingerprinting.
Permission prompts and privacy policy
Every permission request (camera, location, contacts, photos) needs a clear purpose string explaining why the app needs it. Ask only when the feature is used, not all at once on launch. A privacy policy link is required both in App Store Connect and inside the app.
4. In-app purchase rules
If you sell digital content or features that are consumed inside the app, such as subscriptions, premium features, coins or digital courses, Apple generally requires you to use its in-app purchase system. Directing users to pay on your website instead has historically been a common cause of rejection.
There are important nuances. Physical goods and real-world services, such as e-commerce orders, food delivery, taxi rides or salon bookings, should use your normal payment gateway, not in-app purchase. Rules for external purchase links have also changed in some regions due to regulation and legal rulings, and they differ by storefront. Because this area moves quickly, check the current guidelines for the storefronts you target before designing your payment flow.
Key tip: decide your iOS payment model during planning, not after development. Retrofitting in-app purchase, receipt validation and subscription handling into a finished app is one of the most expensive late surprises in iOS projects.
5. Minimum functionality and webview wrappers
Apple expects an app to offer more than a repackaged website. An app that simply loads your mobile site in a webview is likely to be rejected for minimum functionality. The same applies to apps with very little content or apps that duplicate many near-identical apps from the same developer.
To pass, give the app genuine value that uses the platform: native navigation, offline support, push notifications with useful content, device features such as camera or location where relevant, and a polished native feel. If a website is all you need, a strong responsive site or a PWA might be the better investment; we compare the options in website vs PWA vs native app.
6. Account deletion
If your app supports account creation, it must also let users initiate deletion of their account from within the app. Simply deactivating the account, or telling users to email support, is not enough. A clear path such as Settings, then Account, then Delete Account works well. If you operate in a regulated industry and need extra verification steps, explain the process to users clearly.
7. Misleading metadata
Your app name, subtitle, description, keywords and screenshots must accurately represent the app. Common problems include screenshots showing features that do not exist, references to other platforms such as "also on Android", competitor names in keywords, and pricing claims that do not match in-app purchases. Keep metadata honest and specific, and make sure the app category is correct.
8. Sign in with Apple and login options
If your app uses a third-party or social login such as Google or Facebook for the user's primary account, Apple's guidelines require you to also offer an equivalent login option that meets its privacy criteria, and Sign in with Apple is the simplest way to comply. There are exceptions, for example apps that use only your company's own account system, or enterprise and education apps using existing organisational logins. If you add Sign in with Apple, handle the private relay email addresses correctly in your backend.
What to do if you are rejected
- Read the message carefully. It cites a guideline number. Look up that exact guideline.
- Reply in Resolution Center if you believe the reviewer misunderstood something. A polite, specific explanation, sometimes with a screen recording, resolves many cases.
- Fix and resubmit when the issue is valid, and explain what you changed in the review notes.
- Appeal through the App Review Board only if you genuinely believe the decision is wrong after discussion.
A pre-submission checklist
- Release build tested on TestFlight across devices and iOS versions
- Demo account and review notes added; backend stable
- Privacy labels, privacy manifests and privacy policy up to date
- ATT prompt present if you track; permission purpose strings clear
- Correct payment model for digital versus physical goods
- In-app account deletion working
- Sign in with Apple offered where required
- Screenshots and description accurate
Launching on Android too? Our Google Play publishing checklist covers the equivalent steps there.
Get your iOS app approved with less stress
Lead Infosoft's iOS development team builds with App Review in mind from the first sprint, and our QA process runs a pre-submission audit against the points above. If your app has been rejected, or you want a review before submitting, reach out to us and we will help you get it through.
Frequently asked questions
What is the most common reason for App Store rejection?
App completeness issues are among the most common: crashes, bugs, placeholder content and missing demo login details. Testing the release build and giving reviewers working credentials prevents most of them.
Do I need Sign in with Apple in my app?
If you use third-party social login such as Google or Facebook for the primary account, Apple generally requires an equivalent privacy-focused option, and Sign in with Apple is the simplest way to comply. Some exceptions apply.
Can I use Razorpay or another gateway in an iOS app?
Yes, for physical goods and real-world services such as e-commerce or bookings. For digital content and features used inside the app, Apple generally requires in-app purchase, though rules vary by region.
How long does App Store review take?
Many submissions are reviewed within a day or two, but it can take longer, especially for first submissions or if clarification is needed. Build a buffer into your launch plan.
