Most rejections are paperwork: the privacy policy, account deletion, permissions you do not need, and the test account you did not provide. All four are avoidable.
Key Takeaways
- Most rejections are paperwork: the privacy policy, account deletion, permissions you do not need, and the test account you did not provide.
- All four are avoidable.
The short answer
Most rejections are not about your code. They are about the privacy policy, the account deletion route, the permissions you ask for, or the test account you did not provide. All four are paperwork, and all four are avoidable before you submit.
Read the rejection carefully rather than resubmitting immediately. Reviewers cite a specific policy section, and that section tells you exactly what to change.
The four that catch Nepali teams most
1. The privacy policy
It must exist, at a public URL, reachable without logging in, and it must actually describe what your app collects. A one-paragraph page generated from a template that mentions data types your app does not touch is worse than useless, because the reviewer compares it against the permissions you declared.
If the app collects a phone number for OTP login, say so. If it uses an analytics SDK, say that too.
2. Account deletion
If users can create an account in the app, both stores now expect a way to delete it, and Google additionally expects a web URL where deletion can be requested without installing anything. "Email us and we will delete it" is not sufficient on its own.
This is the single most common recent cause of rejection for apps that previously passed review unchanged.
3. Permissions you do not need
Every permission must be justified by visible functionality. Location requested at launch, with no map and no location feature, gets rejected. Background location gets heavy scrutiny and needs a clear in-app disclosure before the system prompt.
Request permissions at the moment they are used, not on first launch, and remove any your library pulled in that you do not actually need.
4. No working test account
If the reviewer cannot get past your login, they reject. Provide working credentials, and if you use OTP login, either provide a bypass code for the review account or a demo mode. A reviewer in another country cannot receive an SMS to a Nepali number, and will not try twice.
The ones that take longer to fix
- Payments. Selling digital content or features generally requires the store's own billing. Physical goods and services do not. Getting this wrong means rebuilding the payment flow, not editing a form.
- Minimum functionality. An app that is a wrapper around your website will be rejected by Apple. It needs to do something a browser cannot.
- Misleading listing. Screenshots showing features that do not exist, or keyword stuffing in the title.
- Crashes on the reviewer's device. Test on a real device, not only an emulator, and on the oldest OS version you claim to support.
Before you submit
Install the release build on a clean device and use it as a new user with no data. Check the privacy policy URL loads in a private browser window. Confirm every declared permission maps to something the user can see. Write the review notes properly, including credentials and anything non-obvious about how to reach a feature.
Ten minutes of that removes most of the risk of a week's delay.
If the rejection is about payments or minimum functionality rather than paperwork, the fix is usually architectural. Our mobile app development page covers how we scope that, and Flutter or React Native for a Nepal-market app covers the stack decision underneath it.
Frequently asked questions
How long does review take?
Usually a day or two on both stores, longer for a first submission or anything in a sensitive category. Plan for a rejection and a resubmission in your launch schedule rather than assuming first-time approval.
Can I appeal a rejection?
Yes, and it is worth doing when the reviewer has misunderstood the app. Be specific and point at the functionality. Appealing a correct rejection just costs time.
Do I need a separate privacy policy page?
Yes, at a stable public URL, and the content must match what the app actually does. It is also the easiest item on this list to fix.
Why does Apple reject my app but Google accepts it?
Apple enforces minimum functionality and design guidelines more strictly. An app that is largely a website wrapper commonly passes one and fails the other.
What if my app uses OTP login?
Provide a test account the reviewer can actually use, with a fixed code or a demo mode. A reviewer abroad cannot receive your SMS, and this alone causes a surprising share of rejections.
Enjoyed this article? Share it with others!
Written by
Antbytelabs
Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.