If your app was rejected, do not panic: app store rejection reasons are mostly predictable and most are fixable. The most common are an incomplete or crashing app, misleading store information, privacy and data gaps, payment rule violations, and reviewers who could not log in. This article lists the usual causes, how to respond, and a pre-launch checklist. Rule numbers and wording can change, so this reflects November 2026; the official sources are Apple's App Review Guidelines and the Google Play Policy Center.
What to do first when your app is rejected
- Read the rejection message in App Store Connect (or Play Console) carefully. Which guideline is cited?
- If it is unclear, ask the review team through the Resolution Center. They do answer.
- Fix the issue, describe the fix in the review notes and resubmit.
- If you believe the decision is wrong, an appeal process exists, but fixing is usually faster.
The most common App Store rejection reasons
| Reason | What it means | Fix |
|---|---|---|
| Incomplete or buggy app (2.1) | Crashes, broken links, "coming soon" screens | Test end to end on real devices, use TestFlight |
| Cannot log in | Reviewers could not get in | Provide a working demo account and a note |
| Misleading metadata (2.3) | Screenshots or description do not match the app | Show the real interface and accurate claims |
| Minimum functionality, copies (4.2, 4.3) | Looks like a website wrapper or a clone | Add meaningful, device-specific value |
| Privacy (5.1) | No privacy policy, incomplete data disclosure, no account deletion | Policy link, accurate labels, in-app deletion |
| Payments (3.1) | Digital content sold outside store purchase | Use in-app purchase |
The numbers are for orientation; Apple can renumber or rewrite. The most critical points: the app must be genuinely complete, and your privacy declarations must match what the app actually does.
Apple-specific: sign-in and account rules
If you offer third-party login such as "Sign in with Google", Apple may expect Sign in with Apple or an equivalent privacy-preserving option. If users can create an account, you need an in-app way to delete it. These two are behind many "I did not know" rejections.
Typical Google Play release problems
- A Data safety form that is missing or does not match the app's real behaviour.
- No privacy policy, or one that cannot be reached.
- An outdated target API level.
- Misleading or copycat content, or trademark infringement such as someone else's name or logo.
- Violations of rules for apps aimed at children and ad policies.
- Trying to go to production before account verification and the testing requirement are complete.
The "Policy status" and "Publishing overview" sections of the Play Console show what is missing. For the release steps see publish an app on Google Play.
Real-world scenarios
Three cases hit small teams again and again. First: the app requires login but no demo account was provided, so reviewers could not get in and rejected it. Fix: put a working username and password in the notes field. Second: the privacy labels say "we collect no data" but an analytics and crash-reporting library is running, so the declaration and behaviour disagree. Fix: list the data every library collects and fill the labels from that. Third: the store page shows a feature that is not in the app, which triggers a misleading-metadata rejection. Fix: show only what exists.
Apps for children need extra care
If your audience is children, the rules tighten: third-party analytics and ad libraries are restricted, external links and purchases must sit behind a parental gate, and personal data collection is strictly limited. When we design our own children's game, Kaşif Ormanı (in preparation), we put the parental gate, the daily time limit and minimal data collection into the architecture from the start, because adding them later is more expensive and riskier. Clarify questions for children's apps with a lawyer, since laws differ by country. Parents can read how to judge such apps in choosing safe apps for kids.
Pre-launch checklist
- Test on real iPhone and Android devices with different screen sizes.
- No empty or half-finished screens, dead buttons or "coming soon" text.
- Do the privacy policy, terms and support links work?
- Do the privacy labels and Data safety form match exactly what the app collects? (See app privacy and GDPR basics.)
- Is the demo account and review note ready?
- Is the payment flow compliant, and does restore purchases work?
- Do screenshots and description reflect reality?
- Can account deletion (if accounts exist) be done inside the app?
Habits that prevent rejection during development
Most rejection reasons are born in small decisions during development, not in the last week. Trying weekly builds on real devices and through test channels such as TestFlight catches bugs early. Update the data table for the privacy labels whenever a new library joins the app. Draw the payment flow against store rules at design time. Do not leave store text and screenshots to the final day. Before launch, hand the app to someone who has never seen it and watch them go from first launch to purchase without guidance: every place they get stuck is a place a reviewer could get stuck.
Frequently asked questions
How many times can I resubmit a rejected app?
There is no fixed limit, but resubmitting the same problem wastes time. Resolve the message first, then submit.
How long does review take?
It varies, and a first submission with follow-up questions may take longer. Build a few weeks of slack into your plan.
Does a rejection harm my account?
An occasional rejection is normal. Repeated, serious policy violations can have account-level consequences, so read the rules early.
How do I contact the Apple review team?
Through the Resolution Center and the review notes field in App Store Connect. A call can sometimes be requested.
The cheapest fix for rejection is to design with the rules in mind. At OdenaVerse we apply what we learned releasing our own app to client projects, publish under your own account and keep each step in writing. See App Store fees for developers for the account side, and the blog for more.