Vibe Coding, Meet Store Reality

Published May 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 release build that survives Google Play or App Store Connect without signing surprises, wrong artifacts, or policy mismatches.

Neither store reviews the debug build you run from Xcode or Android Studio. Google Play expects a signed release artifact (typically an Android App Bundle); the App Store expects an archive you validate and distribute through App Store Connect. Both require declarations that match real data use: Play's Data safety form, Apple's privacy manifests (including required-reason APIs on iOS), and behavior that matches your 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 release-only crash appears. The sections below cover Android and iOS; each links to the platform documentation we rely on.

Release builds are not the same as debug builds (Android)

Android Studio projects use build types (for example debug and release) that can change packaging, optimization, and signing; Google's build variants documentation describes those variants in the Android Studio build overview. If you only ever run a debug build from the IDE, you have not yet exercised the same configuration Play users ultimately install from a release pipeline.

• Test a release build locally before you treat the project as store-ready.
• Code shrinking (for example R8), resource shrinking, and minification are typically enabled for release; Google's app optimization guidance says shrinking can remove unused code and resources 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 documentation states that, from August 2021, new apps are required to publish with the 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.

Archives and distribution (iOS)

Apple documents a distribution workflow in Xcode: archive, validate, and distribute builds for beta testing or App Store submission in its beta testing and release distribution documentation. Skipping validation or mixing debug-only settings into a distribution archive is a common source of surprises compared with what ran on a developer device.

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, third-party SDK and app privacy manifests are part of how you declare API and data use; Apple documents privacy manifest files in its developer documentation.

Required reason APIs (iOS: a common vibe-coding trap)

Separate from the App Privacy questionnaire: Apple requires a PrivacyInfo.xcprivacy entry for certain system APIs that can be misused for fingerprinting, even when you are not tracking users. For each category your app (or an embedded SDK) touches, 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).

Categories include APIs teams hit constantly in everyday Swift: for example NSPrivacyAccessedAPICategoryUserDefaults (UserDefaults) and NSPrivacyAccessedAPICategoryFileTimestamp (file timestamps), along with disk space, system boot time, and active keyboards; see Apple's TN3183 for the full list and XML/plist shape. AI-assisted projects often call these APIs in generated code but ship without a manifest, or copy a generic manifest with reason codes that do not match what the binary actually does. You are still responsible for every framework and SDK that links in, per Apple's 2024 privacy submission update.

• Inventory usage: Search your app and dependencies for required-reason APIs (Xcode can surface privacy report gaps; third-party SDKs need their own manifests merged into the upload).
• Declare each category: In NSPrivacyAccessedAPITypes, set NSPrivacyAccessedAPIType to the category and NSPrivacyAccessedAPITypeReasons to one or more Apple-approved codes for that category (not free text).
• Match reality: Reasons must reflect actual behavior and stay within Apple's allowed uses; wrong codes are a common fix after an ITMS / privacy-manifest rejection.

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, release-only crashes, or no capacity to turn a fast prototype into something maintainable; that is work we take on: inherited codebases, release 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.