Pushing Rork Max's AI Beyond Vibe Coding — Patterns That Actually Improve Implementation Quality

Context Management — Surviving Long Sessions

Long Rork Max sessions accumulate context fast. Without management, the back half of a session forgets decisions made in the front half.

Three Rules

Rule 1: Put the project rules in agents.md.

Drop a markdown file at the project root with everything the AI should always remember.

# Project Brief
 
## Stack
- React Native / Expo SDK: paste the values straight from package.json (the expo and react-native lines)
- Hermes v1 (performance-first)
- TypeScript strict mode
- Tailwind / NativeWind
 
## Design Principles
- Generous spacing, visually quiet
- System font
- Monochrome with one accent color
 
## Coding Rules
- One responsibility per function
- Comments in English
- Always handle errors explicitly

The AI consults this at the start of every conversation, so consistency holds even in long sessions.

Rule 2: Split big features across separate sessions.

"Build the auth flow" and "wire up payments" deserve their own sessions. A clean context at the start sharpens the AI's judgment.

Rule 3: Persist key decisions in a file.

Decisions like "we picked RevenueCat for purchases" or "Supabase for storage" need to survive across sessions. Keep them in a decisions.md you can drop into new sessions as context.

Quirks and Workarounds

A few patterns that show up regularly.

Quirk 1: Slightly stale package versions

The AI defaults to versions from training. With React Native or Expo moving fast, you sometimes get code that does not work on the latest version.

Workaround: take the versions from your own package.json, not from memory. I once wrote a note pairing an SDK release with a React Native version from memory; the pairing did not exist, and dependency resolution ate half a day. Since then I paste the output of one line into the prompt.

grep -E '"(expo|react-native)"' package.json

When code fails, point out the API change explicitly: "this library renamed XX in the current version, please rewrite using the new form." The official Expo SDK table is the reliable place to confirm which versions belong together.

Quirk 2: Inconsistent state management

You start with Zustand, and three features later it suggests Redux.

Workaround: pin "all state via Zustand" in agents.md.

Quirk 3: Loose TypeScript types

any shows up under pressure.

Workaround: "Use TypeScript strict mode and avoid any." Slightly verbose, less painful than fixing types later.

Adding AI to the App Itself — On-Device ML vs. Cloud API

Everything above was about using Rork Max's AI to build the app. The moment the app itself needs an AI feature — image recognition, a chatbot — the implementation splits into two paths: on-device ML that runs inference on the phone, and cloud AI APIs that send the request to OpenAI or Gemini. I don't choose by which is "better," but by which one the feature fits.

Here is how the trade-offs line up.

As a rough rule, I keep privacy-sensitive, low-latency basics on-device, and accuracy- or knowledge-heavy features in the cloud. Simple photo classification runs on the phone; understanding free-form user input goes to the cloud. Using both together is fine. As an indie developer shipping on my own budget, that split is also what keeps API bills predictable.

A Minimal On-Device Setup in React Native

With React Native + Expo you can load a model and run inference with TensorFlow.js. Two things matter: wait for the backend to initialize before inference, and dispose every tensor once you're done — forget that and a long session slowly eats memory.

src/utils/onDeviceModel.ts

import * as tf from '@tensorflow/tfjs';
import '@tensorflow/tfjs-react-native';
 
let model: tf.LayersModel | null = null;
 
export async function loadModel(modelUrl: string) {
  if (model) return model;
  await tf.ready();              // wait for the backend to initialize
  model = await tf.loadLayersModel(modelUrl);
  return model;
}
 
// pass a normalized 224x224x3 image array and classify it
export async function classify(pixels: number[]): Promise<number[]> {
  const m = await loadModel('https://your-cdn.example/model.json');
  const input = tf.tensor(pixels, [1, 224, 224, 3]);
  const output = m.predict(input) as tf.Tensor;
  const scores = Array.from(await output.data());
  tf.dispose([input, output]); // free tensors to protect memory
  return scores;
}

Map the top-scoring index to a label and photo classification or tagging runs entirely on the device. No network call means it is safe both offline and on privacy.

Calling a Cloud API Safely — Never Ship the Key

There is one rule you cannot bend with cloud AI: never put your OpenAI or Gemini API key in the app code. App binaries can be inspected, so an embedded key eventually gets pulled and someone else spends your API budget.

The correct shape is a thin backend of your own that relays the call. The key lives only on the server; the app calls your backend with a user auth token.

src/services/aiClient.ts

import * as SecureStore from 'expo-secure-store';
 
const BACKEND = 'https://your-backend.example/api';
 
export async function askAI(prompt: string): Promise<string> {
  const token = await SecureStore.getItemAsync('auth_token');
  const res = await fetch(`${BACKEND}/ai/chat`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token ?? ''}`,
    },
    body: JSON.stringify({ prompt }),
  });
  if (!res.ok) throw new Error(`AI request failed: ${res.status}`);
  const data = await res.json();
  return data.reply;
}

Your backend calls OpenAI or Gemini and returns only the result. With this in place you can swap models or add rate limiting later without touching app code. You get both a key that never leaks and operational flexibility.

When you ask Rork Max to build this, adding one line — "relay the API key through a backend, never embed it in the app" — gets you a safe scaffold from the first try.

Plain Rork or Rork Max — Where the Decision Splits

Everything above works almost unchanged whether you build on plain Rork (the React Native + Expo path that ships cross-platform) or on Rork Max, which emits native Swift. But the foundation you pick sets the ceiling of what the app can ever become.

After running several apps solo, the first thing I decide is one question: does this app reach into Apple's hardware or OS-level features? If it does not, staying on plain Rork and holding both iOS and Android at once is by far the better deal. If it does, I consider Rork Max for that part only.

Laid out as a table, the call looks roughly like this.

For a solo developer, $200 a month is not a rounding error. My test is whether a native capability worth dropping Android for sits at the center of the app. If widgets or Live Activities are the star of the experience, Rork Max's directness easily pays for itself.

But for an ordinary list-style or content-reading app, where the reason is "I might use it someday," staying on plain Rork and chasing both stores wins on total revenue in my experience. Giving up Android from the start is a bigger decision than it first looks.

When unsure, build the skeleton on plain Rork and switch to Rork Max only once you know a native feature is truly required. That order spills the least money and time.

Building Without Burning Credits

Use Rork Max for a while and you will be surprised, at least once, by how fast credits drain. User reviews through 2026 echo the same "consumption is heavier than expected" note. Early on, I melted plenty of credits by regenerating the same thing over and over.

The key to cutting waste is turning "regenerate" into "patch."

The highest-leverage move is pinning your assumptions in agents.md so you stop restating them (as covered earlier). Just keeping the stack and state-management choice from drifting visibly reduces how often you rebuild from scratch.

Next is how you hand back broken code. Send only "it's broken, fix it" and the AI tends to rebuild a wide area, eating credits as it goes. Instead, hand it the exact error message plus the file and line.

This error stops the build. Fix only the spot below.
Do not change any other files.

ERROR: undefined is not an object (evaluating 'route.params.id')
  at TaskDetail.tsx:18

That one line — "do not change any other files" — is the quiet lever that holds back needless regeneration.

Finally, do not ask for large features in one shot. The step-by-step prompting from earlier pays off not just in quality but in credits. Ship small, verify, move on. The smaller each generation, the smaller the loss when it misses.

Checking AI-Written Native Code Before You Ship

Code the AI produces can run and still not be in a shippable state. When I first started submitting apps to the App Store, I caught rejection after rejection. Most were not about whether the code ran — they were about skipping the checks before submission.

Before publishing an app I had Rork Max build, I verify at least these three things by hand.

First, no API keys or tokens embedded directly in the code. As covered earlier, keys belong behind a backend, but the AI sometimes hardcodes one in a "just make it run" form. A single mechanical scan before submission buys peace of mind.

# Scan for key-like strings before submission
grep -rEn "sk_live_|AIza[0-9A-Za-z_-]{10,}|AKIA[0-9A-Z]{16}" src/ \
  && echo "Found a key-like string. Move it behind a backend." \
  || echo "No hardcoded keys found."

Second, whether permission purpose strings read naturally in every language you support. If you use the camera or location but the purpose text is empty or left in English, that alone earns a rejection.

Third, the first-launch path. The AI tends to build screens that assume an already-signed-in user, so the empty states and errors of a brand-new install fall through the cracks. Open it once, end to end, on a freshly installed device. That is the check that catches the most.

None of this is glamorous work. But these quiet few minutes prevent the multi-day loss of a review round trip. The faster you let AI build, the more the final human check is worth — that is how it feels to me.

Why I Stay With Rork Max

Three reasons keep me coming back as a solo developer who writes about this work:

First, idea to running on a real device in hours. That is the single most important feedback loop in indie development.

Second, support through the boring native-app config — push certificates, in-app purchase setup, TestFlight submission. Web app builders skip this entirely; Rork Max meets you in it.

Third, the generated code stays as a real React Native + Expo project. Even if you stop using Rork Max, you still have a codebase you can maintain by hand. That portability is a kind of insurance.

Next Step

If you want to push Rork Max further, the highest-leverage starting move is creating a short agents.md for your project. Write down the stack, the design principles, and the coding rules you want enforced. Output consistency improves immediately. Once that habit is in place, layering the three prompt patterns above is what takes the quality further.