A step-by-step guide to taking a React Native app generated by a0.dev and shipping it to the iOS App Store using Expo Application Services (EAS) Build and Submit, plus the Apple Developer Program requirements you cannot skip.
This guide takes a React Native app generated by a0.dev and walks it through to the iOS App Store using Expo's EAS pipeline.
The key idea is that a0.dev produces a standard Expo project, so release follows the normal Expo path. There is no proprietary or special release channel to learn.
That path has three big pieces: building a native binary with EAS Build, submitting it with EAS Submit, and completing Apple's review process in App Store Connect.
Because each of these has official documentation that stays current, use this guide as a map and rely on Expo's and Apple's docs for the exact commands and screens.
Before building for the App Store, you need an Apple Developer Program membership. This is a paid annual enrollment and is mandatory for App Store distribution.
You also need your a0.dev project exported or accessible as an Expo project on your machine, with Node.js and the EAS CLI installed.
Have your app config in order. Your iOS bundle identifier must be set and unique, and your app name, icon, and version should be finalized before you build.
Finally, make sure the app actually works. Apple reviews for functionality and completeness, so a half-finished prototype straight out of generation is likely to be rejected.
Start by installing the EAS CLI and logging into your Expo account. This is the tool that orchestrates cloud builds and submissions.
Run EAS configuration in your project directory. This creates an eas.json file that defines build profiles, typically including a production profile for App Store builds.
Review the generated build profiles. For iOS App Store release you want a production profile that produces a distributable binary, not a development or internal build.
If your a0.dev app relies on environment variables or secrets, configure those in EAS so they are available at build time rather than hardcoded in the repo.
iOS builds must be code-signed with an Apple distribution certificate and a provisioning profile. EAS can manage these for you, which is the simplest path.
When you run a build, EAS can generate and store the necessary certificates and provisioning profiles using your Apple credentials. This automated flow removes most of the manual keychain and portal work.
Alternatively, you can supply your own credentials if your organization requires manual control. Expo documents both approaches clearly.
Get this right early. Signing problems are one of the most common causes of failed iOS builds, and letting EAS manage credentials avoids many of them.
With configuration and credentials in place, trigger a production iOS build through EAS Build. This compiles your React Native app into a native binary in the cloud.
The build runs on Expo's infrastructure, so you do not strictly need a Mac. You can monitor progress from the terminal or the Expo dashboard.
Builds take time and can fail for real reasons — a missing native dependency, an invalid bundle identifier, or a permissions misconfiguration. Read the logs carefully when they do.
Once the build succeeds, EAS gives you a downloadable artifact and a record in your project. This binary is what you submit to Apple.
EAS Submit uploads your finished build to App Store Connect. This replaces the older manual upload workflow for most Expo projects.
You provide your Apple credentials or an App Store Connect API key so EAS can push the binary to the right app record. Using an API key is the recommended, more automatable approach.
After submission, the build appears in App Store Connect under your app's TestFlight and versions sections. It may take some time to finish processing on Apple's side.
Confirm the build shows up and finishes processing before moving on. You cannot submit for review until Apple has a processed build attached to your version.
A build alone is not enough. Apple requires complete metadata before review, and this is where many first-time releases stall.
Fill in your app name, subtitle, description, keywords, category, and support URL. Prepare screenshots at the required device sizes — Apple is strict about these.
Complete the App Privacy section honestly. You must declare what data your app collects and how it is used, and this must match your app's actual behavior.
Set your pricing and availability, and provide any required review notes or demo account credentials if your app has a login. Missing demo access is a frequent rejection cause.
With a processed build and complete metadata, submit for App Review. Apple's reviewers check functionality, compliance with the guidelines, and privacy accuracy.
Review times vary. Plan for the possibility of a rejection, especially on a first submission, and do not schedule a hard launch date that assumes instant approval.
If rejected, Apple provides a reason. Common ones for AI-generated apps include incomplete features, placeholder content left in, missing privacy strings, or metadata that misrepresents the app.
Address the specific feedback, increment your build if needed, and resubmit. Once approved, you control when the app goes live according to your release settings.
The most common failure is shipping something unfinished. A freshly generated a0.dev app with mock data and empty states will likely be rejected as incomplete — polish it first.
Signing and credential errors are next. Letting EAS manage credentials, and keeping your bundle identifier consistent everywhere, prevents most of these.
Privacy declarations trip up many teams. If your app requests camera, location, or tracking, you need matching usage descriptions in your config and accurate answers in App Privacy.
Finally, remember the moving parts have their own docs and pricing. Verify EAS build limits and Apple's requirements against official sources, since both evolve independently of a0.dev.
Before submitting for public release, take advantage of TestFlight. A build you push through EAS Submit can be distributed to internal and external testers first.
This step catches problems that neither the preview nor a simulator reveals: real network conditions, real permission prompts, and behavior on the specific devices your testers own.
Invite a handful of testers, give them a short script of what to try, and collect feedback before you commit to App Review. Fixing issues now is far cheaper than fixing them after a rejection.
TestFlight also lets you validate that your build actually installs and launches from Apple's infrastructure, which is a meaningful signal that your signing and configuration are correct.
Shipping version one is not the end. Every update follows the same EAS Build and Submit path, so it is worth establishing a repeatable process early.
Increment your version and build numbers consistently. Apple requires a new build number for each upload, and a clear versioning scheme prevents confusion across releases.
Keep your credentials, bundle identifier, and app config stable between releases. Changing them unnecessarily reintroduces the same signing and matching problems you solved the first time.
Treat each release as a small repeat of this workflow: build, submit, complete any metadata changes, and review. Once you have done it once, subsequent updates are considerably faster.
Not necessarily. EAS Build compiles iOS binaries in the cloud and EAS Submit uploads them, so you can release without a local Mac. A Mac with Xcode is still helpful for debugging and local testing.
Yes. App Store distribution requires a paid Apple Developer Program membership. There is no way to publish a public App Store app without it, regardless of the tool used to build the app.
Yes. EAS can generate and manage your distribution certificate and provisioning profile using your Apple credentials, which avoids most manual signing problems. You can also supply your own credentials if required.
Common reasons include incomplete features, leftover placeholder content, missing privacy usage strings, or inaccurate metadata. Polish the app, complete the App Privacy section honestly, and provide demo credentials if it has a login.
It varies and Apple does not guarantee a fixed time. Plan for the possibility of a rejection and resubmission on your first release, and avoid committing to a launch date that assumes instant approval.