◉RORK LABJP
●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Articles/Dev Tools
⬡ Dev Tools/2026-06-19Intermediate

Rebuilding Rork's Generated Form Screens for Real Use: react-hook-form and zod

Rork's generated forms look fine on screen but fall apart on a real device: the whole screen re-renders on every keystroke, the keyboard hides the submit button, and slow networks invite double submits. Here is how I rebuild them with react-hook-form and zod, from an indie developer's point of view.

Rork611React Native242formsreact-hook-formzod

✦ Premium Article

Ask Rork to "build me a login screen" and you get a working screen in seconds. As an indie developer running wallpaper apps under the Dolice name, I often let Rork draft the settings and feedback forms for my apps. But I have never shipped one of those generated forms to the App Store as-is. The reason is simple: the generated code is a valid screen, yet it is not a tool you can comfortably use with your thumbs.

In practice, the screen flickers on every keystroke, the keyboard covers the submit button on a real iPhone, and a slow connection lets the user tap submit twice. This is less about Rork being wrong and more about the division of labor where AI lays the foundation and a human does the finishing. What follows is how I rebuild a generated form with react-hook-form and zod, along with the reasoning behind each decision.

Three ways a Rork-generated form breaks

A freshly generated form usually looks like this: one useState per field and a single validation pass when the button is pressed.

// The naive form Rork tends to output (it has problems)
function LoginScreen() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [error, setError] = useState("");
 
  const onSubmit = async () => {
    if (!email.includes("@")) {
      setError("Email format is invalid");
      return;
    }
    if (password.length < 8) {
      setError("Password must be at least 8 characters");
      return;
    }
    await signIn(email, password); // runs multiple times if tapped twice
  };
 
  return (
    <View style={{ padding: 16 }}>
      <TextInput value={email} onChangeText={setEmail} placeholder="Email" />
      <TextInput value={password} onChangeText={setPassword} secureTextEntry placeholder="Password" />
      {error ? <Text style={{ color: "red" }}>{error}</Text> : null}
      <Button title="Sign in" onPress={onSubmit} />
    </View>
  );
}

This implementation hides three problems that only surface on a real device.

The whole screen re-renders on every character

Each useState update re-renders the component that owns it (here, the entire LoginScreen). With two fields you will not notice, but as fields grow to five or six and validation and derived UI pile on, a heavy re-render fires on every keystroke and input starts to feel a beat behind. In my experience the lag becomes obvious on item-heavy forms like settings screens.

The keyboard hides the submit button

A screen that simply stacks Views gets its lower half covered when the software keyboard appears. The moment a user focuses the password field on an iPhone, the submit button disappears, and they cannot press it until they dismiss the keyboard. That extra step causes drop-off right at the finish line.

The button can be tapped twice mid-request

onSubmit is async, but nothing records that it is in flight. On a slow connection the user feels "nothing happened" and taps again. The same request runs twice, which means duplicate sign-ups for account forms and double charges for purchase flows.

Why react-hook-form and zod

Formik and hand-rolled hooks are options, but I recommend the react-hook-form plus zod pairing, for three reasons.

First, react-hook-form keeps input values close to uncontrolled internally, avoiding full-screen re-renders. Second, with zod you write the schema once and both your TypeScript types and your validation derive from the same definition, so they never drift apart. Third, both libraries are light and drop straight into the Expo project Rork hands you.

Add them at the root of your exported project:

# At the root of the project you exported from Rork
npx expo install react-hook-form
npx expo install zod @hookform/resolvers

@hookform/resolvers is the adapter that bridges a zod schema into react-hook-form. Forget it and validation never runs, so install it up front.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦Diagnose the three ways a Rork-generated form breaks on a real device (full re-render, keyboard overlap, double submit) so you know what to fix first
✦Build a reusable component that wraps each TextInput with react-hook-form's Controller and a zod schema
✦Finish a login screen to production quality, including the iOS/Android KeyboardAvoidingView gap and routing server errors back to the right field
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

Related Articles

⬡ Dev Tools2026-09-04
EAS secret visibility does not keep a value out of your app — deciding prefix and visibility separately
The EXPO_PUBLIC_ prefix decides what ships inside your app; EAS visibility decides who can read it. Why stacking them blanks a value on OTA updates, and how to check your build.
⬡ Dev Tools2026-08-22
Every bulk replace exited zero. The damage was in the lines I did not delete
Run a bulk replace over generated code and the breakage lands on the neighbouring lines, not the matched ones. Here is what broke in a live project, and a dependency-free guard that checks the invariants a replace must preserve.
⬡ Dev Tools2026-08-14
Find the native edits expo prebuild will erase before you upgrade to SDK 57
Expo SDK 57 makes expo prebuild clear and regenerate ios and android by default. Here is how to audit your hand edits first, move them into config plugins, and why 57.0.9 matters for Reanimated apps.