Getting an AI App Through App Store Review: A Checklist

A standard utility app has a short list of things a reviewer can object to. An app with a generative model inside has a much longer one, because the model can say or show almost anything. A reviewer who opens your chatbot and types something nasty is doing their job, and what comes back decides your outcome.

The rejections we see on AI apps fall into a handful of buckets: the app sends personal data to a third-party model without clear disclosure, it produces content the store treats as unsafe, it has no way to report or block that content, the subscription flow breaks payment rules, or the app is a thin wrapper that does not do enough on its own. Each has a fix, and each is cheaper to handle before submission than during a week-long back and forth.

Both stores revise their rules often, so treat this article as a preparation guide and read the current App Store Review Guidelines and Google Play Developer Policy yourself before you submit. Rule numbers and wording shift. The underlying concerns do not. If you have been rejected before for non-AI reasons, our general guide to App Store rejections covers the standard causes, and this piece focuses on what AI adds.

This is the area where AI apps trip most often. If your app sends user text, photos, voice or documents to a model API, that is personal data going to a third party, and Apple expects you to say so plainly and get permission before it happens. Apple's guidelines have called out sharing personal data with third-party AI explicitly since late 2025, so a vague line buried in your privacy policy is not enough.

Build the disclosure into the product, not only the legal text:

• A first-use consent screen. Before the first request goes out, show a short screen naming the provider category ("your messages are processed by a third-party AI service"), what is sent, and why. Include a clear accept button and a way to decline and still use the rest of the app.
• Accurate privacy labels. Your App Store privacy nutrition label and your Google Play Data safety form must match what the app does. If prompts include user content, declare it. Reviewers compare the label to observed network traffic more often than founders expect.
• A privacy policy that names the practice. State what you send to model providers, whether those providers may retain it, and whether it is used for training. If you use an API tier with zero retention, say so, since it is a selling point as well as a compliance detail.
• Minimization. Strip names, emails and identifiers from prompts when the feature does not need them. It reduces your exposure, and it gives you a straightforward answer when a reviewer asks.

If your feature can run on device, the story gets simpler. Data that never leaves the phone does not need the same third-party disclosure. That is one reason we often recommend on-device models for sensitive features, and our guide to Apple's on-device AI tools explains what is possible and where it falls short.

If your app lets users generate or share text, images or audio with a model, reviewers treat it like a user-generated content app, even when you think of it as a private tool. The expectations are consistent across both stores:

• A method for filtering objectionable output before the user sees it.
• A mechanism for users to report offensive or inaccurate content, with a timely response from you.
• The ability to block abusive users if the app has any social or sharing layer.
• Published contact information so people can reach you.

Implement these in layers. First, put the provider's built-in safety settings to work. The major model APIs ship moderation endpoints or safety parameters, and they are cheap or free. Second, add your own checks for the things that matter in your domain, such as a medical app that must not give dosage instructions, or a kids' product with a tighter bar. Third, add a visible report button on every generated item. Reviewers look for it.

Test it the way a reviewer will. Spend an hour trying to make your own app say something it should not: ask for violent content, sexual content, self-harm advice, hate speech and impersonation of real people. Whatever gets through is what you fix before submitting. Our walkthrough on how to build AI guardrails covers input and output filtering patterns in detail.

Image and video generation raises the bar further. Realistic images of real people, sexualized content and deepfake-style features are among the fastest routes to rejection or removal. If your product generates people, put hard limits on prompts that name real individuals and on anything involving minors.

Some domains draw closer review no matter how good the tech is. Health, mental wellbeing, finance, legal advice, children's content and dating all fall here. An AI assistant giving medical or financial guidance is a particular concern, because wrong answers hurt people.

What helps in practice:

• Frame the output honestly. Show a clear note that responses are generated by AI and are not professional advice, placed where users see it, not only in the terms of service.
• Route crises somewhere real. If a user of a wellness chatbot mentions self-harm, the app should surface crisis resources and stop pretending to be a therapist. Reviewers test this.
• Be accurate about claims. Describing your app as diagnosing, treating or detecting a condition can trigger regulatory questions and extra evidence requests. Describe what it does, such as "helps you track symptoms and prepare questions for your doctor".
• Age gating where needed. If an experience is not suitable for children, set the age rating honestly and enforce it. Mismatched ratings are a common finding.

For finance, remember that an app which moves money or gives investment guidance brings licensing questions that no review checklist can fix. Get legal advice early, before you build the AI layer on top.

AI features cost money to run, which pushes founders toward usage-based pricing, credits and subscriptions. Those models are fine, but they must fit the stores' payment rules.

The core rule is that digital goods and features consumed inside the app generally have to go through the platform's in-app purchase system. Credit packs for generating images, a subscription that adds more AI messages, a premium model tier: all of these are digital and typically use the store's billing. Sending users to your website to pay for them is restricted in many regions, and the rules there have shifted through court rulings and regulation, notably in the US and EU. If your plan depends on steering users to web checkout, read the latest policy for each region you ship in before building it. Our notes on Apple's current EU terms cover one part of that picture.

A few specifics that cause rejections:

• Unclear pricing. If a free trial converts to a paid plan, the screen must say the price, the billing period and how to cancel, before the purchase button.
• Credits that expire without warning. State expiry rules at purchase.
• A paywall before the reviewer can see what the app does. Reviewers need working access. Give them a demo account with credits already loaded, and explain it in the review notes.
• Restore purchases missing. Include it, since reviewers check.

Also model your unit economics early. If a heavy user can burn more in model costs than they pay, the paywall has to cap or meter usage. Rejections are not the only way AI pricing hurts.

Apple's minimum functionality rule has been used against apps that are little more than a chat box pointed at someone else's model, or a web view around a website. Google applies its own spam and minimum functionality standards in Play. If your app's whole value is a text field that forwards to an API, you are exposed, and it is also a weak business, because anyone can copy it in a weekend.

What separates a reviewable app from a wrapper:

• A defined job. The app solves a specific problem for a specific person, such as turning a photo of a receipt into categorized expenses, not "ask anything".
• Native capability that earns its place. Camera, notifications, offline storage, widgets, share extensions and on-device processing show the app is more than a skin.
• Your own data or workflow. Saved history, templates, integrations, team features or domain data that the raw model lacks.
• Distinct design and onboarding. A first-run experience that teaches the job, rather than dropping the user at a blank prompt.

Also avoid copying the branding of the model provider. Apps that look like official clients of a well-known AI product, or use its name and logo in the title or icon, get flagged for impersonation and misleading metadata. Name your app for what it does for the user.

If you are adding AI to an app that already exists, the minimum functionality question mostly goes away, because the AI sits inside a product with real depth. We outline that path in how to add AI to your existing app.

Run this list the week before you submit. Each item takes minutes and each maps to a rejection we have seen.

1. A consent screen appears before any user data is sent to a third-party model, with an option to decline.
2. Privacy labels and the Play Data safety form match the real data flows, including prompts, uploads and analytics.
3. The privacy policy names model providers or categories, retention and training use.
4. Output filtering is on, and you have tried to break it with at least fifty hostile prompts.
5. Every generated item has a report control, and you have an inbox that someone watches.
6. The age rating reflects what the model can produce, answered honestly.
7. AI-generated content is labeled as such where it could be mistaken for human or professional output.
8. In-app purchases handle credits, trials and subscriptions with clear pricing and a restore option.
9. The reviewer has a demo account, loaded credits and instructions that work from a clean install.
10. Your backend and model API keys are live and funded on the day of review. An empty quota that makes the app error out has caused more than one rejection.
11. The app name, icon and screenshots show your product, not a model provider's brand.

Then write the review notes with care. In the notes field, tell the reviewer what AI features exist, which provider category powers them, what safeguards you built (filters, reporting, blocking), where to find the consent screen, and how to log in. Reviewers read these, and a clear note often prevents a rejection that a mystery would have caused. If you get rejected anyway, answer the specific guideline cited, point to the exact screen that fixes it, and resubmit quickly. Polite and precise beats long and defensive.

On timing, plan for a few days to a week for the first review of an AI app, and budget a second round. Do not tie a launch event or paid campaign to a date that assumes you pass on the first try.

The cheapest rejections to fix are the ones you prevent in the first sprint. Decide on data flows, moderation and the payment model before you write the feature, because retrofitting a consent screen and a report system into a finished app costs more than building them from the start. As a rough guide, the consent flow, reporting and moderation pipeline add a few days of engineering to a typical mobile app, and a few weeks of rework if you skip them and get caught late.

Keep a living document with your answers to the reviewer questions above, and update it whenever a model provider, SDK or data flow changes. A swapped model vendor changes your privacy answers. Teams that treat store compliance as a one-time form tend to find out the hard way, usually right after a release.

If you are building an AI app for iOS and Android and want a team that has been through review on this kind of product, we can help you scope the features, the safeguards and the submission plan together. Book a free strategy call.