How AI Generation Works
You describe an app. Thirty seconds later you're holding the real thing on your phone. Here's what happens in between — knowing the shape of it helps you write better prompts and read what AppX is doing as it builds.
AppX generates real Expo + React Native code — StyleSheet for styling, lucide-react-native for icons. Not a visual-builder export you can't touch, but actual code you can inspect, edit, and ship.
Plan → Generate → Validate
Every new app moves through three stages:
1. PLAN
The AI reads your prompt and works out:
- Which screens to build
- The data each screen needs and how it flows
- How navigation ties the screens together
↓
2. GENERATE
For each screen, the AI writes:
- React Native + TypeScript code
- StyleSheet styles + lucide-react-native icons
- The planned navigation and state
↓
3. VALIDATE
Every file is checked automatically:
- Syntax and imports
- No web-only elements that crash React Native
- Common issues auto-fixed; a screen that won't build is retried
1. Plan
Before writing a line of code, the AI produces a plan — the list of screens, the navigation shape (tabs, stack, or a mix), and the data model that connects everything. This is what keeps a multi-screen app coherent instead of a pile of unrelated screens.
In Plan mode you see this plan first and hit Execute when it looks right — a chance to course-correct before any credits are spent. In Direct mode AppX plans and builds in one go.
2. Generate
With the plan set, the AI writes each screen: complete TypeScript, StyleSheet.create styling, navigation hooks, and state. When a screen should remember data between launches, it wires up on-device storage.
Every generated app shares one consistent stack:
- Expo Router for file-based navigation
- StyleSheet.create for styling
- lucide-react-native for icons
- TypeScript throughout
The stack is fixed on purpose — consistent, validated output beats a different toolkit on every build. (AppX doesn't generate NativeWind or react-native-paper apps.)
3. Validate
Each file passes through automated checks before it ever reaches your phone: syntax, imports that actually resolve, no web-only elements like <div>, and a valid screen export. Common problems are auto-fixed in place; anything that still won't build gets regenerated. The result is that most issues are caught and repaired before you see the preview.
Refining by chat
Once your app exists, you shape it through conversation. Edits run a tighter, more surgical loop than a full build:
- The AI reads the target screen.
- It makes precise, targeted changes to just the part that needs to change — not a full rewrite.
- The change is applied and validated.
- If something's off, the AI sees the error and corrects it — those internal retries are part of the same turn.
- The result comes back to you, ready to keep or cancel.
Surgical edits are safer than rewrites: the AI touches only what you asked about, so the rest of your screen stays exactly as it was.
When you edit one screen, AppX sends that screen's full code to the AI and only short summaries of the others. You get accurate edits without paying for context the AI doesn't need — which is why edits feel quick.
When something fails
If the AI can't produce working code for a screen, AppX tells you in the chat panel — and you aren't charged for a screen that didn't land (failed screens are refunded automatically). Usually a quick nudge ("the build failed on an import error — try again") gets it through on the next pass.