Quick answer
An AI-built app goes through the same App Store review as any other app. Apple checks the build you submit against its App Review Guidelines, whichever tool wrote the code. To pass, replace mock data and placeholder screens with working features, keep secrets out of the bundle, match your privacy labels to the SDKs the agent added, and give the reviewer a demo account that works.
Does Apple review AI-built apps differently?
The paywall looks done. Restore Purchases shows a spinner and then a success toast. Then you open PaywallScreen.tsx and find const isPro = true; // TODO: connect StoreKit on line 14, written by your coding agent three weeks ago and never touched since.
Apple reviews that app the same way it reviews hand-written code. The App Review Guidelines mention AI in one place, guideline 5.1.2(i), and that rule is about sharing user data with third-party AI at runtime. No guideline addresses how the code was written, so using Claude Code, Codex, Cursor or GitHub Copilot neither excuses a half-built feature nor counts against you.
AI-built apps do fail review in a recognizable pattern, though. Coding agents are good at producing screens that look complete and less careful about what happens behind them. Apple says over 40% of unresolved issues fall under guideline 2.1 App Completeness (crashes, placeholder content, incomplete information), and a fake paywall is exactly that kind of problem. The steps below target the gaps agents tend to leave.
Step 1: Find the screens that only look finished
Start with a search, before you polish the store listing. Agents leave fixtures, TODOs and local addresses behind when they make a screen render:
Some hits will be real test fixtures. The ones that matter are in code the release build runs. Then open the app and press every button that promises an outcome, checking the outcome on the server rather than on screen.
| What the screen shows | What to check | How to check it |
|---|---|---|
| Core feature works | The user can finish the main task with real data | Create a record, kill the app, reopen it and find the record |
| Sign-in and sign-out | Sessions survive expiry, and logout clears the previous user's data | Sign in as user A, log out, sign in as user B |
| Paywall or subscription | Access follows the real transaction, not a local flag | Buy, cancel and restore in Apple's sandbox environment |
| Delete account button | The server account and its data are actually removed | Delete a test account, then try to sign in with it |
| Support and privacy links | The pages load for someone outside your company | Open each link signed out, on cellular |
| App Store description | Every feature it mentions exists in this build | Read the listing next to the running build |
A Delete account button that only clears local state is the classic example. So is a dashboard still reading a JSON fixture the agent created on day one, or a Restore button that flips a boolean in memory.
Step 2: Remove secrets and development servers from the build
Search the client code for API keys. An agent that wired up OpenAI, Anthropic, Stripe or a database admin key to make a demo work will often have put the key wherever the call happens, which can be inside the app. Anything shipped in the app can be read by anyone who downloads it.
In an Expo project, values in EXPO_PUBLIC_ variables are inlined into the JavaScript bundle and, as the environment variables guide puts it, "will be visible in plain-text in your compiled application." Move private keys to a server you run, and have the app call that server with the user's own session.
Next, run the release build with your laptop switched off. A packaged app must not depend on a Metro dev server, an ngrok tunnel or the agent's temporary sandbox. Guideline 2.1 asks you to keep backend services live and reachable during review, so every service the app talks to needs to be one you actually operate.
Check authorization on that server too. A list screen that hides other users' records proves nothing about whether the API will return them. Write one test that requests another user's data with a valid token and expects a 403.
Step 3: Check the SDKs and permissions the agent added
Read the dependency diff for the whole project, not only the last commit. Agents add packages to get a feature compiling, and each native SDK can bring its own data collection and permission prompts. Remove packages the finished app no longer uses.
Then rebuild your privacy answers from the code. A privacy policy the agent wrote is a draft until it matches what the app sends and to whom. Guideline 5.1.1(i) requires a link to your privacy policy both in App Store Connect and inside the app, and Apple's app privacy details page explains how to declare data collected by you and by third-party partners such as analytics and crash-reporting SDKs.
Check every permission prompt against a feature the user can see. If Info.plist asks for camera access because an unused image-picker package requested it, the reviewer will ask why. Write each purpose string in words the user can connect to the button they just tapped.
Images, icons and fonts need the same scrutiny. Keep a list of where each asset came from and what license covers it. An attribution line generated by an agent does not prove you have the rights, so ask someone qualified when the source is unclear.
Step 4: Disclose AI features that run inside the app
Writing code with AI and shipping an AI feature are separate questions for review. If the app sends user data to a model provider at runtime, guideline 5.1.2(i) requires you to clearly disclose where personal data will be shared with third parties, "including with third-party AI," and to get explicit permission before sharing it.
Test the feature when the model call fails or returns something unusable. Show a retry or a plain error, never a blank card or a fake success. Where the output feeds a decision the user makes, say that it was generated and may be wrong.
Step 5: Finish account deletion and in-app purchases
Agents tend to build the first half of a flow. Sign-up works; deletion is a button with no handler. Guideline 5.1.1(v) says that if your app supports account creation, it must also let users delete the account from inside the app. Apple's account deletion guidance covers what the flow needs, and you should verify the result on the server rather than trusting the confirmation screen.
For purchases, guideline 2.1(b) requires in-app purchases to be complete, visible to the reviewer and working, and guideline 3.1.1 requires in-app purchase for unlocking features or content inside the app. Payment rules vary by product type and storefront, so read the current text instead of reusing a rule from an old prompt. Apple's getting started resources link to in-app purchase testing. Test buying, cancelling and restoring, and confirm your server agrees with StoreKit about who has access.
Keep the review account honest. Give it the access the reviewer needs to see paid features, but run the same purchase and account code a new user gets. A review-only code path runs into guideline 2.3.1, which bans hidden or undocumented features and says the app's functionality should be clear to both users and App Review.
Step 6: Make sure the app does enough
Agents can generate a polished app in an afternoon, and so can everyone else with the same prompt. Guideline 4.2 Minimum Functionality asks for features, content and UI that take an app beyond a repackaged website, and 4.3 Spam rejects apps that are indistinguishable from what is already widely available. If the core idea is a thin wrapper around a chat API, put the work into the product before the submission.
Adding a camera button or push notifications to look more native does not help. Reviewers judge whether the app solves one problem well.
If you built from a commercial template or an app generation service, read guideline 4.2.6 as well. Apple rejects apps created that way unless the provider of the app's content submits them.
Step 7: Rehearse review with a clean install
Build the exact release you plan to submit and install it on a device that has never run the app. If this is an update, also install the current App Store version first, create some data, and upgrade over it.
Hand a colleague the review account and the notes you plan to give Apple, and nothing else. Watch where they get stuck. Every question they ask is a gap in the review notes or in the product.
Keep a short record with the build so the person answering App Review knows what was tested:
Put the demo credentials in the App Review Information section of App Store Connect, never in screenshots or the public description. Write the store description after the rehearsal, take screenshots from this build, and cut any feature that is still on the roadmap. Guideline 2.3.3 asks for screenshots that show the app in use, and Apple's screenshot instructions cover the upload.
Step 8: Submit and handle the reviewer's questions
Submission works exactly as it does for any other app. Select the build you rehearsed, complete the version's metadata, and follow Apple's submission instructions, which separate adding items to a submission from sending it to App Review. Name one person to watch App Store Connect for messages.
If the reviewer reports a problem, reproduce it on the submitted build with the review account before changing anything. Fix the layer that broke, whether that is code, server or metadata, and say what changed in your reply.
Ownership continues after approval. The backend, the account support inbox and the dependency upgrades all need someone, and an agent that wrote the code will not be watching your crash reports at 2 a.m.
Where Expo fits
Expo gives a coding agent a standard React Native project structure to work in, with config in app.json and native projects generated from it. EAS Build compiles the signed iOS build on hosted macOS machines, and EAS Submit uploads it to App Store Connect, from macOS, Linux or Windows.
Follow the iOS submission guide once the checks above pass, and pick the build you rehearsed rather than the newest one. After approval, EAS Update can ship JavaScript and asset fixes to that build within App Store Review Guideline 2.5.2. An update cannot add native code, and it does not replace App Review for changes to what the app does.
Limitations
Build and upload services cannot check whether your metadata is true or whether your business model meets every applicable rule. A successful upload is not an approval, and no checklist guarantees one.
Expo Go cannot load custom native code your agent may have added. Test a development build or the release build itself, because a working web preview or Expo Go session says little about how the signed iOS build behaves.
Next step
Read Apple's App Review preparation resources, then run Step 7 with a colleague on the exact build you plan to submit.
Verified on 12 September 2026.