Step-by-step on taking a Rork-generated React Native project through code export, an EAS iOS build, and App Store Connect submission with your Apple Developer account.
Rork gets you to a working app fast, but the App Store has its own non-negotiable requirements. This guide covers the bridge between the two.
The short version: export your code, build a signed iOS binary with EAS, and submit through App Store Connect. None of those steps happen inside Rork.
That's not a flaw — it's how every Expo-based app reaches the store. Rork hands you a standard project, and the standard Apple pipeline takes it from there.
Before you start, accept that this phase is real engineering and account setup, not prompting. Budget time accordingly.
Don't export the moment the demo works. A prototype and a submittable app are different things.
Test core flows on a real iPhone, check empty and error states, and confirm the app behaves without a debugger attached. Apple reviewers test the shipped build, not your demo.
Review the AI-generated code for anything that shouldn't ship: placeholder text, unused permissions, or hard-coded test data. Apple scrutinizes permission usage in particular.
If your app collects data, prepare an honest privacy description now. You'll need it for App Store Connect's privacy questionnaire.
Use Rork's code export to get the full React Native + Expo project onto your machine. This is the moment the app becomes truly yours.
Once exported, treat it like any Expo project. Install dependencies, run it locally, and confirm it starts cleanly outside Rork's environment.
Put the project under version control immediately. Git gives you a safety net before you start making release configuration changes.
Verify the app still runs after export. If it works in Rork's preview but not locally, resolve that before going near a build — the build will only amplify existing problems.
You cannot submit to the App Store without an Apple Developer Program membership. It's a paid annual enrollment with Apple.
Enroll as an individual or an organization. Organization enrollment requires a D-U-N-S number and typically takes longer, so start early if that's your path.
Inside App Store Connect, you'll later create the app record, set its bundle identifier, and manage builds. Choose a unique bundle ID that matches your project configuration.
This account is also where signing identities live. EAS can manage much of the signing for you, but the account must exist and be active first.
Open your Expo app configuration and set the iOS essentials: app name, bundle identifier, version, and build number.
Declare any permissions your app uses with clear, honest usage strings. iOS requires a human-readable reason for camera, location, photos, and similar access, and Apple rejects vague or missing descriptions.
Add your app icon and splash screen at the required resolutions. A missing or low-quality icon is an easy, avoidable rejection.
Double-check that the bundle identifier here matches the one in App Store Connect. A mismatch is a frequent cause of upload failures.
Expo Application Services (EAS) is the standard way to produce a signed iOS build from an Expo project. It runs the native compile in the cloud, so you don't strictly need a local Mac toolchain.
Initialize EAS in your project and start an iOS production build. During setup, EAS can generate and manage your signing credentials against your Apple Developer account.
The build produces an .ipa, the installable iOS package. This is the artifact you'll submit.
If the build fails, read the logs carefully. Most first-build failures are configuration issues — bundle ID, credentials, or a missing native dependency — not mysterious errors.
With a successful build, submit it to App Store Connect. EAS Submit can upload the binary directly, or you can upload manually.
In App Store Connect, complete the listing: screenshots, description, keywords, category, and age rating. These are required before you can submit for review.
Fill out the privacy section truthfully based on what your app actually collects. Inaccurate privacy answers cause rejections and erode user trust.
Then submit for review. Apple's review takes time and can request changes, so don't schedule a launch announcement for the same day you submit.
App Review may approve your build or send it back with specific reasons. Read rejection notes literally — they usually cite a guideline.
Common issues include unclear permission usage, broken flows the reviewer hit, or missing demo credentials for a login. Address the exact point raised, then resubmit.
Keep a test account ready if your app has authentication. Reviewers need a way in, and not providing one is a frequent, avoidable rejection.
Iterate calmly. Even hand-built native apps get rejected on first submission; it's a normal part of the process, not a sign your Rork app is flawed.
Be clear on the division of labor. Rork produces the app and lets you export it; everything from EAS build onward is the standard Apple and Expo pipeline.
That means the responsibility for signing, privacy accuracy, and guideline compliance is yours, not the AI's. No app builder takes on Apple's requirements for you.
The upside is portability. Because the output is a normal Expo project, you're never locked into Rork to ship or maintain the app.
Approach this phase as the engineering it is. The reward is a real, signed iOS app on the App Store built from an idea you prototyped in a fraction of the usual time.
It helps to plan this phase honestly so you aren't surprised. The export itself is quick, but the surrounding setup is where time actually goes.
Apple Developer enrollment can clear in a short time for individuals, while organization enrollment with a D-U-N-S number can take noticeably longer. Start it before you need it.
The first EAS build and the first round of credential setup almost always take more than one attempt. Budget for a few iterations rather than expecting a clean run.
App Review itself adds its own wait, and a rejection-and-resubmit cycle extends it further. The practical lesson is simple: treat the export-to-store phase as days, not minutes, and don't promise a launch date you can't control.
Shipping once is not the end. Apps need updates for bug fixes, new features, and to keep pace with new iOS versions Apple releases each year.
The good news is that subsequent releases follow the same path you've now learned: change the code, bump the version and build number, build with EAS, and submit. The first trip is the hard one.
Keep your project under version control and your credentials organized, because future-you will thank present-you when a quick fix needs to ship.
Because the exported project is standard React Native and Expo, you can keep iterating in Rork for new screens or move fully into your own editor — the choice stays yours, and the maintenance path never depends on the original builder.
No. Rork generates and exports the project, but submission uses the standard pipeline: an EAS iOS build, App Store Connect, and an Apple Developer Program membership.
Not necessarily. EAS runs the iOS build in the cloud and can manage signing, so you can produce a signed binary without a local Mac toolchain, though a Mac is still useful for some workflows.
Unclear or missing permission usage strings, broken flows the reviewer encountered, and not providing demo login credentials are among the most frequent and avoidable causes.
Beyond your Rork subscription, you need an annual Apple Developer Program membership, and EAS builds may have their own costs depending on volume. Check the official pricing pages.
Yes. It's a React Native project on the Expo runtime, so it works with normal Expo tooling, EAS, and your own editor and version control.