Quality assurance
Why Was My App Rejected? Common App Store & Play Store Rejection Reasons and How to Avoid Them
By Farheen Tahir · Code Huddle · Product engineering guides
A rejection email feels like a setback. It usually isn't. Most rejections come from a short list of fixable problems, and the reviewer tells you exactly which guideline you broke. The real danger is the second rejection, the one that happens because the first fix was only half done. At Code Huddle we have submitted many apps to the App Store and Google Play. This guide covers the rejections we see most often, what the stores actually said, and how we fixed each one.
Quick answer: why do apps get rejected?
Most apps are rejected for payment rule violations, missing privacy or account-deletion features, unclear or misleading store listings, and incomplete submissions. Apple and Google publish their rules, so almost every rejection can be prevented by checking your app and your store listing against them before you submit.
How does app review work?
Both stores review your app and your listing, not just the code.
- Apple App Review tests the build on real devices, reads your description and screenshots, and checks your links and in-app purchases. Rejections cite a specific guideline number, such as 3.1.1 or 5.1.1.
- Google Play review checks the build against Developer Program Policies and reviews your store listing, graphics and Data Safety form.
Review times vary, so don't plan a launch date with zero buffer.
What are the most common App Store rejections?
- 3.1.1 In-App Purchase — Digital content must be sold with Apple's In-App Purchase. Typical cause: subscription sold through Stripe or another payment method. Fix: implement In-App Purchase (StoreKit) and remove external purchase paths.
- 2.1(b) App Completeness — Everything referenced in the app must be reviewable. Typical cause: subscriptions mentioned, but IAP products not submitted. Fix: submit the IAP products with a review screenshot, then upload a new build.
- 2.3.2 Accurate Metadata — Paid features must be clearly labelled. Typical cause: description mentions subscriptions without saying a purchase is required. Fix: mark paid features as requiring purchase, or remove the references.
- 5.1.1 Privacy — Privacy policy must be accessible. Typical cause: policy URL only in App Store Connect, not inside the app. Fix: add the policy inside the app (Settings, Profile or signup) and keep the URL in App Store Connect.
- 5.1.1(v) Account Deletion — Apps with account creation must let users delete the account. Typical cause: no delete option at all. Fix: add in-app account deletion.
Real case studies from our projects
Case 1: Subscription sold outside In-App Purchase (Guideline 3.1.1)
What happened: Our client's subscription was sold on their website and landing page using Stripe. The mobile app also contained a URL leading to that page. Apple rejected the app twice for this. The second message opened with "the issues we previously identified still need your attention."
What Apple flagged:
- The subscription could be bought in the app with something other than In-App Purchase, and the app accessed content bought outside the app that was not available through IAP.
- The app contained a call-to-action or URL that directed users to an external purchase mechanism.
How we fixed it: We implemented In-App Purchase inside the app and removed the external URL from the mobile app.
The lesson: These are two separate fixes. Adding IAP does not remove an external link, and removing the link does not add IAP. Do both before you resubmit.
Note: Apple's rules on external purchase links differ by region and have changed in recent years. Always check the current guidelines (3.1.1 and 3.1.3) for the storefronts you target.
Case 2: Subscription mentioned, but IAP products not submitted (Guideline 2.1(b))
What happened: Apple could not finish the review because the app referred to subscriptions, but the In-App Purchase products had not been submitted for review.
How to fix it: Submit the IAP products in App Store Connect (an App Review screenshot is required) and upload a new binary.
The lesson: Creating IAP products in the code is not enough. They must also be configured and submitted in App Store Connect.
Case 3: Metadata mentioned subscriptions without saying they cost money (Guideline 2.3.2)
What happened: The app description referenced subscriptions but did not tell users that a purchase was required to access that content.
How to fix it: Clearly mark paid features as requiring a separate purchase, or remove the references from the description.
The lesson: Anything paid that appears in your description or screenshots must be labelled as paid.
Case 4: Privacy policy not inside the app (Guideline 5.1.1)
What happened: The app had a privacy policy URL in App Store Connect, but Apple wanted the policy available inside the app.
How we fixed it: We added a privacy policy link inside the app.
The lesson: Put the policy in both places: the Privacy Policy URL field in App Store Connect and somewhere users can easily find it in the app, such as Settings, Profile or the signup screen.
Case 5: No way to delete an account (Guideline 5.1.1(v))
What happened: The app let users create accounts but had no way to delete them. Apple rejected it.
How we fixed it: We added a feature that lets users delete their own account from inside the app.
The lesson: If users can create an account in your app, they must be able to start deletion from inside the app too. Plan this at the start of development. Building it in a rush after a rejection costs more.
What are the most common Play Store rejections?
Case 6: Misleading screenshots and mockups (Metadata policy)
What happened: The Play Store listing used mockups that contained stars and badge or certificate graphics, and the mockup text did not describe what the app does. Google treated this as implying the app was ranked number one.
How we fixed it: We removed the mockups with stars and badges and rewrote the mockup text so it describes the app's actual features.
The lesson: Don't put ratings, rankings, awards or badges ("#1", "best", stars, certificates) in your graphics unless they are real and allowed by policy. Screenshots should show what the app really does.
Note: Google's Metadata policy changes over time. Check the current policy text before finalising your listing.
How do you fix a rejection? (Step by step)
- Read the full message. It names the guideline and often the exact screen or text.
- Make a list of every issue. Messages often contain more than one.
- Fix each issue completely. Check the code, the store listing, the links and the metadata.
- Test on a real device. Walk through the same flow the reviewer used.
- Add reviewer notes. Include a demo login and explain anything that isn't obvious.
- Reply or appeal if you disagree. Use the Resolution Center (Apple) or Play Console (Google), politely and with evidence.
- Resubmit once everything is fixed, not after the first fix.
What are the most common mistakes after a rejection?
- Fixing one issue and resubmitting. This is how the same app gets rejected twice.
- Fixing the app but not the listing. Descriptions, screenshots, links and URLs are reviewed too.
- Assuming a payment fix is only code. IAP products must also be set up and submitted in the store console.
- Leaving external payment links in the mobile app after adding In-App Purchase.
- Treating privacy and account deletion as afterthoughts.
- Using promotional claims in graphics such as stars, badges and "#1".
- Skipping reviewer notes and demo credentials.
Pre-submission checklist
Apple App Store
- In-App Purchase implemented for all digital subscriptions and content
- IAP products created, configured and submitted in App Store Connect
- No external payment links, CTAs or registration links that lead to purchases (check regional rules)
- Description clearly labels paid features
- Privacy policy URL set in App Store Connect and a policy link inside the app
- In-app account deletion available if users can create accounts
- Demo account and reviewer notes provided
- Tested on a real device
Google Play
- Screenshots and mockups show the real app
- No ranking, award or rating claims in graphics or text
- Listing text accurately describes the app
- Data Safety form matches what the app actually collects
- Privacy policy link added
Final thought
Rejections are information, not punishment. Read the message, fix every issue, check the store listing as carefully as the code, and resubmit once. Teams that treat store rules as part of development, not a last-minute hurdle, get approved faster.