To publish a vibe-coded app, you need more than a working AI preview. You need a production product, a reliable phone experience, developer accounts, app identity, store assets, privacy information, reviewer access, and tested iOS and Android builds. Most web-first apps can reach both stores without a full native rewrite, but the packaging step cannot finish an incomplete product for you.
This checklist is for creators who built with Lovable, Bolt, Replit, Base44, v0, Cursor, Claude Code, Bubble, or a similar AI or no-code tool and are now asking: “What am I missing before this can become a real mobile app?”
The short vibe-coded app publishing checklist
Before submitting to either store, confirm all ten items:
- The app is a real product, not only a preview. New users can complete its main task with persistent data.
- It runs at a stable production URL. The app does not depend on your builder session or a temporary preview domain.
- It works comfortably on phones. Navigation, forms, keyboards, uploads, and error states have been tested on small screens.
- You control the important accounts. Your business owns the domain, builder project, backend, Apple account, and Google Play account.
- The app has a final identity. Name, icon, colors, support contact, iOS Bundle ID, and Android package name are decided.
- Privacy and account controls are ready. Users can understand data use and request account deletion when accounts are offered.
- The store pages match the product. Descriptions and screenshots show features that actually exist.
- Reviewers can enter the app. A working demo account and clear instructions bypass normal invite or approval bottlenecks.
- Installable builds have been tested. TestFlight and a Google Play testing track expose problems a browser preview cannot.
- The first release is deliberately small. Unfinished actions are removed, and version one delivers one complete promise.
If several items are “not yet,” that does not mean the idea needs a native rebuild. It means the product or release preparation needs another pass before submission.
1. Confirm what your AI builder produced
Start by identifying the output, because “AI app” does not describe a technical format.
| What the project does today | What you probably have | Route to mobile stores |
|---|---|---|
| Opens from a normal HTTPS link | A web app | Package the production web app inside iOS and Android projects |
| Runs only inside a clickable editor preview | A prototype | Finish and deploy the real product first |
| The builder explicitly created Expo or React Native code | A native mobile project | Follow that framework's build and submission workflow |
| Users can add it from a browser to the Home Screen | A web app or PWA | Keep browser installation, or package it for normal store listings |
Most vibe-coded projects are web apps. That can be an efficient foundation for mobile because the interface, accounts, database, and backend can remain shared across the website, iPhone app, and Android app.
Do not ask the AI to “convert everything to Swift” simply because you want an App Store listing. First determine whether the existing mobile web experience already solves the user problem. A native shell may be enough; a full rebuild is justified only when core requirements cannot work well through the web-first product.
2. Finish one real user journey
Store reviewers and customers do not grade the quality of the original prompt. They open the product and try to complete a task.
Write the app's main promise as a sentence: “A customer can book an appointment,” “A team can approve an expense,” or “A student can create and review flashcards.” Then complete that journey as a brand-new user on a phone.
The journey is not ready if it relies on:
- sample records that reset after the preview;
- buttons that display a success message without doing the work;
- manual database changes by the creator;
- an admin approval step nobody will monitor;
- emails, uploads, payments, or invitations that work only in test mode;
- instructions that exist only in your head.
Remove secondary features until the main promise works from beginning to end. A small complete app is easier to explain, test, and review than a large generated interface with hidden dead ends.
3. Move from preview to production
A store app should load the production product, not a disposable builder preview. Use a stable HTTPS domain that you control and confirm that the backend, authentication, files, and external services use their production configuration.
Test in a private browser window where you are not signed into the builder. Create an account, close the browser, return later, and verify that the data persists. Check password recovery, email delivery, invitations, and any scheduled actions. If the product cannot survive outside the editor, mobile packaging will reproduce that weakness inside an installed app.
Keep access to the builder and hosting account, but avoid making the business dependent on one person's login. Record where the domain, database, email service, analytics, and other critical services are owned.
4. Test the phone experience before packaging
Responsive design means the page fits a screen. Mobile readiness means the whole task remains easy while someone is holding a phone.
Check the app on at least one iPhone-sized screen and one Android-sized screen:
- Can users understand the first screen without zooming?
- Are primary buttons easy to tap and visible above the keyboard?
- Do long names, tables, dialogs, and menus fit?
- Does a form keep its answers after a validation error?
- Are loading, empty, offline, and failure states useful?
- Do login, logout, password reset, uploads, and external links work?
- Can a user recover after denying a camera or notification request?
- Does the back action behave predictably?
Give two people a goal instead of a tour: “Create an account and book Thursday at 10.” Do not explain the interface. Their questions reveal missing product design more accurately than another generic “make this mobile-friendly” prompt.
5. Create the developer accounts early
The store accounts should belong to the person or organization that owns the product, not a temporary freelancer or packaging provider.
For iOS distribution, enroll in the Apple Developer Program and use App Store Connect to manage the app record, TestFlight builds, store information, and review. For Android, create the appropriate personal or organization Play Console account and complete identity verification.
Account setup can require legal identity, organization, contact, or business information. Google notes that organization verification can take time and requires verified contact details; prepare it before the app is otherwise ready. Review the current Google Play developer-account requirements instead of waiting until launch day.
New personal Google Play accounts created after November 13, 2023 must also satisfy Google's pre-production testing requirement before applying for production access. The current rule calls for at least 12 testers continuously opted into a closed test for 14 days. See Google's testing requirements.
6. Decide the app identity once
Prepare a simple identity pack that both mobile projects and store pages can use:
Visible identity
- Final app name
- Square high-resolution icon
- Launch-screen color or artwork
- Short value proposition
- Support email and public support page
Store identity
- iOS Bundle ID
- Android package name
- App category
- Copyright or publisher name
- Countries or regions for the first launch
The Bundle ID and package name are stable technical identities even though users rarely see them. Choose values connected to a domain or brand you control and avoid temporary builder names. Do not create a second store record because a build used the wrong identifier; align the project and record before the first upload.
If Apple's identifiers are confusing, the Team ID, Bundle ID, App ID, and SKU guide explains which value belongs in each place.
7. Prepare privacy and account deletion
AI builders can connect authentication, databases, analytics, and external services quickly. The store privacy answers must describe what the finished product actually does across all of those systems—not what the original prompt intended.
Prepare:
- a public privacy policy written for the real product;
- an inventory of personal data collected by the web app, mobile shell, and third-party services;
- a reason for every requested phone permission;
- an in-app account-deletion path when users can create accounts;
- any required external deletion page or support process;
- accurate Apple App Privacy and Google Play Data safety answers.
Google's account-deletion policy requires an in-app deletion path and associated data handling when an app enables account creation. Apple also requires account deletion from within apps that support account creation, subject to its documented exceptions. A “contact us someday” placeholder is not a finished deletion experience.
Do not copy another app's privacy answers or ask the AI to invent them. Inspect the services the product uses and answer from evidence.
8. Create store assets from the real app
The store page should explain the outcome, not the technology used to build it. Most customers do not need to know that the product was vibe-coded, uses a WebView, or started in Lovable.
Prepare for each store:
- a clear app name and short description;
- a longer description focused on audience, problem, and main benefits;
- screenshots from the actual submitted experience;
- icon and any required promotional artwork;
- privacy-policy and support URLs;
- category, age or content answers, and availability;
- release notes that describe the version honestly.
Avoid screenshots of mockups that contain features the build does not include. Google explicitly advises that the listing must deliver what it promises and recommends a clear, comprehensive description in its publishing guidance.
9. Give reviewers a reliable path through the app
If login hides any feature, create a reusable review account with realistic content. Test it from a clean device and make sure it will remain active throughout review.
Your review notes should explain:
- how to sign in;
- where to find the core workflow;
- how to reach features that require a particular role or state;
- what to do if an email, location, or permission is involved;
- why the app requests any capability that is not immediately obvious.
Do not require the reviewer to create a paid account, wait for your manual approval, enter an expiring one-time code, or contact support. Apple requires review contact and demo-account information where applicable, as described in its App Review details reference. Google likewise warns that missing credentials can prevent review.
10. Test the installable build, not only the website
The website working in Safari or Chrome does not prove the installed app is ready. Test the release candidate through TestFlight on iOS and a Play Console testing track on Android.
Repeat the main workflow after:
- a fresh install;
- denying optional permissions;
- closing and reopening the app;
- leaving the app during login or upload;
- losing and restoring the network;
- receiving an external link or notification, if supported;
- signing out and resetting the password.
Check that the app has no browser-only instructions, accidental external tabs, debug menus, builder branding, sample content, or blank screens. Ask testers to report the exact screen and action rather than saying only “it doesn't work.”
Apple uses TestFlight to distribute beta builds before App Review, while Google provides internal, closed, and open testing tracks. Testing is part of the release, not a ceremony after development.
What your vibe-coding tool does not automatically provide
| The AI builder may provide | You still need for store release |
|---|---|
| Screens and responsive layout | Real-device testing and installed-app behavior |
| Authentication and database connections | Production configuration, privacy answers, and deletion |
| A published URL | iOS and Android projects with stable app identities |
| Generated icons or copy | Final store-quality assets and accurate metadata |
| A working browser demo | Signed builds, beta distribution, and reviewer access |
| Rapid feature generation | A controlled release scope and long-term product ownership |
The builder creates or helps create the product. It does not remove Apple and Google's release responsibilities. A managed packaging workflow can reduce the native setup, but you remain responsible for the product, accounts, privacy, content, and promises made to users.
Are you ready to package the app?
| Status | What it means | Next action |
|---|---|---|
| Ready | Core journey, production URL, mobile UX, privacy, ownership, and assets are complete | Package and begin beta testing |
| Almost ready | Product works, but support, deletion, screenshots, or review access is missing | Finish release materials before submission |
| Prototype | Data is simulated, flows are incomplete, or the app works only in the builder | Finish the web product before mobile packaging |
| Needs specialist review | Sensitive data, regulated activity, complex payments, or unusual permissions are central | Get appropriate legal, security, or platform guidance |
Packaging too early creates a mobile version of the same unfinished product. Waiting for perfection creates a different problem. The right moment is when one valuable workflow is complete, safe, explainable, and testable.
Vibe-coded app publishing FAQ
Can a vibe-coded app be published on the App Store?
Yes. Apple reviews the finished app, not whether AI helped build it. A web-first product needs an iOS project, complete store information, privacy answers, testing, reviewer access, and enough utility to meet the review guidelines.
Can a vibe-coded app be published on Google Play?
Yes. It needs an Android project and signed App Bundle, a complete Play Console listing, policy declarations, testing, and a stable product that delivers the functionality described.
Do I need to rebuild my Lovable or Bolt app in React Native?
Usually not. If the published web app works well on phones, it can often remain the product while a native shell provides the iOS and Android store layer. Rebuild only when core requirements demand deeper native behavior.
Can I submit an AI builder preview URL to an app store?
No. Apple and Google review installable app builds, not a website URL. Use a stable production product as the content behind the mobile projects; do not base the release on a temporary editor preview.
What should I prepare before converting my web app?
Prepare the production URL, final name, icon, support contact, privacy policy, account-deletion flow, developer accounts, working reviewer credentials, and a complete core workflow tested on phones.
Do I need Apple and Google developer accounts?
Yes, if you want to publish under your own ownership in both stores. Create the accounts in the correct personal or organization name and complete verification early.
Will the stores reject an app because it uses a WebView?
Not automatically. Risk comes from limited utility, broken behavior, inaccurate metadata, privacy problems, or a thin experience that does not feel credible as a mobile app. The final product matters more than the AI builder used.
How many features should version one include?
Include the smallest set that completes the app's main promise safely and reliably. Remove unfinished options. One clear workflow with strong mobile behavior is better than many generated screens that reviewers cannot complete.
Can I keep updating the app through my AI builder?
Yes, when the installed app uses your production web product. Normal web changes can continue through the builder and hosting workflow. Native capabilities, permissions, icons, or project configuration may require another store build.
Official publishing references
- Apple: App Store Connect workflow
- Apple: Submit an app for review
- Apple: App Review Guidelines
- Google Play: Helpful publishing tips
- Google Play: Developer-account requirements
- Google Play: Testing requirements for new personal accounts
Continue your vibe-coded mobile launch
Turn your vibe-coded product into an iOS and Android app
WebNativeApp packages a production web app into mobile projects while you keep the product, publishing accounts, and source code. Bring the working URL, complete the checklist, test the installable builds, and launch without recreating the entire app in native code.