The question I hear most often from people new to Rork is some version of: "What's the difference between Rork and Rork Companion?" It's a reasonable confusion — the two are tightly related but serve different functions. Getting clear on the distinction changes how effectively you use both.
Rork vs. Rork Companion: The Actual Difference
Rork is the code generation engine. You give it a description and constraints, it produces SwiftUI or Kotlin Compose code. It's powerful but narrow — you need to know what you want before you ask.
Rork Companion is everything around that process. It's the conversational AI layer that helps you figure out what to build, works through your generated code with you, diagnoses errors, and explains what the code is doing. If Rork is the engine, Companion is the navigator.
The practical consequence: Companion is where most of the work happens before you ever ask Rork to generate anything, and it's what you reach for after generation when something doesn't work the way you expected.
The First 10 Minutes: Turn a Vague Idea Into a Spec
When you open Companion, don't worry about having a polished idea. Start with what you actually have:
I want to build a running tracker app. The apps I've tried have too many
features — I want something minimal. Not sure exactly what that means yet.
Companion will respond with clarifying questions, not generic advice:
- What information do you want to record per run? (distance, time, route, pace?)
- How do you want to use historical data? (weekly graphs, personal records, just a list?)
- Do you need integration with Apple Watch or other wearables?
Answering these takes about 10 minutes. What you end up with is concrete: "Record distance and time only. Weekly summary graph. Apple Watch companion for the active session. No GPS route recording for now."
This conversation before code generation isn't optional overhead — it's the step that determines whether Rork produces something close to what you wanted or something you have to substantially revise. Developers who skip straight to Rork without using Companion for spec refinement consistently report more revision cycles.
Design Phase: Screens and Data Model
Once the feature list is settled, Companion can walk through the screen architecture:
Based on what we discussed, suggest a screen structure.
I want to keep it to the minimum needed.
A typical Companion response:
For a minimal running tracker, three screens work well:
1. Home — Start run button, summary of last 7 days
2. Active Run — Live elapsed time and distance, stop button
(Apple Watch companion mirrors this screen)
3. History — List of past runs, weekly distance total
HealthKit write happens in the background from the active run screen —
no separate screen needed for that.
Push back on anything that doesn't fit: "Add a weekly chart to the home screen instead of the 7-day summary." Companion updates the design accordingly. The back-and-forth here is exactly what you'd have with a human collaborator during a design session.
Once the screen structure is agreed on, Companion can also help you think through data model — what needs to be stored, what can be computed, how it maps to SwiftData or Core Data. This is the input that makes your Rork prompt more precise.
Implementation Phase: What to Say When Something Goes Wrong
The most reliable Companion pattern during implementation is pasting the error message directly:
Getting this error when I build in Xcode:
Error: Value of type 'CLLocationManager' has no member 'requestLocation'
File: LocationManager.swift, Line: 47
Companion explains the cause (in this case, requestLocation being deprecated in favor of startUpdatingLocation for continuous tracking), shows the corrected code, and notes what else to check for related issues. You don't need to parse the error first — just paste it.
For understanding generated code:
I don't understand what this generated code is doing.
Specifically, why does it use @StateObject for one property and @ObservedObject
for another? When do I use which?
[paste the relevant code section]
Companion explains in the context of your specific code, not in abstract documentation terms. The distinction between "what @StateObject means in theory" and "what it's doing in this file, for this app" is where most of the learning happens.
For feature additions:
I want to add swipe-to-delete to the history list.
What's the best way to add that?
Companion gives you the implementation approach and, importantly, shows you how to phrase the request to Rork if you want it to generate the change: "Here's the prompt that would produce the right modification in Rork..."
When the Conversation Gets Long: Working With Companion's Memory
Within a single conversation, Companion responds with the earlier exchanges in mind. Not having to re-explain your app's purpose or screen layout every time is a real advantage.
That said, once a conversation runs long, the assumptions you set at the start tend to fade. I once told Companion early on that the target was "iOS 16 and up" with "no more than three tabs," only to be handed iOS 14-era code near the end — and I stopped short, a little deflated. Old instructions get washed downstream by the newer back-and-forth.
A few habits keep this from happening.
Put a "ground rules" note at the top of the conversation. Keep the target OS, the framework, and any non-negotiable constraints as a short bullet list, and restate it once at key moments. There's no need to belabor it — short, just the essentials.
Ground rules (do not change):
- Target: iOS 16+
- State management: SwiftUI standard (@State / @Observable)
- Up to three tabs
Refer to screens and files by the same name every time. Mixing "the settings screen" and "SettingsView" makes it easy for Companion to lose track of which one you mean. Settling on a single name noticeably sharpens the accuracy of your edit requests.
When the topic shifts substantially, just start a fresh conversation. Cramming a second app's questions into one thread blends the earlier context in and breeds off-target suggestions. If there's something worth carrying over, pasting a short summary of just those points into the new conversation is enough.
When you're juggling several apps in solo development, it's tempting to keep one conversation going forever. It's the same with running multiple blogs at Dolice Labs — drawing a clean line through the context turns out to be the faster, more accurate path.
What Companion Is Not Good At
Three limitations worth knowing before you hit them.
Deep performance debugging: If your app's list scrolling is janky, Companion can offer hypotheses, but diagnosing the actual cause requires Instruments — Xcode's performance profiling tool. Companion is good for explaining what Instruments shows you; it's not a substitute for running it.
Very recent API changes: Swift and SwiftUI update with each major Xcode release. Companion's knowledge has a training cutoff, so for anything released recently, verify against Apple's release notes. Companion is reliable for the established API surface; it's less reliable at the bleeding edge.
Visual design decisions: "What colors should this app use?" is outside what Companion does well. It can answer the question, but Apple's Human Interface Guidelines and your own aesthetic judgment will serve you better here. Companion is for code and architecture; design tools are for design.
How to Use Companion Most Effectively
The developers who get the most from Companion treat it as a genuine collaborator rather than a query engine. That means conversational messages rather than single-line commands, pushing back when the suggestion doesn't feel right, and asking "why" rather than just taking what's generated.
The clearest entry point if you haven't used it: open Companion and describe the app you've been thinking about building. Don't frame it as a technical spec — just explain the idea. The conversation that follows will tell you a lot about whether Rork is the right tool for what you have in mind, and it will produce the groundwork for getting the most out of Rork when you do generate code.