Skip to content

Project

Benchmarks

Every number on this page comes from building real features on the public test app (Expo Dev Client) with /rn-feature-dev — 35 completed features across form wizards, charts, lists, notifications, and animations. No synthetic micro-benchmarks.

The end-to-end measurement that matters: from a one-line feature description to code that has been implemented and verified live on the simulator — component tree, store state, and interactions checked.

Feature complexityExamplesTime to verified
Simplesearch field, toggle, store slice3–5 min
Mediumforms, charts, lists5–10 min
Complex3-step wizard, onboarding flow11–25 min

Zero crashes and zero manual interventions across all 35 measured builds — no human unblocking, no restarts.

Pipeline phaseTypical share
Discovery, exploration, questions~3 min
Architecture~1 min
Implementation~5 min
Live on-device verification~5 min
Code review + fixes~4 min
Summary + E2E proof~2 min

Flows the agent has verified once are saved as actions and replayed instead of rediscovered:

Interactive walkReplayed action
3-step wizard flow~14 min~4 s

That is a ~210× speedup on every later session that needs the same flow (login, navigation, multi-step setup). Across the measured features, average session time dropped from ~12 min to ~4 min once the corresponding actions existed.

iOS interaction goes through an in-tree XCTest HTTP runner:

OperationLatency
Tap~216 ms
Accessibility-tree snapshot~5 ms
Screenshot~74 ms
Per-step overhead~1.4 s (vs ~3.1 s CLI baseline)

The ~210 ms tap floor is XCTest’s own event-synthesis limit.

Features using these libraries were built and verified through the full pipeline: react-hook-form, zod, @tanstack/react-query, @gorhom/bottom-sheet, @shopify/flash-list, zustand, react-native-svg, expo-notifications, react-native-reanimated, react-native-gesture-handler, expo-haptics.

Timings are wall-clock, recorded on an Apple-silicon MacBook Pro with a booted iOS simulator and Metro running, using the repository’s public test app. Complexity buckets reflect the feature’s UI and state surface, not lines of code. Latency numbers are medians over repeated runs.