Prototype a mobile app with AI: a Claude Code workflow

To prototype a mobile app with AI, have your coding agent draw each screen state as a static HTML frame at phone size (390 x 844 is a common choice), link the frames by the taps that lead from one to the next, and review them before any native code changes. Once you have chosen what each screen should look like, the agent implements it with your real components, in React Native, SwiftUI, Flutter or a mobile web app.

This suits Claude Code well, because the prototype and the implementation become two separate steps, each easy to check.

Why prototype mobile screens before code

Mobile code is slow to iterate on. A change means a rebuild, a simulator or a device, sometimes a store review before users see it. A flow that looked right in a ticket turns out to need an extra step once you tap through it.

HTML frames are cheap. An agent can produce ten states of a sign-up flow in minutes, you can look at them side by side, and throwing one away costs nothing. The expensive decisions (what goes on which screen, in what order, what happens on error) get made on something disposable. Frames also give the rest of the team something to react to: a product manager or a client can say what is wrong with a screen far more easily than with a paragraph.

Set the frame size and the phone constraints

Tell the agent the size of every frame and the constraints of a real phone. Without them, frames tend to look like narrow desktop pages.

Setting	Typical value	Why
Phone frame	390 x 844 CSS px	Screen of the iPhone 12 to 14
Tablet frame	834 x 1112 CSS px	A common iPad size, if you support tablets
Status bar and home indicator	About 47 px at the top and 34 px at the bottom on those iPhones	The system draws over these areas
Touch targets	44 x 44 px or more for main actions	Easy to hit with a thumb
Primary actions	Lower half of the screen	Within reach of one thumb
Body text	16 px or more	Readable without zooming

For touch targets, the W3C sets 24 x 24 CSS pixels as the minimum in WCAG 2.2 Target Size (Minimum) (level AA), and 44 x 44 in the enhanced criterion (level AAA). Aim for the larger size on main actions.

List the screens and states first

Before any frame, ask the agent for an inventory: every screen, and for each one the states worth drawing. For a small habit tracker:

• Onboarding: welcome, notification permission explained, account created.
• Sign in: empty, filled, wrong password, offline.
• Home: first day (empty), a normal day, all habits done.
• Habit detail: current streak, streak broken, editing with the keyboard open.
• Settings: default, delete account confirmation.

Mobile adds states that desktop apps rarely have: the keyboard covering half the screen, a permission prompt, no network, a notification that opens a deep screen. Name them. The UI states checklist is a good base, and prototyping an onboarding flow covers the first screens in detail.

A prompt that produces useful mobile frames

Prototype the sign-in flow of this app as static HTML, one file per
state, each 390 x 844. States: empty, filled, wrong password,
offline. Use the real texts from src/screens/SignIn.tsx and the
colors from src/theme.ts. Self-contained HTML with inline CSS, no
scripts, system font stack. Keep controls out of the top 47 px and
the bottom 34 px, primary button in the lower half, touch targets at
least 44 px. Do not modify the app code. Then list the taps that
lead from one state to the next.

Three parts do most of the work: the size, the real texts and colors from your code, and “do not modify the app code”, which keeps prototyping and implementation apart. Self-contained HTML with inline CSS also means each frame renders the same wherever you open it.

Review at phone size

Frames judged on a large monitor mislead: everything looks spacious. Open each frame at its real size, or in your browser’s device mode, and ask a few questions:

• Can you reach the main action with one thumb?
• Does the longest realistic name or title fit on one or two lines?
• Is anything important hidden when the keyboard is open?
• Does each error say what to do next?

To look at many frames quickly, have the agent take screenshots with Playwright. Its device descriptors set the viewport, scale factor and touch support of a given phone. The iPhone 13 descriptor uses a 390 x 664 viewport, the screen minus the browser bars, so set it back to 390 x 844 or the bottom of each frame, where the primary button sits, is cut off:

import { chromium, devices } from "playwright";

const browser = await chromium.launch();
const context = await browser.newContext({
  ...devices["iPhone 13"],
  viewport: { width: 390, height: 844 },
});
const page = await context.newPage();
await page.goto("file:///tmp/proto/sign-in-empty.html");
await page.screenshot({ path: "/tmp/proto/sign-in-empty.png" });
await browser.close();

The Playwright emulation guide explains the device list and what each descriptor sets. Screenshot every screen of a web app with Playwright extends this to a whole app.

Start from the app you already have

If the app exists, prototype changes on top of how it looks today rather than from memory. When it has a web build that runs, such as a mobile web app or the web export of a cross-platform app, Playwright can open it at 390 x 844 and capture each state. Use a demo account and sample data: a screenshot shows whatever is on screen. Playwright drives browsers, so for an app that only exists as a native build, the agent draws the current screens as HTML from your code instead.

From frames to native code

When a flow is agreed, ask for the implementation one flow at a time:

Implement the sign-in flow as shown in the chosen frames, using our
existing components in src/components. Reuse the theme values, run
the type check and the tests, and tell me what you could not match
exactly.

The HTML is a reference, not code to paste. Layout carries over well, because React Native lays out with flexbox like the web, and SwiftUI and Flutter have row and column equivalents. Fonts, spacing and native controls still need the platform’s own components. Check the result in a simulator or on a device, next to the frames.

Keep the frames after the implementation. When a bug report says a screen looks wrong, the chosen frame is the reference for what right means, and the next change starts from it rather than from a fresh description.

Doing it with agentappbuilder

agentappbuilder gives these frames a home. Your agent creates a mobile app in a project, whose frames default to phone size (390 x 844), draws one frame per state, and links them with the taps between them, shown as arrows on a canvas. If the app has a web build that runs, locally or deployed, the agent can instead capture it at 390 x 844 with the Playwright script of its guide, after asking you, and you import the captures into the prototype. You paste a frame URL with a change, compare versions side by side, and say “apply” when you want the chosen version coded. The canvas is designed for desktop screens; the frames render at phone size on it. Concepts covers apps and device presets, and Getting started walks through a first capture.

Whatever tool holds the frames, the order stays the same: states first, phone size always, review before code, one flow at a time.