The first few days with Rork feel almost magical. You write a prompt, and a working app screen appears. Buttons respond. Data gets saved. Watching it happen still doesn't feel entirely real, even after you've done it a dozen times.
Then, around the end of the first week, reality kicks in. "Why isn't this working the way I imagined?" "What do I do when the AI just... stops making sense?" The excitement is still there, but it's mixed with something that feels suspiciously like confusion.
Having built several apps with Rork and watched many other developers navigate the same learning curve, I've noticed that beginner struggles tend to cluster around three specific patterns. Here's what those walls are, why they happen, and — more importantly — how I actually got past each one.
Wall #1: Prompts That Don't Generate What You Had in Mind
This is the most universal early frustration. You ask for "an app where users can save notes," and what you get back is missing half the features you pictured, or the layout looks nothing like what you imagined. After a few rounds of follow-up prompts, you either get something that works or you end up with something more broken than when you started.
Why It Happens
Rork's AI is genuinely capable, but it can only work with what's written down. When you think "notes app," your mind automatically fills in layers of detail — categories, a search bar, a swipe-to-delete gesture, a confirmation dialog, timestamps on each entry. The AI doesn't have access to that mental image. It only has your words.
The gap isn't a capability problem. It's an information problem. And once you understand that, fixing it becomes straightforward.
How to Get Past It
I started treating prompts more like I was writing a product specification — not an elaborate one, just detailed enough that someone who had never seen my idea could build it accurately. These three elements make the biggest difference:
① Describe each screen explicitly
- Home screen: list of notes showing title and creation date,
floating add button in the bottom right corner
- Detail screen: three input fields (title, body text, category),
save and delete buttons in the top right
- Category selector: dropdown with three options — Work, Personal, Ideas
② Give behavioral examples for key interactions
- Tapping the add button opens the detail screen in create mode (empty fields)
- Tapping a list item opens the detail screen in edit mode (pre-filled)
- Tapping the delete button shows a confirmation dialog:
"Delete this note?" with Cancel and Delete options
③ Add a one-sentence design direction
- Clean, minimal aesthetic with a light gray-based color palette,
system font throughout
That level of specificity noticeably improves the output. You don't need to write a perfect spec on the first attempt — in practice, generating a first version and then iterating with follow-up prompts ("move the add button to the top right," "make the title text larger," "add a timestamp to each list item") works better than trying to get everything right in one shot.
The mindset shift that helped me most: stop thinking of Rork like a vending machine where you insert a request and receive a finished app. Think of it more like working with a skilled contractor who needs clear instructions. You're building toward the final product through multiple rounds of communication. Once I embraced that, the frustration from imperfect first drafts disappeared almost entirely.
Wall #2: Works in Rork Companion, Breaks on a Real Device
You test everything in the Companion app and it looks great. You build it to your actual iPhone and things start going wrong — features don't work, the app crashes, data doesn't load. This was the most confusing wall for me personally, because the same code was suddenly behaving differently.
Why It Happens
The Rork Companion runs in an environment similar to a simulator. On a real physical device, anything that requires OS-level permissions — camera, location, push notifications, microphone, photo library — gets controlled by iOS in ways the Companion doesn't fully replicate. Network environment differences, missing API key configurations, and HTTP/HTTPS mismatches are the other common culprits.
It's not a Rork bug. It's just the difference between a development preview and a production build running on actual hardware.
How to Get Past It
When something breaks on a real device, these are the first three things I check:
① Permission strings in the config file
If your app uses the camera, NSCameraUsageDescription must exist in app.json. The same principle applies to location (NSLocationWhenInUseUsageDescription), the photo library (NSPhotoLibraryUsageDescription), and the microphone (NSMicrophoneUsageDescription). When you prompt Rork to "add a camera feature," these strings don't always get written automatically.
// Add inside infoPlist in app.json
"infoPlist": {
"NSCameraUsageDescription": "Used to capture photos for your profile picture",
"NSPhotoLibraryUsageDescription": "Used to select images from your photo library"
}Without these, iOS simply blocks the feature and shows no error — the permission request never appears, which makes the root cause hard to diagnose.
② Environment variables and API keys
If your code references process.env.EXPO_PUBLIC_API_KEY or similar variables, those need to be configured in your EAS Build settings — not just stored locally. Keys that resolve correctly in the Companion won't automatically be bundled into a production build unless you've explicitly added them.
③ HTTP vs HTTPS for API requests
iOS enforces App Transport Security by default, which blocks unencrypted HTTP requests. If you're calling any external API, check that the URL starts with https://. This catches more people than you'd expect, especially when using third-party APIs where someone else chose the endpoint URL.
The framing that finally helped me get comfortable with this stage: real device testing is where you find bugs — that's its job. Expecting everything to work immediately on a real device puts you in the wrong mental state. If you treat the Companion build as a design and logic prototype, and the EAS build as the bug-discovery phase, the frustration when things break shifts into something closer to productive problem-solving.
Wall #3: App Store Review Rejection
This one hits differently. After everything you've built, tested, and refined, you submit for review, wait several days, and receive a rejection notice. The discouraging part is that most rejections are preventable once you know what reviewers are actually looking for.
In my experience, rejections tend to fall into a handful of predictable categories. Knowing them in advance is most of the battle.
Common Rejection Reasons and How to Handle Them
① Guideline 4.0 — Design: app appears incomplete
Submitting a Rork-generated app in its default state — without any additional polishing — can result in a rejection for looking unfinished. Reviewers flag placeholder text, obviously generic icons, and screens that appear to be works in progress.
Before submitting, verify:
- Your app icon is a properly designed, 1024×1024px image (not the default placeholder)
- No text like "Enter description here" or "Sample text" remains anywhere in the app
- Demo data or test content isn't visible on screens a reviewer would encounter
② Guideline 2.1 — Performance: the app crashes during review
If the app crashes while a reviewer is testing it, rejection is essentially guaranteed. There's a specific trap that catches a lot of first-time submitters: if your app requires a user account, you must provide valid demo login credentials (email and password) in the "Notes for Reviewer" field in App Store Connect. Without this, the reviewer can't access the app's main functionality, and Apple treats that as a functional failure.
③ Guideline 5.1.1 — Data Collection and Storage
Any app that collects user data needs a valid, accessible privacy policy URL linked in the App Store Connect listing. You also have to accurately declare what types of data you collect in the privacy nutrition label section. If you added authentication to your Rork app, make sure email addresses are included in your data declarations. It's an easy thing to forget and a common rejection reason.
My habit before every submission: I spend thirty minutes reading through the relevant sections of Apple's App Store Review Guidelines. Once you've read them a few times, the check becomes quick — you start recognizing patterns and catching potential issues before a reviewer does.
One More Thing About Rejections
Getting rejected doesn't reset the clock entirely — you can respond to most rejection notices, fix the issue, and resubmit without losing your place in the queue. The key is reading the rejection message carefully and addressing exactly what it says, rather than making broad changes and hoping for the best. Apple's reviewers are generally consistent about what they flag, so a clear, targeted fix usually gets through on the next attempt.
The Pattern Behind All Three Walls
Looking back, all three walls came down to the same root cause: insufficient information — on my end. Not enough specificity in prompts, not enough knowledge about how real devices handle permissions, not enough familiarity with App Store guidelines. That means they're all solvable. And they compound: each one you get through makes the next one easier because you're building a working mental model of how the whole pipeline actually works.
If you're just getting started with Rork, Building Your First App in 30 Minutes is the best place to begin. For the complete App Store submission process from start to finish, The Complete App Store Publishing Guide walks through every step in detail.
The thing I most want to leave you with: when you hit any of these walls, resist the impulse to interpret it as evidence that Rork isn't for you, or that app development is beyond your reach. Nearly every Rork developer has been through all three of these moments. They're normal parts of the learning process, not signs that something is fundamentally wrong with you or your project.
Keep going. The app you're trying to build is more achievable than it probably feels right now.