App store submission checklist for an AI-built app that is ready to review

An app store submission checklist for an AI-built app should begin before the upload screen. A generated mobile interface can look finished while missing a privacy explanation, a working review account, a permission rationale, or a reliable release build. Store review evaluates the product people receive, not the speed at which the code was produced.

The right goal is not to predict approval. It is to remove avoidable ambiguity and prove that the submitted build works for a reviewer who does not know your project. Apple’s App Review Guidelines describe review across safety, performance, business, design, and legal concerns, and explicitly frame the guidelines as a living document. Google Play’s app setup guidance covers app creation, declarations, testing, release management, and app bundles. Use the current rules for the exact markets and capabilities your app targets.

Freeze the submitted product

Create a release candidate branch or tag before preparing store metadata. Record the version name, build number, commit, environment, and configuration used to produce the binary.

Release candidate

App version: 1.0.0
Build: 42
Commit: <immutable commit reference>
Environment: production configuration
Store targets: iOS, Android
Review owner: <person>
Rollback owner: <person>

Do not submit a build while the AI coding agent is still changing unrelated files. Inspect the complete diff, generated assets, dependency changes, native configuration, permissions, and release scripts. The artifact uploaded to the store must be reproducible from the recorded source and configuration.

If the app uses a hosted backend, confirm that the production API points to the intended environment. A store reviewer should not see a staging hostname, a seeded development account, or a service that disappears when your laptop sleeps.

Test the core path without developer help

Write the review path as numbered steps from a clean install:

1. Install the release build.
2. Create an account or use the supplied review account.
3. Complete the first-run permission explanation.
4. Perform the primary action.
5. Leave and reopen the app.
6. Sign out and sign back in.
7. Deny an optional permission and continue.
8. Trigger the documented error and recover.

Run it on a physical device where possible. Test a slow network, no network, a fresh account, an account with existing data, and a session that has expired. Confirm that loading, empty, error, and success states are visible rather than leaving a disabled control with no explanation.

An AI-built app often passes the happy path and fails at the second launch. Check navigation after a force-quit, interrupted upload behavior, duplicate submission, keyboard and screen-size behavior, and whether a back action returns to a sensible screen.

Prepare reviewer access

If the app requires an account, provide a working review account and exact instructions in the store submission flow. Explain any one-time code, role, seed data, or setup step. Do not make the reviewer guess which email address, workspace, or feature flag to use.

Before submission, verify the account against the release build:

• Credentials work from a clean install.
• The account has enough data to demonstrate the primary workflow.
• The account is not locked behind an employee VPN.
• Any required subscription or entitlement is available for review.
• The account does not expose another user’s private information.
• The instructions match the current UI labels.

If the reviewer cannot access a core feature, the rest of the polish cannot compensate. Treat review access as a release dependency and check it immediately before upload.

Review permissions and privacy

List every device permission the binary requests: camera, microphone, photos, location, notifications, contacts, calendar, health data, Bluetooth, or another sensitive surface. For each permission, answer why the app needs it, when it asks, what happens if the user denies it, and whether the feature can work without it.

Request a permission at the point of use when the product allows it. Show a clear explanation before the system prompt. Do not ask for a permission merely because a library makes it available.

Create a data inventory:

Reconcile the inventory with the actual release build, privacy policy, analytics configuration, crash reporting, model provider, and store disclosures. “The model only sees what the user sends” is not a sufficient review unless you can explain retention, processing, and access for the actual provider and configuration.

For an AI feature, document whether prompts, uploaded files, generated output, and feedback are stored. Give users a way to understand or delete data when your product and applicable requirements call for it. Never include credentials or private test data in screenshots, logs, prompts, or support instructions.

Validate metadata and store assets

Store metadata is part of the product contract. Check the app name, subtitle or short description, full description, category, age rating, keywords, support URL, privacy URL, marketing URL, screenshots, preview media, and localization.

Every screenshot should represent the submitted build. Remove debug labels, placeholder copy, fake account names, test servers, and UI that the reviewer cannot reach. Make the primary value clear without promising a capability the binary does not contain.

Check that:

• The icon is present in every required size.
• Screenshots use the correct device dimensions.
• Promotional copy matches the current feature set.
• The support contact is monitored.
• Privacy and terms links load over HTTPS.
• The age and content declarations match actual behavior.
• Subscription or purchase terms are complete where relevant.

Do not claim that an AI feature is guaranteed to be accurate. Explain what it does, what users should verify, and how they can report a problem. If output can affect health, finances, safety, employment, or another high-impact decision, add the appropriate review and product safeguards before submission.

Inspect the release binary

Run a release build rather than relying on a development preview. Install the exact artifact you will upload and inspect its network behavior, permissions, startup path, deep links, push notifications, and offline handling.

Check that production secrets are not bundled into the client. API keys embedded in a mobile binary should be treated as public. Put privileged operations behind a server boundary and authorize the user and resource on every request.

Review the binary for:

• Staging URLs and debug flags.
• Test endpoints and sample accounts.
• Excess permissions.
• Unused native capabilities.
• Missing privacy manifests or declarations required by your targets.
• Crashes on cold start.
• Broken deep links.
• Incorrect version and build metadata.
• Accessibility labels and focus order.

Run the platform’s available validation tools and read their output. A clean tool result is useful evidence, but it is not a substitute for installing and using the app.

Test purchases, subscriptions, and account deletion

If the app includes paid features, test the complete purchase and restore flow in the platform’s test environment. Confirm that a cancelled, pending, failed, restored, and expired purchase each produces a clear state.

Do not enable a paid feature based only on a client-side flag. Verify entitlement on a trusted server or through the platform’s signed transaction mechanism appropriate to your implementation. Handle delayed confirmation without charging or granting twice.

If users create accounts, check the current store requirements for account deletion and implement the full path where required. Deletion should explain what disappears, what must be retained for a legal or operational reason, and when the process completes. Test a user who has content, an active subscription, and a pending background job.

Check the backend and AI failure paths

A store reviewer may use a different network, device, account, and timing than your development team. Make the backend failure behavior part of the submitted product.

Test:

• Authentication expiry.
• A rejected request.
• Rate limiting.
• Model timeout.
• Provider refusal or invalid output.
• Upload interruption.
• Duplicate submit.
• Background job still running after the app closes.
• A server response with no data.

Return a user-visible explanation and a safe next action. Do not show internal stack traces, provider credentials, raw prompts, or database errors. If a request can create an external side effect, make retries idempotent and show whether the operation is queued, complete, or failed.

Ship an AI MVP to production covers the wider release gate. Safe AI agent tool permissions covers authorization and replay-safe side effects when the AI feature can call tools.

Give the coding agent a submission task with evidence

An AI coding agent can assemble checklists and fix individual screens, but it should not be allowed to declare store readiness from a screenshot. Give it the release candidate, the target platforms, the allowed files, and the acceptance evidence.

Review the mobile release candidate for store submission.

- Read the repository instructions and release checklist first.
- Inspect permissions, deep links, production endpoints, and privacy-related configuration.
- Run the release build and the focused test suite.
- Test cold start, sign-in, primary action, denial states, and sign-out.
- Do not change native configuration without listing the exact impact.
- Return passed, failed, and not-run checks separately.

Review every generated change. Keep release configuration in version control, require a human review for permissions and privacy declarations, and attach the build identifier to the review record.

Build a real rollback plan

Submission is not the end of release management. Record how to disable a broken AI feature, stop a failing job, revoke a compromised credential, and publish a corrective build. Keep the previous stable version identifiable.

Define a kill switch for provider outages or unsafe output when the product needs one. The fallback should be an honest unavailable state, not a fabricated answer. Monitor crashes, authentication failures, model errors, purchase failures, and support reports after release.

Google Play’s setup guidance describes app bundles, testing, release management, and permanent package-name considerations. Apple’s guidelines emphasize that review rules change over time and that developers are responsible for their app and third-party services. Read the current platform documentation again when a release adds a permission, purchase flow, sensitive data type, or new distribution target.

OTF’s templates page verifies a free MIT component SDK and a free AI configurations pack for Cursor, Claude, and Lovable. That is the relevant OTF connection for an AI-built app: a reusable UI and project-context starting point, not a guarantee of store approval or a substitute for platform testing.

An app store submission checklist is complete when a clean-install reviewer can access the app, understand its permissions and data use, finish the primary workflow, recover from common failures, and find a real support path. Lock the artifact, verify the declarations, test the failure states, submit with evidence, and keep rollback ready for the first build after approval.

Sources

• Apple App Review Guidelines
• Google Play: Create and set up your app
• OTF templates