The first wall when trying to ship an iOS app with Rork: opacity. "Native, but what's actually happening behind the curtain?" Is JavaScript running like React Native? Is real Swift code being generated? Where is the build happening? The official docs don't quite paint the whole picture.
In the past six months I've shipped three iOS apps to TestFlight using Rork. I've made my share of mistakes. Here I lay out the entire workflow — from "writing a Rork prompt" through "the SwiftUI code that comes out" through "build" through "running on a real device" — using the steps I follow day to day. The aim is to give beginners a map so they can see where they currently are.
First, Rork's Output Is a Real Native App
The thing to internalize first: Rork generates real SwiftUI code. No React Native or Flutter intermediate layer — what you get is a Swift project that opens directly in Xcode.
Why this matters: the path of "open Xcode and edit the Swift directly after generation" is always available. Build 80% with Rork, finish the last 20% by hand. That's a realistic operating mode. The TestFlight builds I've shipped all got final polish in Xcode.
If you don't understand this structure, you'll force yourself into "Rork must do everything" mode and waste loops on prompts. My first app went exactly like that. It took me a month to conclude "would have been faster to drop into Xcode."
The 5-Step Workflow
The workflow I currently use:
Step 1: Generate the app skeleton via prompt. Describe screens, data model, navigation, and let Rork produce the initial project. Goal: get something running as fast as possible. Don't worry about polish.
Step 2: Refine UI screen by screen. Take each screen one at a time and tell Rork "tighten the spacing, fonts, and colors here." Attaching screenshots helps a lot.
Step 3: Export the Swift project and open it in Xcode. Pull Rork's output as a .zip or Git repo, open in Xcode.
Step 4: Run on a real device. Install directly on your iPhone from Xcode and verify actual behavior. Rork's simulator and a real device differ subtly, so device testing is non-negotiable.
Step 5: Ship to TestFlight. Apple Developer Program steps, App Store Connect setup, TestFlight tester invites.
Steps 1 and 2 are Rork territory. Steps 3 and 4 are Xcode territory. Step 5 is App Store Connect territory. Knowing from the start that you'll move between three places saves confusion.
Step 1: Writing the Skeleton Prompt
For the first project, write the prompt so the relationships between screens come through. My template:
Building a native iOS app in SwiftUI.
App purpose:
A reading log. Record the title, author, notes, and rating (1-5)
for books you've finished.
Screens:
1. Home: list of recorded books. New-entry button at top right.
2. Detail: opens when tapping a list item. Shows the book info,
with edit and delete buttons.
3. Edit: form to edit title, author, notes, rating.
4. New entry: same layout as Edit but starts empty.
Data persistence:
Use SwiftData. Book model has id (UUID), title (String),
author (String), note (String), rating (Int), createdAt (Date).
Start minimal. Polish design later.
Three points. First, declare screen count and relationships up front. Without this, Rork helpfully invents extra screens.
Second, specify the data model concretely, types included. Vague generation here is expensive to fix later.
Third, the line "start minimal." Without it Rork adds animations and effects out of generosity, which slows generation. Speed first during skeleton phase.
Step 2: UI Refinement Using Screenshots
Once the skeleton works, refine each screen. The single most powerful technique: attach a screenshot.
If the home list feels cramped, screenshot Rork's preview and instruct:
Issues in the attached screenshot:
- Row spacing is too tight, hard to read
- Rating stars on the right are too small to see
- New-entry button doesn't stand out
Fixes:
- Add 12pt vertical padding to each row
- Make rating stars 18pt SF Symbols star.fill
- Move new-entry to a Floating Action Button at bottom right
Splitting "current issues" and "fixes" into two bulleted blocks works well. Screenshot + structured feedback is dramatically more accurate than text-only instruction.
The classic mistake: vague briefs like "make it more modern." Rork will change something, but rarely what you meant. Use concrete parameters (pt, color, position).
Step 3: When to Drop into Xcode
The hardest call: stay in Rork or descend to Xcode? After six months, my rule:
Stay in Rork for "easily verbalized changes." Color shifts, layout changes, adding a screen, modifying a data model — Rork is good at these.
Drop to Xcode for "hard-to-verbalize tweaks" and "edits to existing code." Things like "make this button's tap animation a 0.3s easeOut" are faster to type yourself than to describe.
The other reason for Xcode: anywhere you call Apple frameworks directly. Once you reach for Notification, HealthKit, CoreLocation, the complexity outgrows what prompts can carry. Just open the Swift docs and write it.
Step 4: Common Real-Device Stumbles
Three pitfalls when going from Xcode to a connected iPhone:
Signing & Capabilities. In Xcode project settings, pick your Apple ID as Team and set Bundle Identifier to a unique string (e.g., com.yourname.bookapp). Skip this and you'll see "No matching profile found."
"Untrusted Developer" warning. After installing on device, go to iPhone Settings → General → VPN & Device Management and trust your Apple ID. Without this the app installs but won't launch.
Network permissions. If your app calls APIs, add NSAppTransportSecurity to Info.plist; for local-dev servers, allow NSAllowsLocalNetworking. Rork generates assuming production, so local-dev settings are a "you add later" item.
Step 5: Shipping to TestFlight
The TestFlight path has many small forks for first-timers. The essentials:
Setup: enroll in Apple Developer Program ($99/year). Create a new app in App Store Connect, and match Bundle Identifier to Xcode.
In Xcode, do an Archive build (Product → Archive). On success, the Organizer window opens — choose Distribute App → App Store Connect → Upload. The upload runs 5–10 minutes.
Back in App Store Connect, the new build appears. Answer the export compliance question (do you use encryption?), then in the TestFlight tab add internal testers (yourself, friends). Testers receive a TestFlight link and install.
Once here, you've shipped. Now the loop: gather user feedback, return to Rork, improve.
Failure Patterns I Repeated
Mistakes I made more than once, shared so you can skip them:
"Hand over a perfect spec from the start." Trying to generate a 10-screen app from one prompt collapses Rork mid-stream. Grow it 3–4 screens at a time.
"Stay inside Rork without ever opening Xcode." Rork's preview and on-device behavior differ enough that early on-device testing is a habit worth forming.
"Change the data model later." Mid-flight SwiftData model changes mean migrations, which are more painful than you'd guess. Spend time on the model up front and the rest is easier.
A Suggestion for Your First Build
For anyone new to building iOS apps with Rork, I strongly suggest "a small tool you actually want to use yourself."
My first build was a feature-light memo app for tracking books I want to read. Not for sale, so I could accept "minimal is enough" and use it as a Rork practice ground. Once shipped, I'd use it daily, surface my own complaints, and turn the improvement loop naturally.
Don't aim for a chart-topping App Store hit on attempt one. Start by "solving a small problem of your own" — both the strengths and the limits of Rork become visible, and that knowledge feeds your next serious project. That's what I'd tell my six-months-ago self.