A practical, step-by-step guide to going from a single Rork prompt to a working app running on your real iPhone via Expo Go.
This guide walks you from an empty Rork project to a tappable app on your iPhone. The goal is a working preview, not a finished App Store release.
You'll need a Rork account, an iPhone, and the free Expo Go app from the App Store. A stable Wi-Fi network helps, because preview relies on your phone reaching the project over the network.
No Mac or Xcode is required just to preview. That comes later if you decide to build and submit.
Set expectations up front. The first generation gives you a starting point, and you'll refine it through several prompt iterations rather than expecting perfection on attempt one.
Your first prompt sets the foundation, so be specific about the app's purpose and core screens. Vague prompts produce vague apps.
Name the app's job in one sentence, then list the main screens. For a habit tracker, you might describe a home screen with today's habits, an add-habit screen, and a simple stats screen.
Mention the navigation style you want, such as a bottom tab bar. React Native apps commonly use tab or stack navigation, and naming it helps Rork structure the project sensibly.
Avoid cramming every feature into the first prompt. Establish the skeleton first, then layer detail in later iterations.
It also helps to describe the kind of data each screen shows, even loosely. Saying a habit has a name, a streak count, and a done state gives Rork enough to scaffold sensible components instead of guessing.
Once Rork generates the app, look at the structure before adding more. Confirm the screens you asked for exist and that navigation connects them.
Because Rork builds on React Native and Expo, the output will feel familiar if you've used either. You'll see components, screens, and navigation rather than native Swift files.
Read a little of the code even if you plan to mostly prompt. Understanding what was generated makes your follow-up prompts far more effective.
If something is structurally wrong — a missing screen or broken navigation — fix it now with a focused prompt before you build on top of it.
A quick structural pass at this stage pays off repeatedly. Every later prompt builds on this foundation, so correcting the skeleton early is far cheaper than untangling it after ten iterations.
Download Expo Go from the App Store on your iPhone. It is free and runs Expo projects without you compiling anything yourself.
Sign in or create an Expo account if prompted. Keeping your phone and your Rork session reachable on the same network avoids the most common connection issues.
Expo Go is essentially a host that loads your JavaScript bundle. That's why you can preview instantly: there's no native compile step for this stage.
Keep Expo Go updated. An outdated client can be incompatible with the Expo SDK version your project targets.
From Rork, open the preview option and connect it to Expo Go, typically by scanning a QR code or opening a link. Your project then loads on the phone.
The first load takes a moment while the bundle downloads. After that, changes you make refresh quickly.
Tap through every screen. You're checking that the flows behave the way they read in the prompt, not just that the app opens.
If the app fails to load, the usual culprits are network mismatch or an Expo SDK version gap. Resolve connectivity first before assuming the code is broken.
Now refine. Change one thing at a time so you can tell what each prompt did.
Good iteration prompts are concrete: 'add a delete button to each habit row' beats 'make the list better.' Specific requests produce predictable diffs.
Reload in Expo Go after each change and verify on-device. The tight loop between prompt and real-iPhone preview is the whole point of this workflow.
When a change makes things worse, revert or re-prompt rather than stacking fixes on top of a bad state. Clean iterations keep the project maintainable.
Once the UI feels right, move to behavior. Ask Rork to persist data, handle form input, or wire up basic state.
For many apps this is where you connect a backend or local storage. Describe the data shape clearly — what a habit record contains, for example — so the generated logic matches your model.
Test edge cases on the phone, not just the happy path. Empty states, long text, and rapid taps reveal problems that a single demo run hides.
This is also where you should start reading the generated code seriously. Data and logic are where AI output most needs human review.
When the preview app is solid, export the code so you own it outside Rork. Because it's a standard Expo project, it drops into a normal React Native workflow.
From here, an App Store release uses Expo Application Services (EAS) to produce a signed iOS build. That step requires an Apple Developer Program membership.
This is the boundary Rork doesn't cross for you. Compiling, signing, and submitting are the standard Apple pipeline, and they happen after export.
Plan that work as its own phase. The preview proves the idea; EAS and App Store Connect turn it into a shippable product.
Keep prompts small and sequential. A series of focused requests almost always beats one giant prompt.
Preview on a real device early and often. Simulated impressions miss touch behavior, performance, and layout quirks that only show on hardware.
Version your progress. Export or save known-good states so a bad iteration doesn't cost you the whole project.
Finally, separate prototyping from production in your head. Rork gets you to a working iPhone preview fast; the polish, testing, and submission are real engineering you still own.
The most common early mistake is judging the app from a simulator screenshot instead of your hand. Touch targets, scrolling, and keyboard behavior only feel right on a real phone.
Another is over-prompting. When you ask for five changes at once and one breaks, you can't tell which request caused it, so progress stalls.
Watch for prompts that quietly contradict earlier ones. Asking for a tab bar and later a drawer in the same app can leave the navigation in a confused state.
Finally, don't skip reading the code just because prompting is fast. A two-minute look at the generated logic often prevents an hour of confused re-prompting later, and it keeps the project something you can actually maintain after export.
No. Previewing through Expo Go runs on the phone without compiling, so no Mac or Xcode is needed for this stage. A Mac and EAS come into play when you build for the App Store.
The most common causes are your phone and project not being reachable on the same network, an outdated Expo Go app, or an Expo SDK version mismatch. Fix connectivity and update Expo Go first.
Specific about purpose and core screens, but not exhaustive. Establish the skeleton and navigation first, then add features through later iterations.
Yes. Rork supports code export, and because it's a standard React Native + Expo project you can continue in your own editor and toolchain.
You export the project and use Expo Application Services (EAS) plus an Apple Developer Program membership to build, sign, and submit an iOS app to the App Store.