Rejection is normal — most apps are rejected at least once. It is only expensive when it is a surprise, because it usually arrives the week you planned to launch. Almost every common reason is predictable and preventable at design time.
The rejections we see most
1. Incomplete information for the reviewer
If your app requires login, the reviewer needs working demo credentials. No account means no review, and it is the most common avoidable rejection of all.
Fix: supply a permanent demo account in App Store Connect notes, with any OTP bypass explained. Verify it works the day you submit.
2. Crashes or obvious bugs
Reviewers test on current devices and current OS versions. A crash on launch is an immediate rejection.
Fix: test on the newest OS release, on a real device, from a clean install — not just from your development build.
3. "Not enough value" — the web wrapper problem
Apple explicitly rejects apps that are simply a website in a shell with no app-like functionality. This one catches a lot of Indian small businesses whose developer offered a cheap "app version of your site".
Assumption: "We can wrap our website and publish it as an app cheaply."
Reality: Apple rejects this under guideline 4.2 unless the app adds genuine native value — push notifications, offline access, camera, or device features. Budget for real functionality or reconsider whether you need an app.
4. Payment rules broken
Digital goods and services consumed inside the app must use Apple's in-app purchase, which carries a commission. Using your own gateway for digital content is a firm rejection.
The distinction that matters: physical goods and real-world services (food delivery, cab booking, physical products) use normal payment gateways. Digital content, subscriptions, and unlockable features must use IAP.
5. Privacy policy and permission problems
- A working, reachable privacy policy URL is mandatory.
- Every permission needs a clear, specific usage description — "needs camera" is not enough.
- Your Data Safety (Play) and Privacy Nutrition Label (Apple) declarations must match what the app truly collects.
- Do not request permissions you do not currently use.
6. Sign in with Apple missing
If you offer Google, Facebook, or other third-party login on iOS, you must also offer Sign in with Apple. This is frequently missed and easily fixed.
7. Broken or placeholder content
Lorem ipsum text, dead links, empty states, and "coming soon" screens all trigger rejection. Ship complete or hide the feature.
8. Misleading metadata
Screenshots must show the actual app. Keyword-stuffed descriptions and competitor names in your title are rejected.
9. Account deletion missing
If users can create an account in your app, they must be able to delete it from within the app. Both stores enforce this now, and it is a common surprise for older apps submitting an update.
The five-minute pre-submission check that prevents most rejections: working demo login, reachable privacy policy URL, in-app account deletion, permission strings that explain themselves, and Sign in with Apple if you offer other social logins.
Google Play differences
| Area | Apple App Store | Google Play |
|---|---|---|
| Review time | 24–48 hours typically | Hours to several days |
| Review style | Manual, strict | More automated |
| Web wrappers | Frequently rejected | More tolerant |
| Target SDK | Encouraged | Strictly enforced annually |
| Policy strikes | Per-app rejection | Can suspend the whole account |
Google's enforcement carries higher stakes. Repeated policy violations can suspend your entire developer account, not just one app — and appeals are slower and less personal than Apple's. Treat Play policy warnings as urgent.
If you are rejected
- Read the actual guideline number The rejection cites a specific rule. Read that rule rather than guessing from the summary.
- Ask for clarification if it is genuinely unclear The Resolution Center is a real conversation with a reviewer, not a form.
- Fix precisely what was cited Do not bundle unrelated changes into the resubmission — it invites new findings.
- Explain the fix in your reply A clear note about what changed speeds up re-review noticeably.
- Appeal only when confident If the guideline was misapplied, appeal — but fixing is usually faster.
Plan for one rejection in your launch schedule. Teams that budget a week for review issues launch calmly; teams that assume first-time approval launch late and stressed.
Building an app and want store compliance handled properly? We manage submission end to end — get in touch. See our iOS development service or the app cost guide.