Rork Max delivers a working SwiftUI native app in remarkably little time. The moment you aim for "ship it on the App Store and keep updating it," an entirely different game begins. Generation quality is high until, one afternoon, a spec change rips through the project. A review rejection arrives and you cannot tell where to start fixing. The sustainable workflow looks nothing like the prototyping workflow.
This playbook is the production setup I have converged on while shipping and maintaining real apps on Rork Max. It is not a feature tour — it is the judgment calls that make solo development repeatable.
Three principles before anything else
1. Spec-first or not at all
Once you are past "does it work?", stop chatting your way to an app. Write the spec yourself and feed it to Rork. Improvised requests leak into the codebase as technical debt that only surfaces at the worst moments.
A usable spec is just three sections: screens, data model, non-functional requirements. Keep it in a Markdown file and paste it at the top of every Rork chat.
2. One concern per diff
After the app is running, the most dangerous thing you can type is a compound request: "refactor login, polish profile, and fix that bug while you're there." The cross-file edits stop being reviewable. My hard rule: one screen or one feature per chat message. Break it and lose half a day ninety percent of the time.
3. Assets and legal prep start on day one
Icon, screenshots, privacy policy, terms of service, review materials — these are the things you absolutely do not want to improvise the day before submission. Prepare the templates the same day you write the spec.
Phase 1 — design before touching Rork
The first hour of a new project is spent in a text editor, not in Rork.
A spec template that earns its keep
# {App} Spec v1
## Positioning
- Target: {...}
- One-line pitch: {<=50 chars}
## Screens
- Home: {what is shown, what actions}
- Create: {...}
- Detail: {...}
- Settings: {...}
## Data model
- {Entity1}: {field1 (type)}, ...
## Non-functional
- iOS 17+
- Offline-first: required / not
- Sync: iCloud / server / none
- Monetization: one-time / subscription / ads
## Submission prep
- Privacy policy URL: (WIP)
- Terms URL: (WIP)
- PII collected: {none / device ID / email / ...}Paste this into every Rork chat about the project. The prompt stops drifting. Later changes become "add the following to v1 spec," which Rork handles cleanly.
A realistic screen budget
Solo Rork Max v1 releases stay reliable under eight screens. Past that, the regeneration-and-modify loop starts producing cross-screen breakage. Push the ninth screen to v1.1.
Phase 2 — staged generation
Spec in hand, generate in order:
- Data model and persistence first. "Implement the data model and SwiftData persistence from the spec. No UI yet."
- Navigation skeleton with placeholder screens wired up.
- One screen at a time, Home → Detail → Create.
- Settings, auth, side flows after the core loop is stable.
This ordering prevents 70% of the "oh no, the whole thing needs a rewrite" moments later.
Commit snapshots outside Rork
Rork has built-in versioning, but at every milestone I also export the project and push to my own GitHub. When internal rollbacks cannot recover, git history is the lifeline. Milestones for me: each completed screen, and each non-functional requirement met.
Phase 3 — diff discipline
The delicate phase. Break the discipline, break the app.
Diff request template
## Change request v{n}
### Scope
{one screen or one feature} only
### Problem
{concrete description, screenshots}
### Expected behavior
{bulleted and specific}
### Do not touch
- other screens
- data model
- navigation structure
### Success criteria
{what makes this change mergeable}
Yes, writing this every time feels like overkill. It takes two minutes. The cost of a cross-screen accident is far larger. Save it as a snippet.
No diff merges without a diff review
Every change Rork produces gets inspected as a diff before merge. Never just read the prose summary. A non-trivial fraction of Rork's summaries do not match the actual change — and those mismatches come back to bite you during review.
Phase 4 — App Store submission prep
Submission checklist
- [ ] Icon (1024x1024 + all sizes)
- [ ] Screenshots (iPhone 6.9", iPad 13", Apple Watch if applicable)
- [ ] Privacy policy URL (live)
- [ ] Terms of service URL (live)
- [ ] App Privacy disclosures in App Store Connect
- [ ] Keywords (100 chars, EN and JA)
- [ ] Description (under 4,000 chars)
- [ ] Support URL (live)
- [ ] Review account credentials if login required
Prepare these alongside the spec. Leaving them for submission day is how solo launches slip by a week.
Localization from day one
Even for solo apps, Japanese + English out of the gate can pay off in unexpected ways (the international long tail is real). Tell Rork at the start: "Externalize all UI strings via Localizable.strings in both English and Japanese." Retrofitting localization after the fact is miserable.
Phase 5 — when the review rejects you
It will happen. The cost of rejection is not the fix; it is the hours you lose trying to figure out what Apple meant.
Feed the full rejection verbatim
Paste the rejection message into Rork unedited, in English, and ask: "Propose code changes addressing this rejection, plus a draft response to the reviewer." Summarizing destroys nuance — and Apple is specific.
A reviewer response that tends to get through
Dear App Review Team,
Thank you for your careful review. We have addressed the concern
regarding {issue name} as follows:
1. {concrete change 1}
2. {concrete change 2}
The relevant code changes are in the latest build {build number}.
Please let us know if any further changes are required.
Best regards,
{Your Name}
A professional tone from a solo developer tends to shorten the next review turnaround. Anecdotal, consistent in my experience.
The rejections I keep seeing
4.3 Spam. Similar-app rejections. Differentiate explicitly in the description and inside the app.
5.1.1 Privacy. App Privacy disclosures must be accurate. Permissions you are requesting but not truly using (location, photos) will sink the submission.
2.1 Performance. Hands-on real-device test for 10+ minutes — launch, nav, background-restore — before every submission. Rork Max's generation occasionally leaves crashy edges that only manifest on real hardware.
Phase 6 — life after launch
Update cadence
For the first month post-v1, I avoid new features and stick to bug fixes and polish. Real user feedback over a few weeks sets the v1.1 direction far better than my own post-launch excitement.
Crash reports are free signal
Weekly sweep of App Store Connect crash reports. When something appears, paste the full stack trace into Rork: "Propose a fix for this crash plus verification steps." You get both, instead of a fix without a plan to confirm it.
Cost discipline
Rork Max is a tool, not a budget-free engine. I cap monthly generation volume; if I hit the cap, new feature work pauses and I switch to manual maintenance. Indie longevity is a cost-control problem as much as a code problem.
Closing thought
Rork Max's promise — build a SwiftUI native app fast — is real. The gap between "fast prototype" and "shipped, maintained App Store product" is closed outside the tool: with a spec, with diff discipline, with review practice, with maintenance hygiene. None of it is exciting. All of it is what makes indie development sustainable.
Start with the spec template. Write one. Paste it at the top of your next Rork conversation. The change in how the project feels within a week will make the rest of this guide easy to adopt.