App Store and Google Play Rejections: Common Causes and Fixes

An app store rejection is rarely about the idea behind the app. Reviewers reject builds for a small set of repeatable reasons: the app crashed or could not be tested, the privacy answers do not match what the code does, a permission is requested without a clear reason, a payment goes around the store's rules, or the listing misdescribes the product. Each has a specific fix.

The sections below follow the order in which we check a rejected build. Guideline numbers refer to Apple's App Review Guidelines. Google Play organizes the same ground into named policies. Both sets of rules change, so read the current text before acting on anything here.

Read the app store rejection message before changing anything

Apple's message in App Store Connect names the guideline, for example 2.1 or 5.1.1, and often includes a screenshot or the steps the reviewer took. Google Play sends an email and shows the issue in Play Console with the policy name and, usually, the affected version.

Find the exact clause and reproduce what the reviewer saw on a clean install of the same build. If the message is unclear, reply and ask. Resubmitting the same build unchanged wastes days, and guessing at the cause tends to earn a second rejection.

Crashes, dead ends and missing review access

Apple's guideline 2.1 covers app completeness: crashes, obvious bugs, placeholder text, broken links and features that do not work during review. Google Play has matching rules against apps that crash, freeze or do not function as described.

The frequent causes are mundane:

• The reviewer could not log in. Supply a working demo account in the review notes, with any second-factor step disabled or explained. Play Console has an "App access" section for the same purpose.
• The backend was not live. The production API, or a review environment the build points to, must be running and populated with sample data.
• A feature needs hardware, a location or an invitation the reviewer does not have. Provide a demo mode or a short video and say so in the notes.
• The release build behaves differently from the debug build that was tested.

Test the exact build you upload, installed fresh on a real device, signed in as a brand-new user. On Android, read the pre-launch report in Play Console, which runs the app on a range of devices and lists crashes.

Privacy declarations that do not match the app

Both stores publish a privacy summary on the listing, and both hold you responsible for its accuracy, including what third-party code collects.

Apple

App Store Connect asks for app privacy details covering your own data practices and those of third-party partners whose code is in the app: analytics, advertising and other SDKs. Guideline 5.1.1 requires a privacy policy link in App Store Connect and inside the app. Apple also requires declared reasons for the use of certain system APIs, by your code and by SDKs, in the app's privacy manifest. If the app tracks users across other companies' apps and websites, it has to ask through the App Tracking Transparency prompt first.

Google Play

Every published app, including those on closed and open testing tracks, must complete the Data safety form. It covers data handled by libraries and SDKs, it requires a privacy policy, and Google states that it may take enforcement action when the declaration and the app's behavior differ.

The fix for both

Keep an inventory of every SDK in the app and what each collects, and update the declarations whenever the inventory changes. Adding an analytics or ads package without revisiting the forms is how apps that passed review for years get flagged.

Account deletion belongs here too. If people can create an account in the app, Apple requires a way to delete it inside the app. Google requires an in-app path and a web link where deletion can be requested. Deactivating or freezing the account does not count on Google Play.

Permissions asked too early or without a reason

On iOS, every protected resource needs a purpose string in Info.plist, such as NSCameraUsageDescription or NSLocationWhenInUseUsageDescription. Apple expects the text to say clearly what the data is used for. A string that only says the app needs the camera invites a 5.1.1 rejection. Say what the user gets, for example that the camera scans receipts for expense reports.

Google Play's permissions policy allows only permissions needed for features the app offers and promotes in its listing, requested in context so the user understands why. Several sensitive permissions need a declaration in Play Console before the app is accepted, among them SMS and call log access, background location, access to all files and broad photo and video access.

Practical steps for both platforms:

1. Ask at the moment the feature is used, not on first launch.
2. Keep the app usable when the user declines, wherever the feature is not essential.
3. Prefer the system photo or contact picker over full library access.
4. On Android, inspect the merged manifest for permissions that an SDK added without your knowledge, and remove the ones you do not use.

Payments that go around the store's rules

This area produces the most painful rejections, because the fix can mean rebuilding the purchase flow. In outline:

• Digital goods and services used inside the app (premium features, subscriptions to content, in-game items) must use Apple's in-app purchase under guideline 3.1.1, and Google Play's billing system under its Payments policy.
• Physical goods and services consumed outside the app, such as retail orders, rides, food delivery and event tickets, use ordinary payment methods on both stores.
• One-to-one services between people, such as a tutoring session or a consultation, may use other payment methods under Apple's guideline 3.1.3. One-to-many services have to use in-app purchase.

The typical mistake is an app that sells a course, a membership or a content subscription and sends users to a web checkout. Both stores also run programs and regional exceptions that allow other arrangements in certain countries, and these have changed repeatedly. Read the current rules for each storefront you sell in, and take advice on anything borderline before you build it.

Listings, screenshots and login rules

Metadata rejections are the easiest to avoid. Apple's guideline 2.3 asks that descriptions, screenshots and previews reflect the app as it is. Names are limited to 30 characters and must not be stuffed with keywords or prices, and the listing should not mention other mobile platforms. Hidden features are treated as a serious violation.

Google Play limits titles to 30 characters as well and does not allow emojis, repeated special characters, claims such as "#1" or price promotions in the title, icon or developer name. Anonymous testimonials in the description are not allowed either.

Three Apple design rules catch new apps regularly. An app that is only a website inside a web view can be refused under 4.2 for minimum functionality. An app whose main sign-in is a social login must also offer an equivalent option that limits data collection to name and email and lets users hide their address (guideline 4.8), which Sign in with Apple satisfies. And apps with user-generated content need filtering, a way to report content, a way to block users and published contact details.

Builds the stores will not accept at all

Some submissions never reach a reviewer. Google Play requires new apps and updates to target a recent Android API level and raises that level every year. Apple sets a minimum Xcode and SDK version for uploads and moves it forward regularly. An app left untouched for a couple of years usually needs its tooling, framework and packages upgraded before a one-line fix can ship.

Resubmitting, and staying approved

Fix the cited issue, check the rest of the app for the same problem, and describe what changed in the review notes. If you believe the guideline was misapplied, reply with specifics or file an appeal.

Listing text, purpose strings and declarations are fixes any team can make itself. A payment flow that has to be rebuilt, or an app whose tooling is years out of date, is where outside help saves time. Nobody outside Apple or Google can promise an approval. What a team can do is run the checks above before every release, since approval is not permanent and rules that did not exist at launch will apply to later updates. Keeping builds, SDK inventories and declarations current is a large part of what mobile app maintenance covers. If the rejection concerns platform-specific code, iOS or Android specialists are the right people to ask, and our mobile app launch checklist covers the wider preparation.

Frequently asked questions

How long does app review take?

It varies with the store and the type of app, and neither store guarantees a time. First submissions and apps in sensitive categories tend to take longer than routine updates. Leave a buffer of several days before any announced launch date, and more if a rejection is possible.

Does a rejected update take the live version down?

Normally not. In our experience the version already published stays available while you fix and resubmit the update. The exception is when the store decides the live version itself violates a policy, in which case it can be removed until a corrected build is approved.

Are Flutter and React Native apps rejected more often?

The stores judge what an app does, not the framework it was built with. Cross-platform apps fail for the same reasons as native ones. The one related risk is an app that merely wraps a website, which can be refused for minimum functionality whatever it is built with.