What gets apps rejected most often?

Review teams are not looking for reasons to reject you — they are checking that a stranger can install your app and understand it without help. The recurring failures are unglamorous.

Reviewers are not assessing whether your architecture is elegant. They are checking whether a stranger can install the app, understand it, and use it without contacting you — and whether the data you collect matches what you declared.

  • Demo credentials missing or expiring before review completes
  • Privacy policy absent, or the data-safety declaration contradicts what the app collects
  • Placeholder content, lorem ipsum or 'coming soon' screens in the review build
  • Screenshots that don't match the actual app experience
  • Crashes on older devices or in regions the reviewer is testing from

What does each store actually check?

Apple and Google are looking for the same things with different emphases. Apple's review is more editorial: it cares about design quality, whether the app feels native, whether it duplicates a website in a way that adds nothing, and whether digital purchases use Apple's payment system. Google's review is more mechanical, leaning on automated scanning, policy compliance and the accuracy of your data safety form.

Practically, that means Apple rejects more often for subjective reasons and Google more often for technical or policy ones. An app that sails through Google's automated checks can still fail Apple review for feeling unfinished.

  • Apple — design quality, native feel, in-app purchase rules, minimum functionality
  • Google Play — policy compliance, data safety accuracy, target API level, permissions
  • Both — account deletion, privacy policy URL, working demo access, no placeholder content

What assets do you need before submitting?

Assemble the full store package before you build the release binary — gathering it late is the most common cause of a two-week slip. You need app icons in every required size, a feature graphic, a set of screenshots per device class, a short and long description, a privacy policy URL, and a support contact that a real person monitors.

Write the description for a customer, not a search engine. Store search rewards clarity and keyword relevance in the title and first lines, but reviews punish keyword stuffing.

Build the asset list as a checklist and gather it before the release binary is final. Screenshots in particular should show the app's real value in the first frame — the first two images do most of the work on the listing page, because that is all most people see before scrolling.

How do you write store listings that get found?

Store search is a real acquisition channel and far less competitive than web search. The title and subtitle carry the most weight, followed by the first lines of the description. Put your category term and your differentiator there — 'Invoice Tracker for Freelancers' beats 'InvoicePro', because one of them describes a job.

Then write for humans. Reviews punish keyword stuffing, and both stores increasingly weight engagement and retention over raw keyword density. Describe what the app does in the first two sentences, then explain the outcomes. Keep the long description scannable with short paragraphs rather than one wall of text.

What should you test before you submit?

Test on the devices reviewers will use, not just the newest phone in your office. That means an older Android device, a small screen, a slow connection, and at least one region outside your own. Most rejection-causing crashes are device-specific or region-specific.

Test the whole first-run experience from a fresh install with no cached state. Then test it again with the demo account a reviewer will use, and confirm that account has content in it. An empty demo account is one of the most common reasons an app is rejected for incomplete content.

  • Fresh install on an older Android device and a small-screen iPhone
  • Every permission prompt, and what happens when it is denied
  • Demo credentials that do not expire before review completes
  • Account deletion, if your app supports account creation
  • Offline and poor-connection behaviour on every critical screen

How do you prepare for the privacy review?

Privacy is where otherwise-finished apps stall. Map every piece of data your app collects, where it goes and why, then make the store declaration, your privacy policy and your in-app prompts say the same thing. Inconsistency between those three is treated as a material problem, not a paperwork error.

If you use third-party SDKs for analytics, crash reporting or ads, their data collection counts as yours. Audit them before you declare.

Write the policy in plain language and make it reachable from inside the app as well as from the store listing. If you collect location, contacts or health data, expect scrutiny and be ready to justify why each one is necessary for a stated feature.

What does a clean release process look like?

Treat submission as a staged launch, not a switch. Ship to a closed test group first — internal, then a small external cohort — for at least a week. Watch crash-free rate and the first three screens of your onboarding funnel.

Then submit with a written review note: what the app does, how to reach any gated content, and where the demo credentials live. A short note consistently shortens review time.

Use a staged rollout. Both stores let you release to a percentage of users, which turns a launch into a controlled experiment rather than a coin flip. Start at 10–20%, watch crash-free rate for 48 hours, then widen.

What happens if your app is rejected?

Rejection is normal and rarely fatal. Read the guideline reference in the rejection message, fix exactly what it names, and reply in the resolution centre with a short explanation of what changed. Arguing about the guideline wastes days; fixing it and resubmitting usually clears within 24–72 hours.

The exception is a rejection that questions your app's core premise — minimum functionality, or duplicating a website without adding value. Those need a substantive change rather than a resubmission, and it is worth understanding that risk before you build rather than after.

What should you do in the first week after launch?

Watch three numbers daily: crash-free rate, day-one retention, and where people abandon onboarding. If crash-free rate drops below 99.5%, stop promoting the app and fix it — a bad first impression in a store is expensive to undo, because ratings recover far more slowly than they fall.

Respond to every review for the first month, including the negative ones. A short, specific reply to a complaint is read by far more people than the reviewer, and store algorithms weigh review responsiveness more than most developers assume.