App Store Review for AI Features

Both stores review an app that can generate open-ended text or images roughly as though a stranger had typed that content into it, because from the store’s position that is what is on the screen: material nobody vetted, displayed under your name and theirs. Almost every rejection follows from that one reframing, and so does the fix.

Review tests the build, not the intention

A reviewer has your binary, your metadata and a short amount of time. Anything you assert that they cannot reach is not evidence to them, however true it is. This is the whole difference between teams that pass on the first attempt and teams that spend three weeks in correspondence.

A claim fails review for one of three reasons: it describes a system you do not control and cannot demonstrate, it lives in a document rather than in the app, or it needs a state the reviewer cannot get to. The productive exercise before submitting is to take every expectation the guidelines set and write down the artefact in the build that satisfies it.

Generated output is treated as user-generated content

The most common answer teams give — that the model provider filters its output, so moderation is handled — does not survive contact with review, for four independent reasons.

• It is a claim about somebody else’s system. You cannot demonstrate it, you did not configure most of it, and it can change without your release. A provider’s safety behaviour is a dependency, not a control you own.
• It only covers the model call. It does not cover the image a user uploaded, the document your retrieval step pulled in, the text a user typed that you then displayed to another user, or the share sheet that puts the output onto a social network with your branding on it.
• Filters have false negatives, and everyone knows it. A guideline written on the assumption that some material gets through is asking what happens next. That question is answered by a report path and a human, not by a better classifier — and the precision and recall trade-off that makes this unavoidable is set out in building a content safety layer that is not useless.
• A reviewer will try to break it. Adversarial prompting is a normal part of reviewing this category. If the only defence is the provider’s filter, the reviewer’s third attempt is the screenshot attached to your rejection.

So the shape of an answer that passes is two layers, not one: a pipeline stage that blocks what it can, and a route from a bad output to a person who can act. The second is what the guidelines are really about, and it is the one most AI apps ship without. What that route costs at volume, and what due process on it looks like, is the subject of moderation at scale and its error rates.

Two specific cases are worth naming because they are handled badly so often. If users can send images into a model, the input path needs moderation as much as the output path does, and obligations around child sexual abuse material exist in law independently of any store rule — those are not a review problem to solve at submission time. And if generated content is stored and shown to other users, your app is a content platform, with everything that implies, whatever the pitch deck calls it.

Age rating: the questionnaire asks what the app can produce

Both stores rate an app from a questionnaire the developer fills in. The questions are about content the app can present, at what frequency and intensity: profanity, sexual material and nudity, realistic or cartoon violence, horror, alcohol, tobacco and drugs, gambling and simulated gambling. There are structural questions alongside them — does the app contain user-generated content, does it allow unrestricted access to the internet, does it have social features, does it share location.

An app wired to a general-purpose model answers those structural questions honestly with a yes, and that alone usually takes the lowest ratings off the table. The mistake is answering as a product manager describing the intended product rather than as an engineer describing the reachable output space: “it is a recipe assistant” is a statement about the prompt, not about the model, and a user who types something else gets something else.

The two stores use different instruments, which matters more than it sounds. Apple runs its own questionnaire. Google Play uses the IARC questionnaire, which issues separate ratings per territory from the boards that operate there, so one set of answers produces several different ratings and the strictest board governs your reach in its region. Answering the two questionnaires inconsistently is itself something that gets noticed.

There is an honest way to earn a lower rating, and it is a product decision rather than a form-filling one: constrain the output space so that the honest answer changes. A fixed task with structured output, an input classifier that refuses off-topic requests before the model sees them, and no free-text passthrough is a genuinely narrower app. If free text reaches a general model and the reply reaches the screen, the space is open and the rating must say so.

Credits, subscriptions and platform billing

The principle both stores work from is a distinction between digital content or services consumed inside the app, which their billing systems are meant to handle, and physical goods or services consumed outside it, which they are not. Credits a user spends on model calls within your app sit squarely on the first side of that line. A subscription to a service the user mainly uses elsewhere may be treated differently, and the exceptions that allow it are narrower than teams assume.

Two mechanical details cause more grief than the policy question. The first is that credits are consumables: they are bought, spent and gone, and consumable purchases generally do not restore themselves onto a new device. Keep the balance on your own server, keyed to your own account, and treat the store receipt only as the instruction to credit it. Otherwise a reviewer who buys credits and reinstalls finds them missing, which is both a rejection and a real bug you would have shipped.

The second is that the commission lands on revenue while the model call lands on cost, and for AI features the cost of goods is large enough that the order matters. That is arithmetic you can do before choosing a price:

Assumptions, all replaceable with your own:
  pack price to the user            $10.00
  commission rate r                 0.30  (and 0.15 as a second case)
  tokens the pack buys              2,000,000
  input:output split                3:1
  model price       $0.50 / M input, $1.50 / M output

Cost of goods for one pack
  input   1,500,000 x 0.50 / 1e6  =  $0.75
  output    500,000 x 1.50 / 1e6  =  $0.75
                                     -----
                                     $1.50

Net after commission
  r = 0.30   10.00 x 0.70 = $7.00   margin  7.00 - 1.50 = $5.50
  r = 0.15   10.00 x 0.85 = $8.50   margin  8.50 - 1.50 = $7.00

Same pack, a model priced 10x higher
  cost of goods                      $15.00
  r = 0.30   margin  7.00 - 15.00 = -$8.00 per pack sold

The last line is the one to sit with. A pricing sheet that works on the web can invert once a commission is taken off the top, and the inversion is invisible until you write it down. Refunds compound it: the store can refund a purchase after the tokens have been spent, so the tokens are gone and the revenue is too. Decide in advance whether credits expire, what happens to a refunded balance, and whether a single account can be drained through repeated refunds.

Privacy disclosures when prompts leave the device

Both stores require a declaration of what the app collects, whether it is linked to the user’s identity, and whether it is used for tracking. The recurring error with AI features is answering “no data collected” because the team keeps no database. Collection in this sense covers transmission: if a prompt leaves the device and reaches a model provider, it has been collected and shared, whether or not anyone stores it.

• Prompts are user content, and often more. People paste medical details, contracts and other people’s personal data into a text box without being asked to — the behaviour described in what actually happens to what you type into an AI. Declare the category that reflects what users really send, not what your onboarding copy suggests they will.
• You are answerable for your dependencies. The declaration covers the app as shipped, including every SDK in it: the model provider, analytics, crash reporting, attribution. A third-party library collecting an identifier is your disclosure to make.
• Training is the sharpest question. Whether the provider may train on what you send is a property of your contract and your endpoint, and it changes by tier and by setting. Establish the answer for the exact configuration you ship — what zero data retention does and does not mean is the place to start, because the term is used for several different arrangements.
• Three artefacts must agree. The store declaration, the privacy policy and the app’s actual behaviour. A mismatch between any two is a rejection at review and a separate problem with a regulator afterwards, which is the practical end of GDPR for AI APIs.

This is the one review dimension that on-device inference genuinely shrinks. If the model runs locally and the prompt never leaves, there is no transfer to declare and no processor to name — the memory arithmetic that decides whether that is possible is worth doing before you conclude it is not. Be precise about it though: telemetry, crash reports and analytics still leave, and an app that advertises local processing while shipping prompt text to an analytics SDK has made a claim it cannot support.

Children, and the rules that switch on early

The children’s regimes are stricter than the general ones and they attach earlier than teams expect. What triggers them is not building a children’s app, but whether the app is directed to children or knowingly reaches them — which a mixed-audience app does by default, and which visual style, subject matter and marketing all feed into.

• Third-party data flows are restricted, not just labelled. The families programmes on both stores limit what may be collected from and shared about children, and constrain third-party analytics and advertising SDKs. Sending a child’s free-text prompt to an external model provider is precisely the kind of transfer these rules exist to govern.
• Consent is verifiable, or it is not consent. Where a parental consent regime applies, the standard is a verifiable mechanism, not a checkbox saying the user is over an age.
• An age screen decides which regime a user is in. A neutral age gate that does not prompt the answer, applied before any data is collected, is how a mixed-audience app applies the right rules per user — and how it avoids applying the strictest ones to everybody.
• Open-ended generation and a young rating rarely coexist. If the app targets children, expect to constrain the model far more tightly than an adult product would: fixed tasks, allow-lists, reviewed output templates. That is a design decision, and it belongs at the start of the project rather than in the resubmission.

What the reviewer needs to reach your feature

A large share of AI-app rejections are not judgements about the app at all. They are a reviewer who could not get to the feature, and the fastest available conclusion.

1. Give a demo account with balance already on it. If the feature needs credits, the account must have them, and it must keep having them after a previous reviewer spent some. Top it up as part of the release process rather than once.
2. Name the screen. Write the exact path in the review notes: which tab, which button, what to type. “We were unable to locate the feature” is answered by three sentences you could have written first.
3. Attach a recording where the feature depends on conditions. A model that downloads after install, a device-class requirement, a region-limited provider — each of these can leave a reviewer looking at a progress bar. The delivery mechanics and the review note that goes with them are covered in model size budgets for app stores.
4. Make every failure state legible. A refusal, a rate limit, a provider outage and a network error should each say what happened. A spinner that never resolves is indistinguishable from a broken build, and it is judged as one.
5. Test the app adversarially yourself first. Spend an hour trying to make your own app produce something you would not want in a screenshot. Whatever you find, the reviewer can find, and the question is only who finds it before submission.

What to prepare before submitting

Assemble these as artefacts rather than intentions. Each line is something a reviewer can reach, or something you can point at when asked.

• In the build: input and output filtering with a visible refusal state; a report control on each generated item; a block control wherever content moves between users; a neutral age gate if the audience is mixed; legible failure states.
• In writing: a moderation statement covering what you filter, what a report triggers and how quickly; a privacy policy that names the model provider as a recipient and states the position on training; a working contact route that needs no account.
• In the store metadata: data-collection declarations that include everything transmitted by every SDK; an age rating answered against what the model can produce; consistent answers across both questionnaires.
• In the review notes: demo credentials with balance, the exact path to the feature, a recording if it depends on a download or a device, and a sentence on whether users can see each other’s content.
• Behind it: a queue where reports land with an owner; a decision on refunds and credit expiry; a plan for what happens when the provider changes a safety default under you.
• Checked on the day: both stores’ current guidelines. This page describes mechanisms because the specifics move, and the version that matters is the one in force when you press submit.

One last piece of sequencing. Swapping the model, moving from a hosted provider to a local one, or changing where credits are sold all alter the answers above, so a change that looks purely technical can require a new rating, a new declaration or a new billing arrangement. Treat the release process for a model change with the same care as rolling out a model to devices you do not control — the store paperwork is part of the rollout, not a step after it.