Vibecode builds the app, but shipping it to the App Store runs through Expo EAS and the Apple Developer Program. Here is the full step-by-step release path, from build to App Review.
Before touching any buttons, it helps to see the whole map. Vibecode produces a React Native/Expo project; getting it onto the App Store is a standard Expo workflow.
The pipeline is roughly: finalize the app, produce an iOS build with EAS, register it in App Store Connect, add metadata, and submit for App Review.
None of these steps are unique to Vibecode. They are the same steps any Expo app follows, which is good news because they are well documented.
The key mindset: the AI builder ends where the Apple pipeline begins. Plan time and budget for that handoff.
You cannot distribute on the App Store without a paid Apple Developer Program membership. This is an annual fee paid directly to Apple.
Enroll as an individual or an organization. Organization enrollment requires a legal entity and takes longer, so start early if you need it.
Once enrolled, you gain access to App Store Connect and the certificates and identifiers your build will need.
This membership is separate from any Vibecode or Expo cost. Budget for all three parts of the stack.
Every iOS app needs a unique bundle identifier, an app name, and an icon. Decide these before building so you do not rebuild later.
Set a stable bundle identifier in your Expo config. Changing it after release effectively creates a new app, so choose carefully.
Prepare a high-resolution app icon and any required launch assets. Ask Vibecode to help generate placeholders, but review them against Apple's guidelines.
Also gather screenshots, a description, keywords, and a privacy policy URL. App Store Connect will require these, and having them ready avoids a stalled submission.
Open the project Vibecode generated and confirm the app configuration is release-ready. Check the app name, bundle identifier, version, and build number.
Set a version string and an initial build number. Every upload to App Store Connect needs a unique build number, so plan to increment it.
Review permissions. If your app uses the camera, location, or notifications, iOS requires usage-description strings, or the app can be rejected or crash on request.
Double-check any API keys or backend URLs are configured for production, not a local development environment.
EAS Build is Expo's cloud service for compiling installable binaries. For iOS you will produce a build suitable for the App Store.
Run an iOS production build through EAS. It will handle the native compilation you would otherwise do in Xcode.
Code signing is the step that trips people up. EAS can manage certificates and provisioning profiles for you, or you can supply your own; either way your Apple credentials are involved.
When the build completes, you get an artifact ready to upload. If it fails, read the build logs carefully, because most failures are signing or configuration issues, not code.
With a build in hand, create your app record in App Store Connect using the same bundle identifier.
Upload the build. EAS can submit directly to App Store Connect, or you can upload the artifact manually. Either way, the build must appear in your app record before you can submit.
Fill in all metadata: description, screenshots, category, age rating, and privacy details. Apple's privacy questionnaire is mandatory and should reflect what your app actually collects.
Then submit for review. Consider using TestFlight first to test the exact production build with real users before going live.
App Review is a human and automated evaluation against Apple's guidelines. AI-generated apps are held to the same standards as any other.
Common rejection reasons include missing privacy policies, broken features, placeholder content, and thin apps that do not offer enough value. Ship something complete, not a demo.
Make sure every advertised feature actually works and that you have removed placeholder text and dummy data.
If rejected, read the resolution center notes, fix precisely what is cited, increment the build number, and resubmit. Rejections are routine, not the end.
Before you commit to a launch date, add up every part of the stack so there are no surprises.
There is the Apple Developer Program, an annual fee paid directly to Apple. There may be a Vibecode subscription depending on your plan and usage.
There can also be Expo EAS build usage, which depends on how many cloud builds you run. Confirm current amounts on each provider's official site rather than assuming.
Time is a cost too. Metadata, screenshots, a privacy policy, and App Review all take real hours. Planning for them up front prevents a stalled submission at the finish line.
TestFlight is Apple's beta distribution system, and it is the safest way to validate a build before the public sees it.
Upload your production build and invite testers. They install the exact binary you plan to ship, on their real devices, which surfaces issues a simulator never will.
Watch for crashes, permission prompts that fire at the wrong time, and features that behaved differently in preview. These are exactly the things that trigger negative reviews or rejections.
Only promote to the public App Store once TestFlight looks clean. A short beta pass is cheap insurance against a rocky launch.
The listing metadata is easy to underestimate, and an incomplete listing is a common reason submissions stall.
App Store Connect will ask for a name, subtitle, description, keywords, category, and a support URL. Draft these before you reach the submission screen.
Screenshots are required at specific device sizes, so plan to capture clean shots of your real screens rather than placeholders.
Apple also requires a privacy policy and a privacy questionnaire that accurately describes what data your app collects. Answer it honestly against what the app actually does, because mismatches draw review scrutiny.
Having all of this ready turns submission into a form-filling exercise rather than a scramble.
Two numbers trip up first-time publishers, so it is worth being clear on both.
The version string is the human-facing release number, like the one users see in the store. You bump it for meaningful releases.
The build number is the internal counter for each binary you upload. App Store Connect rejects a duplicate build number, so you must increment it on every new upload, even for the same version.
A simple habit is to raise the build number every time you send a build, and raise the version only when you ship a real update to users.
Getting this right avoids the frustrating late-stage error where a perfectly good build is refused simply because its number was already used.
Shipping once is not the finish line. Plan how you will push updates, because both Apple and Expo evolve.
For code and asset changes, you rebuild and resubmit, incrementing the build number each time. Some over-the-air update strategies exist in the Expo ecosystem, but store-reviewable changes still go through review.
Keep your Expo and dependency versions reasonably current. Falling far behind makes future builds and OS-compatibility fixes harder.
Finally, monitor crash reports and reviews. An AI-built app still needs an owner who maintains it after launch.
No. Release runs through Expo EAS, App Store Connect, and Apple's review. You need an Apple Developer Program membership and must complete the standard submission steps.
You can build in the cloud with EAS instead of local Xcode, but you still need Apple credentials, code signing, and App Store Connect.
You pay Apple's annual Developer Program fee, plus any Vibecode subscription and Expo EAS build usage. Confirm current amounts on the official sites.
Most iOS build failures are code signing or configuration problems, such as certificate/provisioning issues or a mismatched bundle identifier. Check the build logs first.
Yes. Use TestFlight to distribute the production build to testers before submitting for public App Store release.