Native iOS Apps with Rork: SwiftUI to TestFlight

The first wall I hit building an iOS app with Rork wasn't a feature — it was vocabulary. The product said "native," yet the project I exported was full of App.tsx. I had expected Swift files, so for a while I assumed I'd clicked something wrong.

The second surprise came this September, on a morning I spent re-reading the official docs. The platform picker under the prompt box now offered three choices — For iPhone, For Android, Web — and the Expo option that used to sit there was gone.

There's a reason for the confusion. Rork's exits have changed twice in half a year.

Two Corrections, Stacked

This article originally assumed that Rork generates native SwiftUI. After publishing, I corrected it to "plain Rork emits React Native (Expo); only Rork Max, launched in February 2026, generates SwiftUI."

That correction has now aged out too. According to the official documentation, Rork no longer creates Expo (React Native) projects. New iPhone apps are Swift, new Android apps are Kotlin, and new web apps are React. The stated reason is that on internal benchmarks the agent wrote better Swift apps than React Native apps.

What's more, SwiftUI generation for iPhone is now included in Rork Pro at $20 a month. What Rork Max covers is everything outside the iPhone: iPad, Apple Watch, Vision Pro, iOS widgets, and native games.

Existing Expo projects keep working — you can build them, publish them, and export to GitHub as before. That one thing hasn't moved.

This isn't a naming quibble. It changes the order in which you do everything. Below, I'll lay the current map out on one page, then walk the path I actually take to TestFlight.

The Current Map — What Gets Generated on Which Plan

The whole thing reduces to one line: if you only need iPhone, Pro is enough. There's no longer any reason to think, as I once did, "I want SwiftUI, so I need Max." The step up to Max is decided by how many devices you need, not by language.

The other point worth holding onto is that iPhone and Android live in the same project as two separate native apps. It isn't the React Native model of one codebase shared across both operating systems. It's a Swift codebase and a Kotlin codebase, tied together by one chat and one backend.

A 30-Second Test for Which Generation Your Project Belongs To

If you have a half-built project, the fastest check is the root of the exported folder.

package.json next to app.json means an older Expo project. It keeps running, but Step 3 onward here won't map cleanly.

.xcodeproj next to .swift files means a new-generation Swift project, and the steps below apply as written.

There's also a tell inside Rork itself, no folder required. Open an older project and a card titled "Make this app native iOS" appears beside the preview. As long as that card is showing, you can safely assume the project is still Expo.

Judge the Cost in Credits, Not Monthly Fees

For an indie developer, fixed monthly cost is the ceiling on how many attempts you get. Here are the line items the docs state explicitly.

The Free plan is Design mode only. You get screen concepts, but no working code. It allows 5 credits a day, up to 35 a month in major markets. Build mode — the part where Swift actually gets written, run in the simulator, and submitted — assumes a paid plan.

Rork Pro is $20 a month for 100 credits; Rork Max starts at $200 a month for 1,000. On top of either, shipping to the App Store requires Apple Developer Program membership at $99 a year.

The item people miss is the cloud simulator. It costs 0.2 build credits per minute while running, charged separately from your messages. Leave it idle for ten minutes and that's 2 credits — two percent of Pro's monthly allowance. Pressing Stop simulator after each round of testing was a habit I picked up in my first month.

And the biggest line item of all is the credits that evaporate on rework. My first week went to instructions issued before the spec had settled, and half the month's allowance was gone before I had anything I'd call a result. Budget "credits to try" and "credits to finish" as two separate envelopes from the start. That's the line I hold to now.

I've broken down the plans and where each one stops making sense in Rork Pricing Plans Compared Honestly: Free vs Pro vs Max and How to Choose as an Indie Developer. Prices and allowances shift, so confirm against the official pricing page before you commit.

The Five-Step Shape

What I currently run.

Step 1 — generate the skeleton by prompt. Describe screens, data model, and navigation, review the Design mode concepts, then press Build.

Step 2 — refine the UI screen by screen. Alternate between Element Selection (point at a thing in the preview and say what to change) and structured feedback with a screenshot attached.

Step 3 — get it onto a real device. Rork Companion, the Rork Max app, or TestFlight puts it on your iPhone. Xcode stays out of the loop.

Step 4 — drop into Xcode to finish. Optional. My criteria for when to descend are below.

Step 5 — ship to TestFlight or the App Store. Either from Rork's Publish menu, or by archiving in Xcode.

The biggest difference from the old Expo road is Step 3. The whole stage where you used to get stuck on signing and provisioning slides to the end, and the distance to "show someone something that runs" visibly shrinks.

Step 1: Writing the Skeleton Prompt

Pick For iPhone in the platform picker, then send your first message. This is the template I use.

I want to build a native iOS app in SwiftUI.

Purpose:
A reading log. Record books I've finished with title, author, notes, and a 1–5 rating.

Screens:
1. Home: a list of recorded books, with an add button in the top right
2. Detail: opens when a list row is tapped. Shows the book's info with edit and delete buttons
3. Edit: a form for title, author, notes, and rating
4. Add: same layout as Edit, starting from an empty state

Persistence:
Use SwiftData. The model is a Book type with id (UUID), title (String), author (String), note (String), rating (Int), createdAt (Date).

Minimal build is fine for now. We'll polish the design later.

After you send it, Rork doesn't start writing Swift straight away. It asks a few short questions about the look, and each answer is a picture rather than a word. Then Design mode draws the screens, and nothing becomes code until you press Build. Changing your mind at the concept stage is cheap; changing it after Build is expensive. If you already know the look you want, writing it into the first prompt is faster than waiting for the questions.

Three things matter in the prompt. First, state the number of screens and how they relate. Without that, the agent helpfully adds screens you didn't ask for.

Second, write the data model down to the types. SwiftData models drag a migration along with every mid-flight change, so a few minutes here saves hours later.

Third, say "minimal build" explicitly. Otherwise animations and small effects get folded in, and credits go with them. The skeleton stage is about speed.

With Pro's allowance at 100 credits a month, how concretely you write this first prompt is, quite literally, how many rounds of verification you get. I'd keep the prompt in a note and revise it rather than treating it as disposable.

Step 2: Fix by Selecting Elements, Fix by Screenshot

Once the skeleton runs, refine one screen at a time. Rork now gives you two ways to do it.

The first is Element Selection. Use Select an element above the simulator to point at a part of the preview, then write what you want changed about it — more padding, a bigger star. Rork reads the element you picked and edits only that part. When you want a single, surgical change, this path is far less likely to rewrite the surrounding code by accident.

The second is a screenshot with structured feedback, which suits whole-screen balance problems better.

Problems in the attached screenshot:
- Row spacing is tight and hard to read
- The rating stars on the right are too small to see
- The add button doesn't stand out

Changes I'd like:
- Add 12pt vertical padding to each row
- Render stars with SF Symbols star.fill at 18pt
- Move the add button to a floating action button in the bottom right

The trick is separating "what's wrong now" from "what I want changed." The common failure is a vague "make it more modern" — something will shift, just not in the direction you meant. Specify concrete parameters: points, colors, positions.

Step 3: Check on a Real Device

The cloud simulator runs a real iOS system, so most checks happen there. It has no physical camera, though, and it can't receive Apple push notifications. Camera and push are the two things you must verify on a phone.

There are three ways to get the app onto your iPhone. Press Run on your device above the simulator and use Rork Companion for Windows or Mac to install over USB. Open the Rork Max app on the phone and use Install on Device. Or submit a build and install through TestFlight. The Rork Max app is rolling out to selected accounts, so if you don't see it yet, Companion is the path.

The first thing I noticed on hardware was the bounce at the end of a list. What looked smooth in the preview snagged under my finger. It's not a difference any number reveals — you have to touch it. Going through this step early tends to collapse a lot of later fixes into one.

Step 4: Deciding Whether to Drop into Xcode

Because Rork builds entirely in the cloud, opening Xcode is a choice rather than a requirement. After six months, my rule is this.

Stay in Rork for changes that are easy to put into words. Color, layout, adding a screen, adjusting a data model — this kind of work is faster delegated than typed.

Drop into Xcode for tweaks that resist description, and when you want to step through code. "Make this button's tap animation a 0.3s easeOut" is quicker to write than to explain. The same applies when you want to chase a cause through the logs.

If you do descend: sync the project to GitHub, clone it on a Mac, and run xed . in the project folder. Rork iPhone apps are plain Swift projects, so there's nothing to generate first. On the first open, Xcode resolves the Swift packages — wait for that to finish before you build.

For signing, select your Apple Developer team under the target's Signing & Capabilities. Skip it and you'll meet "No matching profile found." To run on your own iPhone you'll also need Developer Mode enabled on the phone, under Settings → Privacy & Security → Developer Mode. The "installs but won't launch" symptom is almost always this.

When a build fails for no visible reason, File → Packages → Reset Package Caches followed by Product → Clean Build Folder has, in my experience, cleared it nearly every time.

Step 5: Shipping — Publish from Rork vs. the Xcode Route

Open Publish in your project and the App Store section offers Submit to App Store. It opens a three-step dialog: App Info (icon, an app name of up to 30 characters, version, bundle identifier), an Apple Developer sign-in, and Start Submission. The build runs on Rork's machines; when it finishes, the build lands in App Store Connect and the chat shows "Available on TestFlight." A Beta Invite Link lets you bring testers in.

I'd run the AI App Store Reviewer before submitting. It checks your build against the App Store Review Guidelines and reports each rejection risk with its guideline number. Given how long review queues can be, fixing those yourself before Apple points them out is worth a lot.

A shorter submission path doesn't shorten the review requirements, though. Privacy disclosures, screenshots, age rating, export compliance answers. Generation got faster; that paperwork did not. On my first submission I spent more time on the forms than on the app.

If you take the Xcode route instead: Product → Archive, then in the Organizer choose Distribute App → App Store Connect, and the build appears in TestFlight. If it never surfaces and sits on "Processing," I've written up the isolation steps in Your Rork App Is Stuck on "Processing" in App Store Connect — A Field Guide to Getting It Unstuck.

For rejections, the guideline-by-guideline responses are in App Store Rejection Survival Playbook for Rork-Generated Apps.

If You Still Have an Older Expo Project

Existing Expo projects keep running. Builds, publishing, and GitHub sync all work as before. There's no need to rush a migration.

When you do decide to move, the path is built in. Press Add iOS app on the "Make this app native iOS" card beside the preview, and the agent rebuilds your screens, navigation, data flows, and design in SwiftUI. The Expo app stays in the same project, so you can compare the two side by side before committing.

I've made a habit of pausing before migrating any project that also needs Android. With Expo, one codebase reaches both operating systems; in the new generation, Swift and Kotlin are separate codebases, and the agent is what keeps them in step. On the other hand, projects that were iPhone-only felt better in the hand after moving. I've kept both, and I choose per project.

The thing to watch if you stay on Expo is that hand-edited native work disappears under prebuild --clean. How to inventory what's about to vanish is covered in Counting what prebuild --clean will erase before you upgrade to Expo SDK 57.

For how far SwiftUI generation can be trusted feature by feature, Benchmarking Rork Max SwiftUI Native Generation Across 30 Features — What to Delegate and When to Step In draws the line case by case.

Mistakes I Made More Than Once

The largest is that my understanding lagged the product's branching — both times. First I applied SwiftUI steps to an older React Native project; then I nearly paid for Max to get iPhone SwiftUI that Pro already included. The real waste was the time I spent attributing the failure to my own skill. Check which generation the project belongs to, then choose the plan by how many devices you need — that alone would have dissolved both problems.

Next most common: handing over a complete spec in one go. Ask for a ten-screen app in a single prompt and internal consistency breaks down partway. Growing it three or four screens at a time proved reliable.

Third: changing the data model late. Mid-flight SwiftData changes pull migrations along with them and stall you longer than you'd expect. I think time spent on the model up front is what makes the rest feel easy.

For Your First Build

If this is your first iOS app, pick a small tool you honestly want to use yourself.

Mine was a stripped-down memo app for tracking books I wanted to read. Nothing to sell, so "minimal is enough" was easy to accept, and it made a good practice ground. Once it shipped I used it daily, my own complaints surfaced on their own, and the improvement loop started turning.

Don't aim for a chart-topping release on attempt one. Solve a small problem of your own, and both what you can delegate and what you can't will come into view — which is exactly what your next serious project needs. In the current Rork, the cheapest place to start is the free Design mode: get one screen concept out, and let that concept decide whether Build is worth it.

Apologies to anyone who read this while an earlier premise was still in place. To those who came back to read it again, my sincere thanks.