Why app stores reject apps, and the checks that avoid it
Published by PWTECH
A rejection from App Review or Google Play is rarely about code quality. It is almost always a rule that was published, was easy to meet, and was not checked before the build went in. Each round trip costs days, and a launch date set without allowing for one is a guess.
This note lists the reasons we see most, in the order they tend to bite, and the checklist we run before the first submission so that the review is a formality.
Why apps come back
No way to delete the account
If an app lets a person create an account, it must let them delete it from inside the app, not by emailing support. Reviewers test this early.
Permission prompts without a reason
Asking for the camera or location with the default system text, or asking at launch before the feature is used, is a common return. The prompt has to say why, in the language of the app.
A reviewer who cannot sign in
The reviewer needs a working demo account with data in it. An app that opens on an empty screen or requires a real phone number to proceed will be returned.
Privacy labels that disagree with the app
The data-safety form and the privacy labels are compared with what the app actually sends. An analytics library that was added late and never declared is enough.
Digital goods sold outside the store
Subscriptions and digital content inside an app must use the store billing system where the rules say so. Physical goods and services are different, and the distinction matters.
Placeholder content and dead links
Lorem ipsum, an empty screen, a support link that opens a 404. Reviewers open everything.
The checks we run
Walk every screen on a real device
Not the simulator. Each tab, each setting, each empty state, with the test account the reviewer will use.
Compare the declarations with the network traffic
We record what the app sends during a session and check it against the privacy labels and the data-safety form, library by library.
Prepare the listing as a document
Screenshots at the required sizes, the description, the support address, the privacy policy page and the demo credentials, kept together so the submission is not assembled in a hurry.
Plan the date around review time
Review takes as long as it takes. We submit well before the date that matters and treat the first submission as a rehearsal.
Asked about store review
Can you speed up a review?
No. Expedited review exists for genuine emergencies and is granted at the store's discretion. The reliable way to be fast is to be rejected zero times.
Whose developer account should the app be published under?
Yours. The accounts are opened in your company name and we are invited as team members, so the app and its reviews stay with you if we ever stop working together.
What about updates after launch?
Each update is reviewed again, more quickly as a rule. New operating-system versions bring new requirements, so we test on the beta releases before they reach the public.
Tell us where your app is
In design, in development or already rejected once: a few lines on where it stands and what it does is enough. We reply within one business day.