Apps are often rejected not because of code quality, but because of documentation and configuration issues: incomplete builds, missing test accounts, no account deletion option, and undeclared privacy information. All of these are covered in the official guidelines and can be checked in advance. Below are the most common blockers in both stores and how to resolve them before release.
A Non-Functional Build — The #1 Reason
Apple's App Review Guidelines document labels section 2.1 as "App Completeness": the submitted build must be a final, working version. Placeholder text, "coming soon" screens, non-functional buttons, and demo-mode content — any one of these is enough to trigger a rejection.
In practice, the most common issue is that the reviewer cannot access the app at all. If registration is required, you must provide a working test account (login and password) in the App Review Information section. If login is done via an SMS code, you need to explain in the notes how the reviewer can receive the code; otherwise, they won't be able to log in, and the submission will be returned with "cannot log in".
In server-dependent apps, there is another pitfall — reviewers often connect from a U.S. IP address. If the backend responds only to Uzbekistan IP addresses or geo-filtering is enabled, the app will show a blank screen for them. Test this with a VPN before release.
Account Deletion Button
If an app allows users to create an account, it must also provide a way to delete that account within the app. This is stated in Apple’s 5.1.1(v) section, while Google Play has a separate “Data deletion” policy, and the Play Console requires a link for deletion requests.
Important point: the text “contact support” is not sufficient. Deletion must begin from the app interface itself. Google Play also requires a web link on the website — meaning that a user who has uninstalled the app can still delete their data.
In practice, making this two-step is convenient: a button in the interface → a confirmation screen → deletion or anonymization in the backend. If some records must be retained for accounting or legal reasons, the privacy policy must clearly state what is retained and why.
Privacy: Two Forms in Two Stores
Both stores require the app to declare how it collects data, but the forms are different:
| Requirement | App Store | Google Play |
|---|---|---|
| Declaration | App Privacy ("Nutrition Label") | Data safety form |
| Where completed | App Store Connect | Play Console |
| Privacy policy URL | Required | Required |
| Account deletion | In-app (5.1.1(v)) | In-app + web link |
| Tracking permission | App Tracking Transparency | Ad ID declaration |
The most common mistake is a mismatch between the answers in the form and what the code actually does. SDKs (analytics, advertising, crash reporting, push) collect data on their own and must be included in the declaration. An app marked as “We don’t collect anything” while Firebase Analytics is running inside it is rejected for non-compliance.
Unjustified permission requests
Camera, location, contacts, microphone, and background location — each one needs an answer to the "why is it needed" question. On iOS, this answer is text such as NSCameraUsageDescription inside Info.plist, and it is visible to the user:
<key>NSPhotoLibraryUsageDescription</key>
<string>E'longa rasm biriktirish uchun galereyaga kirish so'raladi.</string>
Generic text like "App needs access" can cause rejection — the text should explain the exact scenario in that app.
On Android, there are separately monitored permissions: MANAGE_EXTERNAL_STORAGE, access to SMS and call logs, and background location. For these, a separate declaration is completed in Play Console, and a video demonstration is often requested. If a permission remains in the code but is unused, removing it from the manifest simplifies review.
If Your App Has User Content, a Moderation Suite Is Required
A post, comment, chat, or profile photo — any content uploaded by a user moves the app into a different category. Apple's 1.2 guideline requires four things from such apps: filtering inappropriate content, a mechanism for users to submit reports, the ability to block rule-breakers, and a way to contact the developer.
This requirement often stops marketplace and social apps on the first attempt, because many teams postpone the "report" button. In the experience of building the Bisyor.uz marketplace, the moderation process was an integral part of the product — the store's requirements point in the same direction.
The second layer is content rating. If the questionnaire is filled out incorrectly (for example, the app has a chat but is marked as having "no user interaction"), it may be reviewed again even after launch.
Metadata, Screenshots, and Name
A significant portion of rejection responses has nothing to do with the code. If the store listing description promises a feature that is not available in the app, if screenshots show an outdated interface, or if the name uses a third-party brand name, it is rejected as unclear metadata.
The second common case is the "spam" category. Apps built from the same template, differing only in name and color (for example, a separate copy for each client) are rejected by Apple under Guideline 4.3. In such cases, the correct solution is to support multiple organizations within a single app.
The third is a website wrapped in an app. An app consisting only of a WebView and not using device capabilities is rejected for "minimal functionality."
What to Do After a Rejection
A rejection is not a penalty — it’s a message. The process is as follows:
- Find the guideline number in the message (for example, 2.1 or 5.1.1) and read that section in the official documentation — the short text in the message often does not show the full reason.
- Review the screenshot or screen recording attached by the reviewer: it identifies which screen the issue occurred on.
- If the reason is unclear, send a clarifying question through the Resolution Center — before submitting a new build.
- If the issue is in the metadata or declaration, you do not need to re-upload the build — the text or form is corrected and resubmitted for review.
- If a code change is required, increment the build number and re-upload it, and specify exactly what was changed in the notes.
Do not overlook point four: many teams unnecessarily spend several days rebuilding the full build even for a metadata error.
Frequently Asked Questions
How long does the review take?
No exact timeframe is guaranteed, and it varies depending on the release period. In practice, App Store reviews usually take from a few hours to a few days, while first releases on Google Play for new developer accounts can take significantly longer. It is advisable to plan the release date taking this uncertainty into account.
Does a rejection affect future submissions?
A single rejection does not automatically have a negative impact on the account — it is a normal part of the process. The issue is repetition: if the same policy violation is submitted repeatedly or an attempt to bypass moderation is detected, action may be taken at the developer account level.
Can I release the app on my own?
Yes, if the developer account, certificates, and store assets are ready. The difficulty is not technical, but more organizational: privacy policy, account deletion flow, declaration forms, and moderation tools need to be incorporated into the product plan in advance. Doing them right before release is the most time-consuming path.
Do I need to submit to both stores at the same time?
Many teams first release to Google Play's internal testing track, then submit to App Store — this way obvious bugs are found at a lower-cost stage. However, there is no harm in submitting to both stores at the same time: the reasons are often different, and fixing them in parallel shortens the overall timeline.
Most rejection responses are related to documentation and configuration, not code — that is, they can be resolved with a one-hour review before release. If you need help with a mobile product or web project, considering platform requirements at the planning stage is the most cost-effective solution. This approach has also proven effective in long-lived products such as Zamin.uz.