App Store & Google Play Publish Checklist

Shipping a vibe coded app? This checklist covers store-ready builds, app signing, privacy declarations, Google's Data safety form, and App Store review — with links to official Apple and Google documentation.

Published May 2026, updated June 2026 by Batteries Included

If you vibe coded your app into something that runs on your phone, you are further along than most first-time builders. The next milestone is different: a store-ready version that survives Google Play or App Store Connect without signing surprises, wrong upload files, or policy mismatches.

Neither store reviews the everyday test build you run from Xcode (Apple's app editor) or Android Studio. Google Play expects a signed store upload (typically an Android App Bundle (AAB)); the App Store expects a saved build you validate and upload through App Store Connect. Both require forms that match how your app actually uses data: Google's Data safety form, Apple's privacy declaration files (including required-reason application programming interface (API) disclosures for Apple / App Store), and behavior that matches your store listing. When you move fast with AI-assisted development, those steps are easy to skip until Play or App Store Connect blocks an upload, review pushes back, or a store-only crash appears. If crashes are already blocking TestFlight (Apple's beta testing) or Google Play internal testing, use our crash triage guide first. If your demo works but login, secret keys, or error handling are not ready for real users yet, start with our demo-to-production hardening guide, then use the sections below for Android and Apple / App Store steps; each links to the platform documentation we rely on.

Store-ready builds are not the same as test builds (Android)

Android Studio projects can be built in different modes (for example everyday test vs store-ready) that change packaging, compression, and signing. Google's build variants documentation describes those modes. If you only ever run a test build from the app editor, you have not yet exercised the same configuration Google Play users ultimately install.

• Test a store-ready build on a real phone before you treat the project as ready to upload.
• Code compression (for example R8), resource shrinking, and name shortening are typically enabled for store builds; Google's app optimization guidance says compression can remove unused code and files and that you should test thoroughly after enabling it.

Signing and upload format (Android / Google Play)

Play distribution expects you to manage signing keys according to Google's app-signing guidance (including Play App Signing when you use that program). For publishing format, Google's Android App Bundle (AAB) documentation states that, from August 2021, new apps are required to publish with an Android App Bundle on Google Play (with further notes on large apps and TV targets on the same page). Confirm your own app's track and target against that page because exceptions and timelines can change.

Saved builds and upload (Apple / App Store)

Apple documents a distribution workflow in Xcode: save a build, validate it, and upload for beta testing or App Store submission in its beta testing and release distribution documentation. Skipping validation or mixing test-only settings into an upload build is a common source of surprises compared with what ran on your phone during development.

Store rules you declare against (both platforms)

Google publishes a Developer Program Policies hub that applies to apps distributed on Google Play. Apple publishes the App Store Review Guidelines that apply to apps submitted to the App Store. Both documents are long; the point for this checklist is that your listing, permissions, data handling, and in-app behavior must line up with what you ship, not only with what worked in a demo environment.

Privacy and data declarations

On Google Play, developers complete a Data safety form describing data collection and sharing; Google documents that process in Play Console Help. On Apple platforms, privacy declaration files describe how your app and any third-party libraries use data and system features; Apple documents privacy manifest files in its developer documentation.

Required-reason APIs (Apple / App Store: a common vibe coding trap)

Separate from Apple's App Privacy questionnaire: Apple requires a privacy declaration file (PrivacyInfo.xcprivacy) for certain system features that could be misused to identify a device, even when you are not tracking users. For each category your app (or a bundled library) uses, you must list an approved reason code that matches real usage. Apple's required reason API documentation states that uploads missing those declarations are not accepted by App Store Connect (enforced since May 1, 2024; missing entries can also trigger email from Apple when you upload).

Common categories include saved user preferences, file timestamps, disk space, system boot time, and active keyboards. AI-assisted projects often use these in generated code but ship without a declaration file, or copy a generic file with reason codes that do not match what the app actually does. You are still responsible for every library that ships with your app, per Apple's 2024 privacy submission update. See Apple's TN3183 technical note for the full category list and file format (your developer or AI tool will need that detail).

• Find what your app uses: Search your project and dependencies for required-reason APIs. Xcode can surface gaps in its privacy report; third-party libraries need their own declaration files included in the upload.
• Declare each category: Each system feature category needs Apple-approved reason codes that match how your app actually uses it (not free-text explanations).
• Match reality: Reasons must reflect actual behavior and stay within Apple's allowed uses. Wrong codes are a common fix after an upload rejection about privacy declarations.

Generative AI inside the app (if that applies)

If your product includes user-facing generative AI features (for example a chatbot that creates content inside the app), Google Play maintains a separate policy area for AI-generated content that applies to those product categories, distinct from merely having used an assistant while writing code. Read the scope on that help page before you assume it applies to your app.

When the checklist is not enough

If you have walked the items above and you are still blocked: repeated review messages you cannot map to a change, store-only crashes, or no capacity to turn a fast prototype into something maintainable; that is work we take on: inherited projects, store readiness, and resubmission support. Nobody can promise a particular review outcome; we say the same on our mobile app development page and repeat it here: we focus on a methodical diagnosis and fixes you can ship.