The app is ready, the launch date is announced, and then App Store review sends back a rejection. Every resubmission means another wait, a delayed release and a marketing campaign that has to be moved. The good news is that most rejections are predictable: the stores turn apps down for the same reasons again and again, and you can deal with them before you submit.
In short
- Most rejections have familiar causes: crashes, unfinished content, a missing privacy policy, unclear permissions or a login with no demo account.
- Preparing for review starts early: developer accounts, the store listing, data disclosures, notes for the reviewer and beta testing.
- Apple and Google change their rules often, so check the current version before every submission.
How app review works
Before an app appears in a store, it is checked against the platform's rules. Apple reviews every new version against its App Review Guidelines, and real people take part in the process. Google combines automated and manual checks against its Developer Program Policies.
Review times vary. They depend on the platform, the type of app and whether this is your first submission. So always leave a buffer in your launch plan, and don't tie a marketing date to the day you submit.
A rejection isn't final. It usually comes with an explanation and a reference to the rule that was broken, so you can fix the issue and submit again. But every round costs time, which is why passing the first time is always the cheaper option.
Why apps get rejected
The reasons repeat from project to project. These are the typical ones.
- Crashes and bugs. The app crashes on launch, freezes in a key flow or has buttons that do nothing.
- Unfinished content. Placeholder text, empty screens, "coming soon" sections and test data make the product look half-built.
- No privacy policy. Both stores require a link to one, and the policy itself must honestly describe what data you collect.
- Permissions without a reason. A request for the camera, location or contacts needs a clear purpose that the user understands at the moment of asking.
- Payments for digital goods. Digital content and subscriptions usually have to be sold through the platform's own in-app purchases, with exceptions that depend on the country and the type of app.
- A login wall with no demo access. If the main features sit behind sign-up and the reviewer has no login, there is nothing for them to review.
- Misleading store text. Screenshots and the description show features the app doesn't actually have.
What to prepare before you submit
Preparing for review starts well before the final build. These are the four things to have ready.
- Developer accounts. The Apple Developer Program and Google Play Console both require registration, payment and verification of the person or company. An organisation account needs, for example, a D-U-N-S number, so start early.
- The store listing. The name, description, screenshots, icon, age rating and support contacts must match the real app.
- Data disclosures. In App Store Connect this is the App Privacy section; in Google Play Console it is the Data safety section. Both must match your privacy policy and how the app really behaves, including third-party SDKs for analytics or advertising.
- Reviewer access. Create a demo account with realistic data and write short notes explaining how to test the key features. Both platforms have dedicated fields for this.
Testing and beta builds
The reviewer sees the app the way a user will, so test on real devices, not just in the simulator. Check different screen sizes, older versions of the operating system, a slow connection and what happens when a user refuses a permission.
Beta testing catches what the team has missed. On iOS this is TestFlight: you invite testers, and they install the build before it is published. Apple also reviews builds for external testers, so this doubles as an early rehearsal for app review. Google Play has testing tracks (internal, closed and open) that deliver the build only to the people you choose.
New personal developer accounts on Google Play have an extra requirement: before you can publish to everyone (production), you must run a closed test with a set number of testers for a set period. Check the current conditions in Play Console and build this stage into your schedule.
Checklist
- Register your Apple and Google developer accounts while the app is still in development.
- Remove placeholders, test data and unfinished sections from the final build.
- Publish a privacy policy and complete App Privacy and Data safety to match how the app really works.
- Explain every permission request in plain words at the moment it is needed.
- Create a demo account and tell the reviewer how to test the key features.
- Test the build on real devices, in TestFlight and in Google Play testing tracks.
- Check that the screenshots and description show only what the app can really do.
How we do it at IANKO
We think about app review at the "make it work" stage, not a week before launch. Our Business Analyst records which data and permissions the app needs and why, so the privacy policy and data disclosures match reality. Our QA engineers and software testers check every build on real devices and through beta testing. Then, at the "bring it to people" stage, we prepare the store listing, demo access and reviewer notes, so publishing to the App Store and Google Play is a planned step rather than a gamble.
The bottom line
A rejection from the App Store or Google Play is rarely random: it has a known cause, and most of those causes can be dealt with before you submit. Treat launch preparation as part of development rather than a formality at the end, and leave time in your plan for review.