Can you publish an AI-built app to app stores?

A policy-first checklist for moving an AI-built Expo or React Native app from preview through beta testing, reviewer access, and store submission.

AppX team · 2026-09-13

Yes. You can submit an app built with AI to Apple’s App Store and Google Play. The difficult part is not proving who wrote the code. It is proving that the submitted app is complete, useful, safe, accurately described, and ready for reviewers and real users.

This guide was checked against current Apple, Google Play, and Expo documentation on September 14, 2026. Store policies change, so open the linked policy pages again before submitting.

Does Apple or Google reject an app because AI wrote it?

The current public review documents cited here do not describe “AI-written code” as a separate approval category. Apple’s submission checklist focuses on crashes, accurate metadata, reviewer access, live backend services, and explanations of non-obvious features. Google Play asks for policy declarations, privacy information, reviewer access, target-audience details, and working functionality.

That does not create a guarantee. Apple and Google make the final decision for each submission. It means the practical question is whether your app and its operation satisfy the rules, not whether you typed every line yourself.

There is also an important distinction between two products:

• An app created with an AI builder: the generated project becomes the app you submit.
• An app that distributes or runs other generated software: the submitted app itself lets users create, download, or execute mini apps, plug-ins, games, or code.

Apple applies additional rules to the second category. Its App Review Guidelines restrict downloading or executing code that changes an app’s functionality and separately cover mini apps, streaming games, chatbots, plug-ins, and emulators. Reports about an AI-builder platform encountering those rules do not establish that every app created with AI is prohibited.

Know which stage your app has reached

A working preview is an important milestone, but it is not the artifact a store reviews.

Expo says EAS Build can create ready-to-submit binaries for Apple and Google stores. Uploading is a later action: Expo’s iOS submission guide explains that an uploaded build appears in App Store Connect and still has to be submitted for App Review. Google recommends beginning with internal testing and then moving to a small closed group through its Play Console test tracks.

If you are still testing through Expo Go, use our phone-preview guide before preparing a release build.

1. Finish one complete user journey

Choose the main reason someone installs the app. Test that journey from its real starting state through its final result. Include a new user, an existing user where applicable, and a failed request.

For a class-booking app, a useful path might be:

1. Open the schedule.
2. Select a class with one place remaining.
3. Confirm the booking.
4. See the place count and the user’s booking update together.
5. Try to book again and confirm that no duplicate is created.
6. Cancel and verify that the place becomes available again.

Remove sample labels, dead buttons, temporary images, and screens that only imitate a completed feature. Apple reports that more than 40% of unresolved review issues concern app completeness, including crashes, placeholder content, and incomplete information. Google’s production guidance likewise calls for stable functionality without crashes, missing screens, or broken behavior.

Keep a short screen recording of the accepted journey and record the app version, device, operating-system version, and result. That gives your next fix and any reviewer note a concrete reference.

2. Check identity and data access with separate users

If the app has accounts, test with at least two ordinary accounts. Confirm that one account cannot read, change, or delete the other account’s information by changing an identifier, replaying a request, or opening a copied link.

Do not rely on a hidden button or disabled screen as an authorization boundary. Access decisions for shared or private data need to be enforced by the trusted service that stores or returns that data.

Test sign-up, sign-in, sign-out, session expiry, password or account recovery, and an unavailable backend. If reviewers cannot reach protected features, both stores provide places for access instructions. Apple asks for an active demo account or a fully featured demo mode, while Google’s app-review preparation guide asks for access instructions for restricted areas.

3. Make privacy statements match the running app

Inventory the data collected by your code and every analytics, advertising, authentication, payment, crash-reporting, and social SDK. Compare that inventory with the privacy policy and store declarations.

Apple requires a privacy-policy link in App Store Connect and inside the app. Its policy must explain collection, use, sharing, retention, and deletion. Google requires privacy and Data safety information that reflects the app and its third-party libraries. Request sensitive permissions only when the core feature needs them, and explain their purpose in language the user can understand.

If the app creates accounts, deletion must be designed before submission. Apple requires users to initiate deletion inside the app. Google Play requires an in-app deletion path and a web resource where a user can request deletion. Read the current Apple account-deletion guidance and Google Play account-deletion requirements for the complete rules.

4. Remove secrets from the mobile client

A mobile binary is distributed to users. Treat every value bundled into its client code as readable, even when the source repository is private.

Check the exported project, configuration, build logs, and commit history for private API keys, database credentials, service-role tokens, signing material, and test accounts. Expo explicitly warns that variables prefixed with EXPO_PUBLIC_ are inlined into the compiled application and must not contain sensitive information.

Move privileged operations and credentials behind a trusted server. Then test how the app behaves when that server rejects, times out, or rate-limits a request. A polished loading animation is not a safe fallback if the client can bypass the server or exposes a reusable secret.

5. Review permissions, content, and communication features

List every camera, photo, microphone, location, contacts, notification, health, Bluetooth, and background capability requested by the final build. Remove permissions left behind by an abandoned generated feature. Test both approval and denial at the moment the permission is needed.

If users can post or exchange content, the app needs more than a text box. Apple’s user-generated-content rules require filtering objectionable material, reporting, blocking abusive users, and published contact information. Google also asks developers to declare the target audience and relevant content details accurately.

Review outgoing messages and sharing actions as well. A user should confirm the content and recipient before the app sends something on their behalf. Keep support links active and make the person or organization responsible for moderation clear.

6. Verify the payment model before the paywall

Write down exactly what a payment buys, where it is consumed, whether it renews, and how cancellation works. Test success, cancellation, decline, delayed confirmation, duplicate events, restore-purchase behavior, and expired access.

Digital goods and app functionality are generally subject to store billing rules, with programs and regional exceptions that can change. Check Apple’s current in-app-purchase section in the App Review Guidelines and Google Play’s current Payments policy before implementing the final flow.

Do not unlock paid access only because a client screen says payment succeeded. Use the store or payment provider’s verified server-side result as the durable source of truth.

7. Prepare accurate store information and reviewer access

The title, description, screenshots, age rating, privacy answers, support URL, and promotional claims must describe the submitted build. Capture screenshots from the current release candidate. Remove claims for features that are planned but unavailable.

Prepare reviewer notes that include:

• the main journey to test;
• demo credentials or a full demo mode;
• required setup or sample data;
• an explanation of non-obvious permissions and purchases;
• contact details for a person who can respond;
• a video when hardware or a difficult environment is required.

Keep backend services and review accounts working throughout review. Apple explicitly asks for full access and live backend services in its pre-submission checklist. Google Play’s App content workflow likewise includes restricted-area instructions, policy declarations, permissions, ratings, privacy, and target-audience information.

8. Run a production-style beta

Install the release candidate through TestFlight or a Google Play test track instead of testing only from the development server. Test the oldest device and operating-system version you claim to support, a current device, a slow or interrupted connection, denied permissions, an empty account, and an account with realistic data.

For new personal Play Console accounts created after November 13, 2023, Google currently requires a closed test with at least 12 continuously opted-in testers for 14 days before the developer can apply for production access. Verify the live personal-account testing requirements because account and regional rules can change.

Google Play also rejects repetitive or low-quality submissions. Its spam policy says apps should provide unique content or services rather than merely copying other apps or repeating nearly identical experiences. Use the beta to confirm that the app’s central value is visible and actually works.

Keep a release evidence record

Copy this checklist into the release issue or handoff and replace each bracket with evidence.

Release candidate: [version and build]
Source revision: [commit, tag, or untouched export filename]
Primary journey: [start, action, observable result]
Devices tested: [device and OS versions]

Core journey: [pass/fail and recording]
Second-user data isolation: [pass/fail/not applicable]
Empty, loading, error, offline, and retry states: [evidence]
Permissions approved and denied: [evidence]
Privacy policy and store disclosures checked: [date and owner]
Account deletion: [pass/fail/not applicable]
Payment success, cancellation, restore, and expiry: [evidence/not applicable]
Reviewer account or demo mode: [verified date]
Support and privacy links: [HTTP check]
Store screenshots from this build: [location]
Rollback or release-stop owner: [name and action]

Known limitations: [plain list]
Decision: [continue beta / submit / stop]

A submission should point to a specific build and evidence set. “It worked in the AI builder” describes an earlier stage.

Move an AppX project toward submission

AppX creates an Expo and React Native project you can test, refine, and download. Start with a bounded user journey, verify it on a phone, and export the source with a developer handoff before treating it as a release candidate.

You can continue with the exported project and Expo’s build and submission tools. AppX also offers separately scoped store delivery: the written quote can cover build configuration, signing, store assets, submission, and agreed review-response support. See how AppX store delivery is scoped.

No builder or delivery service can guarantee approval. Apple and Google review the submitted app and make the final decision. The useful goal is a complete app, a truthful listing, and enough evidence to respond clearly if a reviewer finds a problem.

Ready to create the first testable version? Describe your mobile app in AppX, then keep the store checklist for the release candidate.

Try your own app idea

Describe your app in AppX →