Can Rork Apps Go to Production? What to Check First

Rork can generate an app that reaches TestFlight, the App Store, or Google Play. Production evidence begins after the build succeeds: the shipped app must work on real devices, protect live data, survive failed requests, support account and payment obligations, and leave somebody able to reproduce and recover a release.

Is a Rork app production ready?

Short answer: yes, with conditions. Rork Pro and Rork Max both produce real, submittable apps in standard stacks, so the generated code is rarely what blocks a launch. A specific build is production ready once five things are true:

• The exact store binary works on real devices, not just in Rork’s App Preview.
• The backend enforces its own access rules, proved with a second account rather than assumed.
• Store metadata, privacy declarations, and purchase flows match the app you actually shipped.
• New features ship as a new binary where Apple requires one, not as an over-the-air update.
• Someone other than the original builder can rebuild, back up, and restore the release.

Rork’s own FAQ answers the question in one line: “Both Rork Pro and Rork Max produce production-ready code in industry-standard tech stacks.” That is a claim about the stack, and it is fair. The five conditions above are claims about your app, and only you can check those.

This article is a documentation-based production review, current as of August 5, 2026. It does not claim hands-on benchmarking of a Rork account or generated project. Rork changes quickly, so verify the linked product documentation again before submission.

What does Rork currently generate and publish?

Rork currently offers two materially different build paths. Rork Pro generates a cross-platform React Native and Expo project for iOS, Android, and web. Rork Max generates a SwiftUI Xcode project for Apple platforms. Both can publish to the App Store, while Android publishing applies to the Pro path.

Rork’s current product FAQ describes built-in App Store publishing. Its publishing documentation says Rork Pro needs both an Apple Developer account and an Expo account. For Pro, App Preview opens a shareable build through Expo Go or the Rork iOS app. Rork documents a different Max preview flow through its Mac companion app and a connected iPhone. Neither preview path is the store binary Apple reviews.

Rork’s FAQ is also direct about the wrapper suspicion these tools attract: “They are fully native apps. Rork Pro uses React Native and Expo, a production-grade framework that compiles to real native code, not web views,” and Rork Max “uses SwiftUI, Apple’s own native framework, compiled with Xcode.” That settles what the app is made of. It does not settle whether your build passes review, which is the rest of this post.

Rork Pro or Rork Max: which one are you shipping?

Write down which path the project uses before anything else. Expo-specific advice can be correct for Pro and irrelevant to Max. The same distinction matters for dependency upgrades, signing, crash reporting, over-the-air updates, and who can take over the code later.

Each path also carries its own list of things to verify before a release:

A working App Preview is not evidence about either list. The binary the stores review is a different artifact, produced by a different build step (EAS Build on the Pro side, Xcode on the Max side) with different configuration, and it has to be exercised through TestFlight or a Play testing track against production-like services.

What does it actually cost to get a Rork app live?

Two bills, not one. Rork charges for generation credits, and the stores charge for the right to publish at all.

Rork defines a credit as “a unit of AI compute, roughly one request where Rork builds or edits your app,” and unused credits do not roll over into the next month. That shape has a production consequence nobody advertises: debugging costs the same as building. A prompt that fixes a broken sign-in burns a credit exactly like the prompt that added it, so the last stretch of a launch, the part that is all rejected uploads, permission strings, and edge cases, is often the most expensive part of the project. Budget credits for the fixing, not just the building.

What must work on a real device before submission?

A Rork preview proves that the current flow can render in the preview environment. A release candidate needs the exact store build on the devices and operating-system versions your users will run.

Test the main workflow with production-like accounts and services:

Rork’s own App Store preparation guide tells builders to test before review and to inspect permission descriptions in app.json. A one-hour pass is a starting point. The release candidate should also cover the failure paths tied to money, identity, and saved data.

Every native capability the app touches is its own review artifact. Rork Max advertises HealthKit, HomeKit, ARKit and LiDAR, NFC, Dynamic Island, Live Activities, Siri actions, widgets, Screen Time, iMessage apps, background tasks, and 3D or body tracking. A capability can require an entitlement when Apple restricts it, a purpose string when the app requests protected data, or a privacy declaration when the app or an included SDK collects reportable data. Test the capabilities you actually shipped on a real device. Then check that every required entitlement, purpose string, and privacy answer describes the same behavior. A capability the app requests but never uses is worth deleting before review, not explaining after it.

What changes when a Rork app needs a backend?

Rork’s documentation says accounts, cross-device sync, shared data, file storage, and access rules require a backend. A local-only timer or journal can avoid that surface; an app with users, teams, payments, or private cloud data cannot.

The current choices include Rork Cloud, your own Supabase project, Firebase, or exported code connected to another service. Rork Cloud is documented as beta. It provides Postgres, row-level security, and server-side functions, and its database changes are live immediately with no separate preview step. Rork also says the backend can be transferred once to the owner’s Supabase organization while keeping its URL, data, and keys.

That beta boundary changes the release questions:

• Where do schema and policy changes get tested before they touch live data?
• Who owns the Supabase organization, Apple account, Expo account, source repository, and service credentials?
• What backup exists, and has a restore been rehearsed without overwriting the live project?
• Can a second account read or edit the first account’s rows?
• Which server functions can spend money, change subscriptions, or call private APIs, and what limits those calls?

For a Supabase-backed project, database and API tests for RLS should run before submission. Do not treat Rork’s generated access rules as proved until anon, user A, and user B have been tested against known fixtures.

Are your API keys really out of the app bundle?

Rork’s FAQ says of its backend that “your API keys stay on the server, never in the app bundle.” That is a checkable claim, and checking it takes about ten minutes.

An .ipa and an .apk are both zip archives. Unpack the build you are about to submit and search it for the shapes secrets come in:

# iOS: unpack the exact .ipa you are submitting
unzip -q MyApp.ipa -d ipa-out
grep -rIn -E 'sk_live_|sk_test_|service_role|SUPABASE_SERVICE|eyJ[A-Za-z0-9_-]{30,}' ipa-out | head -40

# Android: same idea, on the .apk built from the .aab you upload
unzip -q app-release.apk -d apk-out
grep -rIn -E 'sk_live_|service_role|SUPABASE_SERVICE|eyJ[A-Za-z0-9_-]{30,}' apk-out | head -40

Read the hits carefully, because not every match is a finding. A Supabase anon key is a JWT, so it starts with eyJ, and it is designed to ship in the client; it is only as safe as the row-level security sitting behind it, which is why the RLS tests above come first. A service_role key, a Stripe sk_live_ secret, or a model-provider key in the bundle is a real finding. Everyone who installs the app from the store has that key, and rotating it means shipping a new binary and waiting out review again.

If the grep comes back clean, you have evidence for the vendor’s claim instead of trust in it. If it does not, you have found the highest-value bug in the release before a stranger did.

How should a Rork Pro app handle Expo updates?

Rork Pro uses Expo, but Rork’s public documentation does not establish that every project enables EAS Update. Inspect the exported project before assuming an over-the-air update channel exists. If EAS Update is configured, separate staging and production channels and set a runtime-version policy that matches the release process.

Expo’s runtime-version documentation explains that an update must remain compatible with the native code in the installed binary. Changes to native libraries require a new build. Expo’s deployment guide recommends testing the same update on a staging build before promoting it to production and supports percentage rollouts for a narrower release.

Apple’s App Review Guideline 2.5.2 says apps may not download, install, or execute code that introduces or changes features or functionality after review. Runtime compatibility and App Store compliance are separate checks. Native-code, permission, and entitlement changes require a new binary in any case. Treat a material feature change as a store-review question rather than assuming a compatible EAS runtime makes it acceptable.

That guideline has real 2026 enforcement behind it. In March 2026, Apple pulled the vibe-coding app Anything from the App Store, after already blocking its updates since December. Anything’s founders tried the fix Apple had reportedly suggested to other blocked developers, routing generated previews to an external browser instead of the native shell; the app briefly returned in early April, then Apple pulled it again days later over how the company marketed itself as an app maker. Around the same time, Apple blocked updates for Replit and Vibecode under the same guideline, signaling review would clear once Replit opened generated apps in an external browser and Vibecode dropped the ability to generate software for Apple devices. Replit says the freeze cost it features, fixes, and App Store ranking, a separate question from whether Replit’s own security holds up, worth its own post.

The line Apple draws is between an app built with AI, always fine, and an app that builds and runs other apps on-device, or ships new functionality after review through an over-the-air update instead of a fresh binary. A config change to reviewed code is fine; a new screen arriving over the wire after Apple signed off is what’s getting apps pulled.

If a submitted build has already failed this rule, contesting or fixing a 2.5.2 rejection is its own post. No public primary source reviewed for this revision showed Apple pulling or rejecting a Rork-built customer app specifically, so this is a release-control check rather than a claim about Rork enforcement.

A Rork build becomes a production release when its code, backend, store configuration, and recovery path have all been tested as one system.

The same framework as Discord and Shopify, checked by whom?

Rork’s own FAQ says Rork Pro “uses React Native and Expo, the same production framework behind Discord, Shopify, Coinbase, and nearly 30% of top 100 apps on the App Store.” True, and it says nothing about which version your app runs, or whether that version has a publicly known way in.

Across the 26 real AI-built apps AxonBuild audited, 9 ran a framework version with a publicly known, reachable remote-code-execution or auth-bypass hole, most often the Next.js middleware and React-flight-protocol window that hit multiple frameworks through 2025 and 2026. One audit I ran had the app pinned to next@15.0.4, carrying two public CVEs on the internet-facing runtime: one let an unauthenticated request skip the middleware gating admin pages, the other a remote-code-execution path reachable on every route the app served, on the same server holding its auth secrets. Bumping the version cleared both plus two dozen other advisories nobody had touched. Nothing mobile-specific about the pattern: a version nobody moved because nothing crashed while it sat there.

Using React Native and Expo is a different claim from keeping your version current. “Same framework as Discord” describes the library, not your dependency versions. Dependencies and supply chain was the second-worst of the twelve pillars AxonBuild’s audits score, 34.5 out of 100, behind only reliability, and almost every failure there had the same fix: a version bump, not a rewrite.

The honest other half matters just as much. In 3 of 21 third-party apps in the same corpus, a scanner flagged 33 to 44 vulnerabilities each, and once checked for reachability the true count was zero. Raw scanner output is a triage input, not a risk number by itself; checking reachability in both directions is the work.

One caveat, stated plainly rather than hedged: the 26 audited apps are web apps on a Supabase or Postgres stack, none built with Rork or shipped as native mobile. The rate is a general pattern in AI-generated code, not a Rork-specific measurement, and there’s no reason a mobile build habit would be more disciplined about dependency upkeep than the web apps already show.

What Rork builders report going wrong

On 17 August 2026, Trustpilot displayed a score of 1.8 out of 5 across 21 reviews, including a review that called the product a scam. That is evidence of negative public sentiment, not a verified account of how the product behaves for every customer.

Read those reviews for what they are: unverified, self-selected, and weighted toward people who had a bad time. The recurring complaints visible on the linked Trustpilot profile are operational rather than legal:

• Previews that fail, or that behave differently from the build.
• Crashes and bugs that take several prompts to clear.
• Credit burn on iteration, since a failed attempt costs the same as a good one.
• Slow or unhelpful support when a project is stuck.
• In one dated Trustpilot review, project data loss.

The crash reports have a recognizable shape, and it is worth naming because it is the one that costs money. The app runs in preview, then crashes on a real device or right after the store build goes out, and the fix becomes a loop: prompt, rebuild, crash again, prompt again. Rork’s own FAQ documents an escape route rather than denying the loop, telling builders stuck in an error loop to ask Rork to search the web for the error, switch to a different AI model, or restore a previous working version and implement the feature a different way. The same FAQ is explicit that “We cannot fix individual code issues, but we update the AI daily to reduce mistakes,” and that AI errors themselves are not charged credits. Two things break the loop faster than another prompt. Read the actual crash log first, from TestFlight, the Play Console’s crash reports, or Xcode Organizer, so the next prompt describes the failing call rather than the symptom. Then check whether the crash exists only in the store binary, because a preview that runs proves nothing about the artifact users install.

None of that makes Rork a scam. Rork publishes real apps to real stores. What the pattern describes is a young tool with a beta backend, which is a different kind of risk and one you can engineer around. Three moves cover most of it.

Export to GitHub on day one, before you have anything to lose. Rork’s two-way GitHub integration exists for paid users. Use it from the first build that works, not the week you decide to leave. An export you have never cloned is a promise, not a backup.

Own the accounts yourself. The Apple Developer account, the Expo account, the Google Play account, the Supabase organization, and the domain should sit under the business, on billing you control. Rork documents a one-time transfer of the backend into your own Supabase organization; do that before there is production data in it, not after.

Take your own database backups. Rork Cloud is documented as beta and its database changes go live immediately with no preview step. That combination means your recovery plan cannot be “the vendor has a copy.” Pull your own dumps on a schedule, keep them somewhere Rork cannot reach, and rehearse the restore into a scratch project before you need it.

If Rork turns out to be the wrong fit, the alternatives worth naming depend on the target: Replit for a prompt-built app you host yourself, the web-first builders Lovable, Base44, Bolt and v0 for anything that can ship as a web app before it ships as a store binary, and a coding agent such as Cursor, Claude Code or Windsurf driving an Expo project you own outright when the app has to stay native and you want the code under version control from the first commit.

What does Apple expect beyond a working build?

App review includes product behavior, metadata, privacy, payments, and account handling. Apple requires a privacy-policy link in App Store Connect and inside the app. Apps that support account creation must provide account deletion inside the app. Permission purpose strings must clearly explain how the requested data is used.

Rork’s checklist also calls out accurate screenshots, pricing disclosure, policy links, and a working support URL. Confirm those items against the current Apple App Review Guidelines because Apple’s rules control the submission.

This page stays on what a Rork build has to prove before it enters review. The step-by-step path through App Store Connect, from creating the app record to the first approved release, is the same walkthrough for any AI-generated app and does not change because Rork wrote the code.

Two guidelines reject AI-generated apps more often than 2.5.2 does, and neither is about code. Guideline 4.2 minimum functionality says an app “should include features, content, and UI that elevate it beyond a repackaged website,” and that an app which is not “particularly useful, unique, or ‘app-like’” does not belong on the store. Guideline 4.2.6 is narrower and worth reading twice: apps “created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content.” Submitting your own app, from your own account, with your own content, is exactly what that clause allows. Guideline 4.3 spam covers the rest, telling developers not to submit apps that are “indistinguishable from what’s already widely available,” and naming categories, dating, flashlight, sound effects, wallpaper, simple timers, fortune telling, that Apple will not accept again without a meaningfully different experience. A prompt-shaped app in one of those categories is the default rejection, whatever tool built it.

Then there is the check that can fail before review even starts. A privacy manifest, PrivacyInfo.xcprivacy, declares the data an app or included SDK collects, any tracking, and approved reasons for required-reason APIs the code uses. Apple’s listed third-party SDK rules apply when a new app includes one of those SDKs or an update adds one. A listed SDK delivered as a binary dependency must also be signed. Apple documents the format and the reason codes in its privacy manifest guide, and publishes the SDK submission rules separately. This one surprises people because it is an upload problem, not a review problem. Since May 2024, App Store Connect refuses builds that use a required-reason API without declaring why, and the answer comes back as a machine-generated notice rather than reviewer feedback.

1. 01 Choose the correct Rork Pro or Rork Max release path and record the accounts, credentials, and project owner for it.
2. 02 Export the current source to a repository and confirm another person can install dependencies and reproduce the release build.
3. 03 Install the exact candidate through TestFlight or a Play testing track and exercise the main workflow plus failed network, permission, payment, and session paths.
4. 04 Test the backend with anonymous and cross-account requests, and verify server-side limits on every paid API or privileged operation.
5. 05 Confirm privacy metadata, account deletion, permission purpose strings, screenshots, support URL, and subscription behavior against current store rules.
6. 06 Document backup, restore, rollback, monitoring, and ownership before giving the build to real users.

How long this takes, roughly. Apple Developer Program enrollment is quick for an individual and slower for an organization, because an organization account needs a D-U-N-S number registered to the legal entity. Apple’s enrollment page says the number is free, but requesting one has its own lead time, so start it early. App review turnaround varies, and a rejection restarts the clock. The hard floor sits on the Google Play side, and it is measured in weeks rather than days.

What Google Play asks for that Apple does not

Play is half of the Rork Pro promise, and it has gates Apple never checks.

Closed testing before production. Google requires new personal developer accounts to run a closed test with at least 12 testers opted in for 14 continuous days before they can apply for production access. Testers who drop out and rejoin do not count; the 14 days have to be unbroken. Recruit the testers before the build is finished, because this is the longest fixed wait in the whole launch and no amount of engineering shortens it.

The Data safety form. Play makes you declare in the console what data the app collects, whether it is shared, whether it is encrypted in transit, and whether users can request deletion. The declaration has to match what the app actually does. A Rork Pro app with analytics, crash reporting, a backend, and a payment SDK usually collects more than the builder remembers.

Target API level. Play enforces a moving floor. From August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher, with lower floors for Wear OS, Automotive, TV, and XR. An Expo project that has sat untouched for a year can fail the upload on this alone, which is another version-bump problem rather than a rewrite.

App Signing key custody. Play App Signing means Google holds the key that user devices trust, while you hold an upload key. Know which key lives where, who can rotate it, and whether the upload key is sitting in one person’s laptop keychain or somewhere the business can reach. Rork’s documentation covers producing the AAB that Play requires. It does not decide who owns the key, and that is the part that strands a project.

Can another developer take over a Rork project?

Rork’s code-export documentation says paid users own the generated code and can export it through a two-way GitHub integration. Rork Pro exports React Native and Expo; Rork Max exports SwiftUI and Xcode.

An export is valuable only when it reproduces. Clone it into a clean machine or CI runner, install from the lockfile, provide documented environment variables, and build without relying on an unexplained state inside the Rork workspace. Keep store accounts and backend ownership under the business rather than a temporary collaborator’s login.

That takeover test catches a practical production failure before launch: the app can be live while the only working build still exists inside one person’s account.

What an export from an AI builder actually contains, and which parts of a running app never travel with the code, is a question worth settling once for whatever tool you use. The answer is the same shape everywhere: the repository moves, and the accounts, keys, and stored data behind it are separate work.

Common questions about Rork app production

Can Rork apps go on the App Store?

Yes. Rork documents built-in App Store publishing for both Pro and Max. Pro uses React Native, Expo, an Apple Developer account, and an Expo account; Max produces a SwiftUI Xcode project. Before public release, use TestFlight for real device testing first and confirm the exact binary against live-like services.

Is every Rork-generated app production-ready?

Rork describes its generated code as production-ready, but that statement does not verify an individual app’s backend rules, payment behavior, dependencies, monitoring, privacy, or recovery. Production status belongs to a specific build and workflow after those checks pass.

Are Rork apps really native, or web apps in a wrapper?

Native. Rork’s FAQ says Rork Pro “uses React Native and Expo, a production-grade framework that compiles to real native code, not web views,” and that Rork Max “uses SwiftUI, Apple’s own native framework, compiled with Xcode.” The distinction matters at review time, because Apple’s guideline 4.2 rejects repackaged websites and thin web clippings. Neither Rork path produces one, so a 4.2 problem in a Rork app comes from thin functionality, not from the framework.

Is Rork a good app builder?

It is good at the first job and weak at the last one. Rork gets a plain-English idea to a working, submittable app on stacks other developers can pick up, React Native and Expo on the Pro path and SwiftUI compiled with Xcode on the Max path, and it publishes to real stores. It is weaker on the long tail of a launch: fixing a broken build spends credits at the same rate as building it, the Rork Cloud backend is documented as beta, and Rork’s FAQ says support cannot fix individual code issues. Judge it on your own device tests rather than on the preview, and budget for the fixing.

Is Rork a legitimate company?

Yes. Rork is a real company, Rork, Inc., with published documentation, terms of service, a privacy policy, paid subscription tiers, and, by its own account, thousands of customer apps published to the App Store and Google Play. The scam framing in some public reviews is about disappointment with output quality, credit burn, and support speed, not about a company that does not exist or a product that does not ship. Legitimate and good are separate questions, so read the mixed reviews for the operational risks they describe and check the ones that would hurt your project.

Is Rork safe to use?

Rork publishes real apps to real stores, so the scam framing in some public reviews does not establish that the company is illegitimate. Sentiment is still mixed. On 17 August 2026, Trustpilot displayed a score of 1.8 out of 5 across 21 reviews. Treat platform risk and app risk as separate questions. Export to GitHub early, own the Apple, Expo, Play, and Supabase accounts yourself, and keep your own database backups, and no single tool-side failure can take the project with it.

Is Rork free?

There is a free tier, but it is trial-sized: 5 credits a day and 35 credits a month in major markets, with no rollover into the next month. Publishing is not free either, because the App Store requires a $99 a year Apple Developer Program membership and Google Play charges a $25 one-time registration fee. Expect to be on a paid Rork plan before an app is ready to submit.

How much does Rork cost per month?

Rork Pro starts at $20 a month for 100 credits and runs to $100 a month for 500. Rork Max starts at $200 a month for 1,000 credits and scales to $1,800 a month for 10,000. A credit is roughly one build-or-edit request, credits do not roll over, and fixing a broken build spends them at the same rate as building it did.

Does Rork publish to Google Play as well as the App Store?

Yes, through the Rork Pro path, which builds React Native and Expo projects for iOS and Android. Rork Max is Apple only. Play adds gates the App Store does not have: an AAB upload, the Data safety declaration, a target API level floor, and, for new personal developer accounts, a closed test with 12 testers opted in for 14 continuous days before production access is granted.

Does every Rork app need a backend?

No. Rork’s documentation says local-only tools without accounts, sync, sharing, persistent cloud files, or access rules can stay on-device. Accounts, shared state, multi-device sync, moderation, and server-enforced rules require a backend.

Does Rork prevent App Store rejection?

No publishing tool can guarantee approval. Rork prepares and submits builds, while Apple reviews the resulting app against current guidelines. Permission descriptions, privacy, subscriptions, screenshots, account deletion, device behavior, and update mechanics remain the app owner’s responsibility.