Building Native iOS Apps with Rork Max — From SwiftUI Generation to TestFlight

The first wall I hit building an iOS app with Rork wasn't a feature — it was vocabulary. The product says "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.

There's a reason for the confusion. Rork has two exits.

This article originally assumed that Rork generates native SwiftUI. That isn't accurate. Plain Rork emits a React Native (Expo) project. The product that generates native Swift and SwiftUI is Rork Max, which arrived in February 2026. The period I was hands-on overlapped with that split, and the two products stayed fused in my head. Correcting it here.

The distinction isn't about naming. It changes the order in which you do everything. Below: how to tell the two exits apart, then the path I actually walk to get a Rork Max app onto TestFlight.

Two Exits — Rork and Rork Max Emit Different Things

The whole picture on one page.

That last row carries the decision. Rork Max buys depth inside Apple's world at the cost of Android. The base product goes wide but adds friction every time you touch a native API. Ship fast and broad, or go deep into Apple's features? Answer that first and most of the later choices make themselves.

A 30-Second Test for Which Road You're On

When you lose the thread mid-project, look at the root of the exported folder.

package.json plus app.json means React Native (Expo) — base Rork output. Step 3 onward here won't map cleanly.

An .xcodeproj or .xcworkspace alongside .swift files means SwiftUI — Rork Max output, and the steps below apply as written.

If it's still ambiguous, the reliable test isn't "does it open in Xcode" but "does the build finish without Xcode on my machine." Rork Max compiles on cloud Macs, so you can reach a build and a streamed simulator preview without owning a Mac at all. If that stalls, you're on the other road.

Don't Judge the Cost by the Monthly Fee Alone

The line items I actually pay, for calibration.

Base Rork starts free, with paid plans from $25/month. Rork Max sits on the Max plan at $200/month. On top of that, shipping to the App Store requires Apple Developer Program membership at $99/year. The free allowance runs to roughly five prompts a week, so anything past a sketch assumes a paid plan.

The item people miss is the third one: the prompts you burn re-doing work convert directly into money. My first week went to instructions issued before the spec had settled, and the free allowance was gone before I'd verified anything worth calling a result. Budget "cost to try" and "cost to finish" as two separate envelopes from the start.

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 on Rork Max.

Step 1 — generate the skeleton by prompt. Describe screens, data model, and navigation. The goal is something running as fast as possible; polish comes later.

Step 2 — refine the UI screen by screen. Take one screen at a time and direct spacing, type, and color. Attaching a screenshot raises the hit rate considerably.

Step 3 — get it onto a real device. Rork Max installs to your iPhone via QR code, so this happens without Xcode in the loop.

Step 4 — drop into Xcode to finish. Optional. Criteria for when it's worth it are below.

Step 5 — distribute via TestFlight or the App Store. Either a two-click submission from inside Rork, or an Xcode Archive upload.

The biggest divergence from the base product is Step 3. The whole signing-and-provisioning stumble moves later in the sequence, which visibly shortens the distance to "something a person can hold."

Step 1: Writing the Skeleton Prompt

Write 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 things matter. First, declare screen count and relationships up front, or helpful extra screens appear.

Second, specify the data model down to the types. Vagueness here is expensive later — SwiftData model changes drag migrations behind them, so a few minutes now buys back hours.

Third, keep the line "start minimal." Without it, animations and effects arrive uninvited and generation slows. Skeleton phase is a speed phase.

Given a free allowance of roughly five prompts a week, how specific you make this first prompt is how many experiments you get to run. Keep prompts in a local file and revise them rather than throwing each one away.

Step 2: Fixing UI with Screenshots

Once the skeleton runs, go screen by screen. The technique that pays: attach a screenshot of the preview.

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

Split "current issues" from "requested fixes" as two bulleted blocks. Screenshot plus structured feedback lands far more accurately than prose alone.

The recurring miss is the vague brief — "make it more modern." Something will change; it rarely matches your intent. Give parameters: points, colors, positions.

Step 3: Check It on Hardware

Rork Max hands you a QR code that installs to your iPhone. The streamed simulator and a real handset differ in scroll feel and safe-area handling, so run this early.

The first thing hardware taught me was the bounce at the end of a list scroll. Smooth in preview; catching under an actual thumb. No metric surfaces that — you have to touch it.

Step 4: Deciding Whether to Drop into Xcode

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

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

Drop into Xcode for tweaks that resist description, and for edits to one part of existing code. "Make this button's tap animation a 0.3s easeOut" is quicker to write than to explain. Same when you want a surgical change: ask by prompt and the surrounding code often gets rewritten along with it.

If you do descend: set your Apple ID as Team and give Bundle Identifier a unique string (for example com.yourname.bookapp). Skip that and you'll meet "No matching profile found." After installing to the device, go to Settings → General → VPN & Device Management and trust your Apple ID — the "installs but won't launch" symptom is almost always this.

For a local dev server, add NSAllowsLocalNetworking under NSAppTransportSecurity in Info.plist. Generation assumes production, so local-dev settings are yours to add.

Step 5: Two-Click Submission vs. the Xcode Route

Rork Max submits to the App Store in two clicks from inside the product. Skipping the signing and provisioning stage is the concrete value for a first-time shipper.

A shorter submission path doesn't shorten 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.

Taking the Xcode route instead: Product → Archive, then Organizer → Distribute App → App Store Connect → Upload, with the upload running a few to ten minutes. If the build 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.

Staying on the React Native Side Is Also a Choice

Everything above describes the Rork Max road, but the base product fits plenty of situations better.

You want Android at the same time. You want a web build too. You already own an Expo project and want to extend it. Any of those, and it's worth confirming the base product falls short before paying $200/month.

The thing to watch on that side 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 Rork Max 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 the one corrected at the top. While I treated Rork and Rork Max as the same product, I was applying SwiftUI steps to a React Native project. Of course it didn't work — and the real waste was attributing the failure to my own skill. Establish which exit you came out of first. That alone dissolved the problem.

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. Grow it three or four screens at a time.

Third: changing the data model late. Mid-flight SwiftData changes pull migrations along with them and stall you longer than you'd expect. Time spent on the model up front pays back.

For Your First Build

If this is your first iOS app, pick a small tool you genuinely 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 come into view — which is exactly what your next serious project needs.

Apologies to anyone who read this while the earlier premise was still in place. Thank you for reading.