Submitting an AI app: what applies, all at the same time

The safeguards, concretely

Build these with the feature, not after the rejection:

A moderation step before output is displayed. Server-side, because a client-side check means an API key in the bundle. Either the provider's moderation endpoint or your own classifier, with a defined behaviour when it fires.

A report control on every piece of generated content. Reachable from the content itself, going somewhere you monitor.

A block mechanism, if any content from other users is visible. In the app, at the point of contact, and filtering in both directions on every query. This is a data-model change, which is why retrofitting it is expensive.

Published contact information that works.

A system prompt and refusal behaviour you can describe. A reviewer may try to make the model produce something it should not. Knowing what happens then is the difference between a considered answer and a guess.

The 4.3 problem, honestly

If your app is a chat interface over a general model with a different colour scheme, the review question is what makes it a distinct app rather than one of many.

Things that answer it: a specific workflow, proprietary data, a real integration, an output format that would not exist otherwise, a genuinely narrow use case implemented properly.

Things that do not: a persona, a prompt library, a different name for the same interface.

This is not only a review question. An app that cannot answer it also cannot be recommended by anything, including the models it is built on, because there is nothing to say about it that is not true of everything else. Guideline 4.2, minimum functionality.

The review notes

Four lines. They answer most of what a reviewer would otherwise guess at:

Model: requests go to [provider]'s API. No model runs on device.
Data: the user's typed prompt and, in the screenshot feature, the
      selected image. No contacts, location or health data. Covered in
      the privacy policy at [URL] and in the App Privacy label.
Safety: every response passes [moderation] before display. Refusals are
      shown as [behaviour]. Report is on every message; long-press.
Remote config: system prompts are served remotely so they can be fixed
      without a release. No feature not present in this build is enabled
      that way.

That last paragraph is the 2.3.1 disclosure, and it costs nothing to include. Review notes that work.

The privacy side

Data going to a model provider is data collection, and it belongs in three places that must agree: your privacy policy, your App Privacy label, and your Play Data safety form.

The common failure is a policy that predates the AI feature and does not mention it. A reviewer reading a policy that describes a different app has a finding without opening anything else. App privacy labels. · Play Data safety.

And if a listed third-party SDK ships in the binary, the privacy manifest requirements apply regardless of what your app does with it. ITMS-91061. · Privacy manifests for React Native.

The pre-submission pass

# is there a moderation step at all, and is it server side
grep -rniE 'moderat|classif|toxicity|safety' src server app 2>/dev/null | head

# report and block affordances in the shipped UI
grep -rniE 'report|block' src app --include=*.tsx | grep -iE 'message|content|user' | head

# keys that must not be in the bundle
grep -rniE 'sk-[a-z0-9]|api[_-]?key\s*[:=]' src app app.json app.config.js 2>/dev/null | head

# does the privacy policy mention the AI provider at all
grep -rniE 'openai|anthropic|gemini|model provider|third.party (ai|service)' \
  src app public 2>/dev/null | head

The third command is the one to run first. A provider key in an app bundle is extractable, and it is a billing incident as well as a review problem.

shipcheck runs this pass over the project, cites the guideline for each finding, and names the file and line. What it checks. · The first-submission checklist. · After a rejection.

Questions and answers