Transition from Rork to a shippable mobile app (2026)

Citation-ready definition: Transitioning from Rork to a shippable mobile app means taking a Rork prototype to App Store and Play readiness without a greenfield rewrite: own the repository, decide Rork Cloud versus a backend you can operate, close the device-to-server trust boundary, then pass store gates — privacy labels, permissions, account deletion, TestFlight or Play testing — before production. A rewrite is for irreparable identity or native-packaging seams, not for generated screens.

The expensive Rork exit in 2026 is not the one that leaves the builder. It is the one that treats a chat preview as a release candidate, or copies a web-builder playbook onto a phone. Lovable’s job is a URL you can redeploy. Rork’s job is a signed binary Apple and Google will accept, plus a backend that still answers after the reviewer backgrounds the app. Rork’s publish guide is explicit: the platform can build and upload; it cannot be you.

If you are the founder, treat the transition as an ownership sequence, not a rewrite brief. Take the repository first. Decide whether Rork Cloud or a Supabase project you admin holds the rows. Attack the trust boundary the device can leak. Rehearse TestFlight and Play internal testing while the builder still exists. Rewrite only when identity or packaging cannot be made safe. The vibe coding hub is the map. What “production-ready” means after vibe coding is the ship gate. Get off Lovable without a full rewrite is the sibling web exit — useful contrast, not a template to string-swap.

What “shippable” means after a Rork preview

People collapse three exits into one sentence. That is how teams submit a TestFlight build they cannot rebuild, or cancel Rork before they own Sign in with Apple. Separate the work:

Code ownership is a Git problem. Rork’s code export FAQ is blunt: paid users own generated code and export through GitHub. The two-way sync guide is the paper trail: clone, edit in Cursor or Xcode, push back. A zip on one laptop is a snapshot. An organization-owned repository with a second maintainer is an exit artifact. See Get off Rork for the continuity lander this article expands.

Backend ownership is a Cloud-versus-yours problem. Rork Cloud is a hosted Postgres with RLS and Edge Functions, still in beta. Connecting your own Supabase — or using Transfer to your Supabase — is the path when you want the dashboard, billing, and backups in an account you control. The transfer is one-way. Secrets never land in Git; Rork’s Secrets editor says so. If your exit plan is “we connected GitHub, so we can cancel Cloud,” you have source and a schema hint. You do not have the business.

Store ownership is a distribution problem. Rork can upload to TestFlight and send an AAB to Play internal testing. That is packaging help. It is not App Review. An exit is finished when a second human can rebuild the binary, restore the database, rotate secrets, and submit an emergency fix without a Rork login. Rork to production is the systems handoff that sits next to this sequence.

This is not the Lovable exit

Do not paste the web playbook onto a phone. Getting off Lovable is Git, then backend, then hosting. Rork already has a publish machine. The last mile is a reviewer device, a privacy label, a permission string, and a deletion path that works after reinstall. A `rork.app` URL is the fast route on Rork’s publish page. It is not App Store readiness.

The stack underneath also moved. Rork’s Expo note is current as of 2026: you can no longer create Expo (React Native) projects. New iPhone apps are Swift; new Android apps are Kotlin; new web apps are React. Existing Expo projects keep working, and Rork will offer a SwiftUI recreation beside the old app. That is two native codebases sharing one backend, not one React Native file. If you still have Expo, EAS Build and EAS Submit for iOS remain a real packaging path once the repo is yours.

Harden in place, hybrid migrate, or rewrite

Do not pick a path from taste. Pick it from what you can prove about identity, the trust boundary, and the cost of being wrong on a store binary you cannot roll back. Use the production-ready checklist as the ship gate — not as a reason to burn a working preview.

Harden in place when you can name who owns each table, add tests around the paid or invite path, and keep Cloud (or the current Supabase) while you take the repo and close the security gaps. Most early products belong here. Rork MVP hardening is the sibling page for that job.

Hybrid migrate when you need the Supabase dashboard, independent billing, or a compliance story Cloud cannot give you, but the schema is still recoverable. Rork documents a one-way Cloud-to-Supabase transfer that keeps URL, data, and keys so the published app keeps working. That is a backend move, not a rewrite. Transition from Rork is the operating-model change while two delivery systems still share the road.

Rewrite when you cannot establish who can read a row, when Rork Auth and Supabase Auth were mixed so user IDs do not match, when privileged keys shipped with an `EXPO_PUBLIC_` prefix, or when proving safety costs more than rebuilding a named slice. A rewrite still needs Git, secrets, store seats, and a restore. It is this article plus a new domain model — not an escape from store review.

Ownership first: GitHub sync realities

Start with the repository. Rork’s GitHub integration is export and two-way sync. Code export requires a paid plan. Read the code is free; hand-editing is not. The tree is one folder per app, so iPhone-plus-Android is two codebases.

Do not assume a single React Native checkout. New Rork work is Swift and Kotlin side by side. An Expo leftover still syncs, but “add Android” is a second native app. Name the org, the repo, and the second maintainer before you click Connect.

Then remember what is not in the repo. Secrets do not go to GitHub. They live with the Rork project. Set them again in any environment you run yourself. Rork Cloud rows are not in Git. Store certificates and Play service-account keys are not in Git. If your exit plan is “we cloned, so we can delete the project,” you have source and a design file. You do not have keys, seats, or a restore.

Native packaging: Swift, Kotlin, or leftover Expo

Decide the packaging path before you spend a week on screenshots. New iPhone work is Swift/SwiftUI; new Android work is Kotlin/Compose. Rork builds on its machines, so you do not need Xcode to upload. You do need Xcode, Android Studio, or a CI you admin the day you want a binary that does not depend on a Rork session. Open the project in Xcode is the optional local path once GitHub is connected.

If you still have Expo, do not invent a Flutter rewrite because a marketing page said “native.” Expo is still a real store path: EAS Build produces the binary; EAS Submit uploads to App Store Connect. Convert to Swift for a measured API or staffing gap, not because the homepage changed.

Auth and data: the device is not the trust boundary

Rork gives you two account models and tells you to pick one. Rork Auth is Google and Apple sign-in with no extra console work and no backend. Supabase Auth is email, magic links, phone codes, and other providers — and it needs a Supabase project. One project uses one of them, never both. Each hands out its own user ID. Mix them and people sign in to empty screens. Accounts do not migrate if you switch later.

That last sentence is a silent outage waiting for store traffic. If you started on Rork Auth to move fast, you do not get a one-click identity export into Supabase. Plan the model before you have paying users, or budget a re-signup. Rork Auth sessions live in the Keychain on Swift, SecureStore on Expo, and `localStorage` on web. The session survives delete-and-reinstall. Test sign-out as a product feature, not as “wipe the simulator.”

Apple will reject Sign in with Apple mistakes Rork itself lists: asking again for name and email after Apple already handed them over; refusing `@privaterelay.appleid.com` addresses; hiding the Apple button. Those are App Store Review Guidelines problems, not prompt problems. Run them on a real device before you press Submit.

Secrets are the second gate. Rork’s rule is in the name: a variable prefixed `EXPO_PUBLIC_` is baked into the app; everything else stays server-side. Never give a Stripe secret or a service-role key a public prefix. Search the client bundle and the Git history. Rotate anything that appeared in chat. Editors on the Rork project can read secrets — invite accordingly. After export, those values do not travel; you re-enter them in CI.

Data rules are the third gate. Rork Auth policies use `user_id()`. Supabase policies use `auth.uid()`. A hidden button is not a policy. Write the access matrix before you write more features. For every table that matters — profiles, workspaces, invitations, payments, files — name who can read a row, who can write it, and what happens after a member is removed. Test the negative case: change an ID on the device and call the API. If the row returns, you are not ready for TestFlight, and you are not ready for a rewrite either.

Store compliance the preview never catches

A clean simulator is not a listing. Apple requires privacy nutrition labels in App Store Connect: what you and your third-party SDKs collect, whether it is linked to the user, whether it is used to track. You own the SDKs you shipped. Update the answers when the practice changes; you do not need a binary update just to correct the label.

If the app creates accounts, Apple requires in-app account deletion — not a freeze, not “email support” unless you are in a highly regulated industry. Deletion must be findable in settings. Play’s User data policy and account deletion help require both an in-app path and a web resource, plus the Data safety section. Freezing an account is not deletion.

Permissions are copy, not chrome. Camera, photos, location, notifications, and Bluetooth need a purpose string the reviewer can believe. A generated prompt that says “so the app works” is a rejection. Deep links, push, and background fetch need a reason that matches the binary. Placeholder screenshots and lorem listings fail App Review for the same reason they fail humans: they prove you have not operated the product yet.

TestFlight and Play testing before production

Rork will upload an iPhone build to TestFlight and hand you a `rork.com/beta/…` link. That still needs a paid Apple Developer membership — Rork says $99 a year — and App Store Connect. Apple’s TestFlight page is the channel. Rork’s link adds team testers; a large public beta is an external group Apple reviews first. Testers must use their Apple ID email and accept two invites. A TestFlight build is not for sale and not public.

On Android, Rork’s automated upload targets internal testing, not production. You still create the app in Play Console, fill Data safety, and promote the release. New personal accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days. Internal testing does not satisfy that rule. Start the account on day one. Rork’s Play account guide repeats the sequence.

Run the rehearsal as a freeze, not as a vibe session. Install on a device that is not the author’s. Background the app mid-write. Kill it. Retry the paid action and confirm it is idempotent. Sign out and sign in after reinstall. Complete account deletion on a throwaway user and confirm the row is gone. Give App Review and Play a reviewer account that reaches the core flow. Watch auth failures and webhook 4xx. If you cannot see those, you finished an upload, not operations.

When a rewrite is warranted

A rewrite is a product decision with evidence, not a taste decision about generated SwiftUI. Warrant it when at least one of these is true and you can show it:

• You cannot establish access. Changing an ID returns another tenant’s row, and the policies cannot be repaired without breaking the only happy path.
• Privileged keys are in the binary (`EXPO_PUBLIC_` or a hardcoded secret) and the call graph has no server seam you can move them behind in bounded time.
• Rork Auth and Supabase Auth were mixed, or you must switch models after users exist, and there is no supported account move.
• The two native apps have already drifted into incompatible domain models, and keeping them in sync through chat would be a destructive guess.
• The cost of proving safety — review, tests, store metadata, data repair — exceeds the cost of rebuilding a small, named surface and importing only the records you can certify.

Ugly screens are not evidence. “Rork left Expo” is not evidence by itself; existing Expo projects still publish. If you rewrite, strangler the risk: keep the live binary, wrap the unsafe slice, migrate one capability, measure. Preserve data on purpose. Unowned trust is the defect, not the origin story.

Operator checklist

This is the sequence. Adjust duration to your risk. Do not invert the order because a store listing is more visible than RLS.

1. Inventory the doors. Write the human who will own git, the database, file storage, auth, bundle and package identifiers, Apple and Google seats, certificates, and on-call after the builder is gone. If a door still opens only inside Rork, it is on the list. If you cannot name the human, you do not have a submit date. You have a hope.

2. Take Git ownership. Connect GitHub sync into an organization you admin. Add a second maintainer. Protect the default branch. Confirm the repo has the app folders and does not have secrets. Clone it on a machine that is not “whoever had the Rork tab open.”

3. Choose backend and auth on purpose. Stay on Rork Cloud if the schema is fine and you only needed the repo. Transfer to your own Supabase if you need the dashboard or independent billing. Pick Rork Auth or Supabase Auth once. There is no supported account bridge. Budget the manual work.

4. Pass the trust gate. Every important table has rules you have tested. Public prefixes are not on secret keys. Sign in with Apple survives relay emails. Account deletion works in-app and, for Play, on a web page. A former member cannot read current rows.

5. Rehearse TestFlight and Play testing. Upload from Rork or from CI. Exercise lifecycle failures on a real device. Start the Play 12×14 closed test if the personal account is new. Keep the Rork project alive through the first clean week of ordinary tester traffic.

6. Submit listings last. Fill Apple privacy details and Play Data safety from an inventory, not from memory. Attach a reviewer login. Then request production. Deleting the Rork project is not a rollback. It is a commitment.

FAQ

Does leaving Rork for the stores mean I have to rewrite the app?

No. Rork documents paid GitHub export, two-way sync, a Cloud-to-Supabase transfer, TestFlight upload, and Play AAB upload as ownership moves on the existing project. A rewrite is for irreparable access, identity, or packaging. Most exits are repo, backend, trust, stores — not a blank Xcode project.

If I connect GitHub, do I also own Rork Cloud data and store signing?

No. Code export and GitHub sync give you source. Secrets stay on the project and are not committed. Cloud rows need the Database tab or a transfer. Apple and Google seats, certificates, and listings live in those consoles. Connecting GitHub and cancelling Rork is how teams keep Swift files and lose the business.

Can I keep publishing from Rork after the repo is mine?

Yes — and you should, during rehearsal. Two-way sync is built for that hybrid. Do not treat the hybrid as the exit. The exit is a second human producing a signed artifact and a restore without a Rork login.

Can I run Rork Auth and Supabase Auth together, and can I migrate accounts?

No and no. Official auth docs say one model per project. Mixing IDs produces empty screens. Switching models turns the old one off and does not move accounts; existing users sign up again. Pick before you have customers, or treat the switch as a product announcement, not a settings toggle.

What store gates does a Rork preview never catch?

Apple privacy labels, in-app account deletion, Sign in with Apple presentation rules, and permission purpose strings. Play Data safety, account deletion plus a web resource, and the 12-tester / 14-day closed test for new personal accounts. A preview that looks finished can still fail every one of those.

When should I transfer Rork Cloud to my own Supabase?

When you need the dashboard, independent billing, or a compliance box Cloud cannot tick, and you already own Git. The transfer is one-way; URL, data, and keys stay the same. Do it after a restore rehearsal, not the same week you submit for review.

Does a TestFlight or Play internal build mean I am production-ready?

No. Rork’s TestFlight link is a team beta. Play internal testing is not production, and it does not satisfy the closed-test rule for new personal accounts. Production-ready still means the operating contract: identities survive reinstall, writes are owned on the server, and a tested rollback exists. A processed build is evidence of packaging, not of that contract.

Should I convert an existing Expo Rork project to Swift before I ship?

Only with evidence. Existing Expo projects keep working. Rork will offer a SwiftUI recreation beside the old app. Convert if Expo is boxing in an API you need, or if iPhone is the lead surface and you can staff Swift. Do not convert both platforms in the same week you first take Git.

Next steps

Walk the doors in order. Connect Git into an organization you admin. Decide Cloud versus your Supabase with the one-way-transfer constraint on the table. Pick one auth model. Attack your own RLS and public prefixes. Rehearse TestFlight and Play testing. Book the rewrite only if the evidence list fired.

CodeCross LLC is an Austin-registered product studio. We help operators leave a mobile builder without paying for a second product: ownership first, hardening on the critical paths, store rehearsal with a rollback window, and a rewrite only when the trust boundary is irreparable. The Austin app development company page is the studio brief; Austin mobile app development is the store-binary engagement. Company-level evidence lives on proof. When you want a second pair of hands on the sequence, book a conversation.

The goal is not to punish vibe coding. It is to stop treating a working Rork preview as disposable, and to stop pretending a web-builder exit applies 1:1 to a signed binary. Ownership is a sequence. Rewrite is a verdict.