A rejection email lands, you read it twice, and it still doesn't quite say what's wrong. That's the normal experience with AI apps. The frustrating part — and the useful part — is that most AI rejections are not about the model or the cleverness of the feature. They come down to a small set of visible gaps a reviewer can see from the outside: no clear AI notice, a privacy policy that doesn't load, data-use answers that don't match the app, permissions you don't need, or a key sitting in plain sight. This page is a triage guide: the recurring reasons, in the order worth checking them, and how to resubmit without going in circles.
One honest caveat up front. Every store has its own wording and its own reviewers, and the same feature can be waved through one day and bounced the next. So treat this as orientation, not a rulebook — for the exact requirement, always read the rejection notice and the official store guidelines it points to.
Read the rejection notice literally first
Before you change anything, read what the store actually said. Note the guideline number or reason code it cites and the screen or behavior it mentions. Reviewers often describe a symptom ("we could not find your privacy policy") rather than the root gap (the URL 404s for logged-out users). Take the notice at face value as a starting point, then verify the underlying item yourself. If the wording is genuinely unclear, that's a question for the Resolution Center, not a guess.
The recurring reasons AI apps get bounced
These are the gaps that come up again and again for conversational and generative apps. Not every one applies to every app, but they're the first places to look.
- Missing or weak AI disclosure. There's no in-context notice that the user is talking to an AI — only a marketing line like "AI-powered" in the footer, or the disclosure is buried in a legal page a reviewer never opens. → AI interaction disclosure
- Missing or unreachable privacy policy. The policy URL 404s, sits behind a login, or was never linked where the store expects it. For an AI app that sends user input to a model, a reachable policy is table stakes. → privacy policy
- Data-use mismatch. Your store data-use answers, your on-screen notices, and your privacy policy disagree with each other — or with what the app actually collects and sends to the model.
- Over-broad permissions. The app requests access (microphone, contacts, location, photos) it doesn't visibly need, with no clear reason tied to the AI feature.
- Exposed security surface. An API key, model endpoint, or admin path is visible in the shipped frontend or a public URL — a security problem that also reads as an unfinished, unsafe app. → exposed API key in frontend
The triage checklist, in order
Work these top to bottom. Each is phrased as something you can confirm yourself, and the linked detector tells you whether the signal is present on your public surface.
- The rejection notice is understood, not guessed at — you have the guideline number and the screen it refers to written down.
- A plain-language AI notice is on the chat or assistant screen, visible before the first message: e.g. "You're chatting with an AI — responses are AI-generated and may be inaccurate." → AI interaction disclosure
- That notice is visible to a logged-out reviewer, since that is what an automated scan and a first-time reviewer see. → AI interaction disclosure
- Your privacy policy loads at the submitted URL, is not behind a login, and describes what user input is sent to the model and to any third-party providers. → privacy policy
- Data-use answers are consistent across the store questionnaire, the app's on-screen notices, and the privacy policy — no contradictions.
- Every requested permission has a visible, feature-tied reason, and anything you don't use is removed.
- No key, endpoint, or admin surface is exposed in the shipped frontend or a public URL. → exposed API key in frontend
- You've checked the framework-specific rules your feature touches — Apple's AI-related review expectations, and EU transparency duties for chat and generated content. → App Store 5.1.2 AI rejection checklist, EU AI Act Article 50 checklist
Tick the AI-notice, privacy-policy, and exposed-surface items and you've closed the gaps behind most AI rejections. The rest is consistency and cleanup.
What LaunchTrust checks — and what it doesn't
LaunchTrust does not judge whether your app is "compliant" or predict a reviewer's decision — no scanner can. What it does is fetch your public page and surface the observable signals a reviewer tends to look for, from the same HTML an anonymous visitor receives:
- The
ai_disclosuredetector reports detected when it finds a disclosure snippet or plain wording like "you're chatting with an AI," and not detected when only a bare "AI-powered" label or nothing is present. - The privacy policy detector reports whether a policy appears present and reachable.
- The exposed API key detector flags credential-shaped strings visible in the served frontend.
Every result is a signal, not a verdict. "Detected" means the wording or snippet is on the page — it does not confirm the notice is placed correctly, worded sufficiently, or accepted by any given reviewer. And a scan reads your public surface only; it does not open your binary or your store metadata, where other rejection reasons can live. Confirm those against the official guidelines.
Resubmitting without going in circles
Fixing the gap is half the job; showing the reviewer what changed is the other half. When you resubmit:
- Respond in the Resolution Center. Reply directly to the reviewer rather than silently pushing a new build.
- Name each concern they raised and pair it with the exact change — where the AI notice now appears, the URL the privacy policy loads at, the permission you removed.
- Point to the specific screen or link so the reviewer can verify in seconds instead of hunting.
- Re-scan first and confirm the signals flipped, then check each fix yourself in a logged-out session before you send.
A short, concrete note that maps changes to concerns tends to clear review faster than a resubmission that leaves the reviewer to re-find everything.
Check this in 30 seconds
Run your app's public URL through LaunchTrust's free scanner. It fetches your live page and reports whether an AI disclosure is detected, not detected, or unable to determine — alongside your privacy policy and any exposed credential-shaped strings — so you can spot the visible gaps behind most AI rejections before you resubmit. No signup, no crawl of private pages: it reads the same public HTML your reviewer gets. It won't guarantee approval, but it will stop you from resubmitting with the same gap still open.
FAQ
Why do AI apps get rejected more often than other apps? AI apps carry extra expectations that ordinary apps don't. Reviewers commonly look for an in-context notice that a user is dealing with AI, a clear account of what user input is sent to a model, a reachable privacy policy, and no exposed keys or endpoints in the shipped surface. Most rejections trace back to one of these being missing or unclear rather than to the AI feature itself. Confirm the exact reason against the rejection notice and the official store guidelines.
The rejection notice is vague — how do I find the real cause? Start with the guideline number or reason the store cited, then work the triage list in order: AI disclosure, privacy policy reachability, data-use consistency, permissions, and exposed security surface. Many notices point at a symptom rather than the root gap, so check each visible item yourself instead of guessing. If the wording is unclear, ask the reviewer in the Resolution Center for the specific concern.
Does a clean LaunchTrust scan mean my app will be approved on resubmit? No. A scan reports signals — whether an AI disclosure, privacy policy, or exposed secret is detected on your public surface. It does not review your binary, your metadata, or how your feature behaves, and it cannot predict a reviewer's decision. Use it to catch the visible gaps before you resubmit, then confirm everything else against the official guidelines. LaunchTrust is a compliance aid, not legal advice or an approval guarantee.
How should I respond in the Resolution Center after fixing the issues? Reply directly to the reviewer, name each concern they raised, and describe exactly what you changed — where the AI notice now appears, where the privacy policy lives, which permission you removed. Point to the specific screen or URL. A short, concrete reply that maps changes to concerns tends to move faster than a resubmission with no note.
Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict, certification, or approval guarantee.