The morning after I submitted an app for review, the screen said "In Review" and nothing else. I had spotted a typo the night before and couldn't fix it, because resubmitting would reset the clock.
As an indie developer who has run apps for a long time, I've learned that this waiting is not dead time. It sets the speed of the whole project: how slowly you can fix things is how slowly you can improve them.
That's where shipping a web version first comes in. What I'd like to say up front is that whether the option exists depends on which Rork plan you built with.
What the official pages say
Rork's FAQ describes the output of each plan.
| Plan | What it builds | Can it go on the web? |
|---|---|---|
| Rork Pro | An Expo app for iOS and Android | Yes. Rork doesn't host web apps, so you export and deploy to a provider such as Vercel or Netlify |
| Rork Max | A native SwiftUI iOS app | No. It's iOS-only and doesn't run on the web |
If you're on Rork Max, web-first isn't available to you, and the choice is the store or on-device testing. The rest of this article is for Rork Pro (Expo).
The export itself is short
Expo's documentation gives one command:
npx expo export -p webThe output goes to dist, and the contents of public/ are copied there. One trap: if you don't set web.output, it falls back to single, a single-page app with one index.html and no per-route HTML. If you want individual pages to be findable in search, you need static. Templates from SDK 58 onward use server, which only works on a host that supports Expo Router server rendering (the docs recommend EAS Hosting). Uploading just the client directory to a static host won't give you server rendering.
I read about these output modes only after my first export, which is the wrong order. Pick the host first, then export. That's the rule I keep.
For local testing, npx expo serve is HTTP only, so camera, location and other secure-context features may misbehave. A feature failing locally doesn't prove it's broken, and one working locally doesn't prove it will work in production.
Three questions that decide it
Does the core of the app work on the web? Tools centered on recording, calculating or displaying usually do. If your core is the camera, widgets, background work or push notifications, the web version becomes a different product. Expo's page doesn't list web-incompatible APIs, so check each feature in the reference.
Will your first users open a link? If you're showing it to friends or a small community, a URL is faster than a store listing. If you depend on people discovering the app in the store, a web version is only a rehearsal.
Is the store wait unavoidable? For a personal Google Play developer account created after November 13, 2023, Google's testing requirement asks for at least 12 testers opted in continuously for 14 days. That clock runs regardless of how good the app is.
| Situation | Suggested order |
|---|---|
| Built with Rork Max | Store (iOS); test on devices and with testers |
| Rork Pro, core is display or records, few intended users | Web first, then the store after you see reactions |
| Rork Pro, core is camera or notifications | Store from the start; keep the web as an explainer page |
| New personal Google Play account | Start recruiting testers early and gauge reactions on the web meanwhile |
The usual failure: leaving the web version as "temporary"
Once the web version is live, you'll find things to fix right away. That's good, but if porting the fixes to the store build waits, the two versions drift. Whenever the same app lives in two places, a fix lands in one and gets forgotten in the other. A web build adds one more place to check, and wording and price displays are the usual things left stale on one side.
When I plan a web release, I write the store release date on the same sheet. A temporary release without a deadline tends to stay temporary.
A small checklist before the first export
Before running the export, I write down three things on one page: where the files will be hosted, which web.output mode that host supports, and which screens in the app depend on a native-only feature. The third list is usually the shortest, and it's the one that saves the most time, because each item on it is a screen that will need a web-specific fallback or a plain "open this in the app" message.
If a screen can't work on the web, I'd rather show that message than let a half-working screen reach a first visitor. A first impression is hard to redo, and a web visitor who hits a broken camera screen rarely scrolls back up to see that the rest of the app was fine.
One next step
Check in your project whether the app is Rork Pro or Rork Max. If it's Max, you're done here. If it's Pro, pick the one of the three questions you're least sure about and answer only that today.
If you want to see which plan each stage needs, the plan comparison lays it out, and the publishing guide covers the store steps.