Where Rork Max Still Falls Short — A Realistic Line Around Native Generation

When you hear "write plain text and a native app comes out," it sounds as if nothing is left for you to do. Actually using Rork Max, that impression turned out to be half right and half under-stated. What it does well and what still needs my own hands separated more clearly than I expected. So here I want to lay out, honestly, how far it reaches today and where it stops — neither as praise nor as disappointment.

For context, Rork Max generates native Swift apps rather than React Native, and its targets include Apple Watch and Vision Pro on top of iPhone and iPad. Submission to the App Store runs in a short set of steps. Precisely because of that, knowing what happens just before that step saves you from being let down.

What it does well, and where I trusted it

Start with the parts I could hand over comfortably. Ordinary UI — standard navigation, lists, forms, settings screens — came together from plain-text instructions with surprising ease. Features that stay inside the standard frameworks ran with almost no edits to the generated Swift. As an indie developer at Dolice, I tried having it build a small settings screen for one of my wallpaper apps, and a few tweaks to color and layout were enough to reach a usable starting point.

Where human hands are still needed

There were also parts I couldn't fully delegate. Fine custom expression — elaborate rendering with Metal, or the polish of a delicate animation — reached "roughly right" but needed my edits to get the exact feel I wanted. Detailed branching in background behavior, and careful permission flows, are also areas where leaving it to generation tends to leave gaps. Here I found it faster to add the finishing touches myself to the generated foundation than to go back and forth refining the instructions.

Here is one concrete example around permissions. An app that touches HealthKit needs NSHealthShareUsageDescription (an explanation of why you need the data) in Info.plist, plus an authorization request at runtime. The generated screen does include the button that asks for authorization, but the "unhappy path" design — how to gracefully degrade the feature when the user denies it, and how to surface a way to re-enable it later in Settings — is easy to miss.

// The generated code covers the authorization request, but the denial fallback
// is usually something you have to add yourself.
healthStore.requestAuthorization(toShare: [], read: readTypes) { granted, _ in
    guard granted else {
        // Easy to miss when left to generation: disable the feature and offer a
        // fallback such as manual entry.
        DispatchQueue.main.async { self.showManualEntryFallback() }
        return
    }
}

Precisely because the happy-path screens come out cleanly, you want to reserve your own time for the denial, failure, and re-authorization branches.

One more honest note: "publish in two clicks" does not make review disappear. Shipping to the App Store still requires an Apple Developer registration, and a rejection means the round trip of fixing and resubmitting. A shorter path to submission and the absence of review are two different things. Conflate them and you stumble at the final step.

Three questions to spot the limit before you start

Before I start building, I use three questions to roughly sort whether a screen is on the "can-delegate" side or the "needs-hands" side.

1. Does the screen hold together with standard framework parts only? A mix of lists, forms, and settings is almost fully delegable.
2. Does it touch hardware or OS permissions (camera, location, HealthKit, notifications)? If so, I estimate on the assumption that I will design the denial fallback and the re-authorization path myself.
3. Is custom feel (Metal rendering, fine animation, haptics) the core of the experience? If it is the core, I treat generation as a base layer only and set aside time for the finishing work up front.

The more "yes" answers pile up across these three, the shorter the delegable distance and the more hand-work you take on. Conversely, if all three lean toward "no," it is a screen where you can take Rork Max's speed as-is. Color-coding this at the estimation stage keeps you from being surprised later by work that took more than you thought.

How to view the $200/month tier

Rork Max sits at the $200/month tier. Whether that price feels high depends on how seriously you use the features only native can reach. If you are only building an app with standard UI, ordinary Rork or another route is enough. If you want to step into experiences specific to Apple's devices, the value of a shorter on-ramp to them appears. I think it causes less regret to first decide on one concrete experience you want to build, and then choose the tier. Start from the price and you tend to carry features you never needed.

My own conclusion

After about two weeks, my honest read is that today's Rork Max is less "magic that spits out a finished product from zero" and more "a partner that stands up the foundation in one go." Hand it the ordinary UI; keep the custom polish and the final publish decision for yourself. Seen through that split, the distance a non-engineer travels to a first working shape genuinely shrinks. Over-expecting and then feeling let down, or dismissing it outright, are both a waste. Take one small app all the way to just before publishing, and this line will settle into your own sense of things. Thank you for reading.