Need help understanding this app review decision

Apps
1

I recently received an app review decision that I don’t fully understand, and I’m not sure what I did wrong or how to fix it so my app can be approved. Can someone explain what reviewers usually look for, why an app might be rejected, and what specific steps I should take to successfully pass the next review?

2

First thing you need is the exact text of the review decision. Apple and Google both hide the real reason behind generic phrases, but the details are in the specific guideline number or policy name they quote.

Reviewers usually look for a few core things:

  1. Functionality
    • The app must work on first launch with no crashes.
    • All buttons, links, and main flows need to respond.
    • No dead ends. If a screen loads but does nothing, they often flag it.
    • If they say “app is incomplete” or “limited functionality”, they want:
    – Real content, not placeholders like “Coming soon” or lorem ipsum.
    – At least one clear, end to end user flow that makes sense.

  2. Content and value
    • They want to see what value your app gives users.
    • If your app is just a webview of a website, or a clone of another app with no changes, that triggers rejections.
    • If your app looks like a demo or test build, they reject for that.

  3. Account and login
    • If your app requires login, the reviewer needs a test account.
    • If you forgot to put test credentials in the review notes, they often reject with something like “cannot access full functionality”.
    • If login uses special hardware, VPN, company SSO, or geofenced content, you need to explain it step by step.

  4. Policy stuff
    Common triggers:
    • Privacy: Missing or unclear privacy policy, tracking without consent, requesting too many permissions for no clear reason.
    • Payments: Using external payment links where store rules require in app purchase.
    • Content: User generated content with no report or block mechanism.
    • Data: Collecting personal data and not explaining why or how you handle it.

  5. Metadata
    • App name, description, screenshots, and promo text must match what the app does.
    • They reject if screenshots show features not present in the build.
    • If you mention features that are disabled or “coming soon”, they see that as misleading.

Here is what I would do step by step:

  1. Re read the exact rejection message.
    • Note any guideline numbers, phrases like “spam”, “insufficient functionality”, “metadata”, “account required”, “safety”, “privacy”.
    • Copy those into a doc and map each one to something concrete in your app.

  2. Test your app like a new user.
    • Fresh install on a clean device.
    • No test data, no special flags.
    • Try every main feature. Note crashes, layout bugs, confusing screens.
    • If any action does nothing or looks broken, fix it before resubmitting.

  3. Fix obvious guideline issues.
    Examples:
    • Add a working privacy policy link, both in the store listing and inside the app.
    • If you ask for camera, location, or microphone, explain it in the permission prompt and use it in a real feature.
    • Add report/block if users can post content or messages.
    • If you show a website in a webview, add native features like push notifications, settings, offline handling, or extra tools.

  4. Update the review notes.
    • Tell the reviewer how to log in.
    • If there are limitations, say them clearly. Example: “Feature X only works in US. Use this test address.”
    • If you fixed something they mentioned, state it clearly: “Previous build crashed on screen Y, fixed in version Z.”

  5. If still confused, use the appeal or “Ask for more info” option.
    • Keep it short. Example:
    “I received rejection under guideline X.Y. I am unsure which part of the app triggers this. Could you clarify which screen or feature violates the guideline, so I can address it correctly.”
    • They sometimes respond with a more specific hint or screenshot.

If you paste the exact review text and the platform (Apple App Store or Google Play) in a reply, people here can point to the exact issue faster. The wording they use is often a big clue.

3

Couple of extra angles to add on top of what @yozora already covered:

  1. Look at what type of rejection it is
    They’re not all equal:

    • “Guideline X.Y – Informational” usually means “fix this and resubmit.”
    • “Spam / misleading / repetitive content” is more serious, because they may think your concept is the problem, not just implementation.
    • “Safety / deceptive behavior” is even more serious and can risk account flags.

    So before you tweak the app blindly, figure out if they’re questioning:

    • the idea of the app
    • the implementation
    • or the store listing / metadata

  2. Compare your app to what’s already in the store
    This part people hate to hear, but it matters:

    • On iOS especially, they’ll reject things that feel like:
      • “template apps” where you swapped logo/text and shipped
      • 20th calculator / wallpaper / quote app with no twist
    • Search the store for your app’s main keywords and ask:
      “If I were a reviewer who sees 50 similar apps a week, what about mine looks low-effort or redundant?”

    If your app is basically:

    • one screen
    • a webview
    • a reskinned template
      …then the rejection might be “we don’t see enough value,” even if everything works technically.

  3. Check for reviewer-hostile UX
    Reviewers have limited time. Some stuff that triggers rejection simply annoys them:

    • Long unskippable intro video or splash animation
    • Mandatory sign up before any preview of value
    • Onboarding that demands camera/location/notifications before explaining why
    • Walls of text or confusing navigation where it’s not clear what the app “does”

    Quick fix mindset: can a first-time user:

    • understand the main purpose in < 10 seconds
    • complete a core action in < 60 seconds
    • do both without reading instructions or guessing

  4. Watch for “invisible” policy problems
    Some rejections come from stuff devs think is harmless:

    • Hidden test menus, debug text, or flags left accessible in the build
    • Using trademarks/icons you don’t own (logos from other platforms, sports leagues, social networks, etc.)
    • Mentioning brand names in screenshots or text in ways that imply you’re officially partnered when you’re not
    • In-app links that jump to random external signup pages, Discord servers, Google Forms, etc.

  5. Track what keeps changing between builds
    If this is not your first rejection:

    • Write a simple changelog specifically for yourself and the reviewer:
      • “v1.0.1: fixed crash on profile screen”
      • “v1.0.2: removed external purchase page”
    • If rejections keep shifting (first “metadata,” then “functionality,” then “safety”), it can mean:
      • the app feels unstable / unpolished overall, so different reviewers notice different issues
        In that case, it may help to pause, polish everything thoroughly, then submit a more stable, cohesive version instead of rapid tiny patches.

  6. Be very specific in your reply to the review team
    I’ll slightly disagree with the usual “keep it very short” advice. Short is fine, but vague is bad.
    Better pattern:

    • A few short bullet points, each laser-focused:
      • “You mentioned guideline X.Y about misleading content. I removed feature Z from the description and screenshots, and the current build no longer shows that screen.”
      • “You mentioned access issues. Here is a working test account and a step-by-step login flow.”
        That combo of short + specific is what usually gets you a more useful human response.

  7. Future proof your design for review
    When you design new features, ask yourself:

    • “If someone who never heard of my brand opened this cold, would the purpose be clear?”
    • “Can they reach actual content or functionality without entering personal data first?”
    • “Did I request any permission I don’t absolutely need right away?”
      Designing with the review process in mind saves you from a lot of back-and-forth.

If you’re up for it, post the exact text of the decision and what platform you’re on. The phrasing they use is usually a giant neon sign pointing at the real issue, and folks can often tell in one or two lines whether it’s a “you need more polish” problem or a “this concept will never pass in its current form” problem.