DEV Community: Praveen Singh

Bareship: an offline-first React Native template for teams and AI agents

Praveen Singh — Thu, 22 Oct 2026 15:39:25 +0000

Bareship is a free, MIT-licensed template for bare React Native 0.87 apps. One command, npx create-bareship Acme, gives you an iOS and Android app where a like or an edit made offline is saved, survives a restart and is sent once when the phone reconnects; where the folder rules are checked by ESLint instead of code review; and where Claude Code, Cursor or Copilot get the same rules as your team. It runs with no backend, Firebase project or Apple account until you need them.

Why another template?

Every new React Native app I've started began the same way: a week or two rebuilding the plumbing before the first real feature. A queue for writes made without signal, somewhere safe for the auth token, folder rules everyone agrees on and nobody checks. Each time I built them a little differently, and each time the gaps showed up later, in a bug report from a user with a bad connection or in a feature folder that had quietly started importing from three others. I wanted to make those decisions once, properly, and start from there.

Most starters get you to a running screen fast. The parts that cost time later are the ones a demo never touches: what happens to a write when the phone has no signal, where the auth token lives, and whether the folder structure you agreed on in week one still holds in month six, with three developers and a coding agent all adding code. Bareship is my answer to those, decided once and written down.

What happens when the phone goes offline?

Every write in the app picks one of four patterns, so a user always knows what became of what they did:

Pattern	Without a connection	Use it for
A	The change appears at once and is sent later	Low-stakes toggles
B	The change appears at once, marked "Waiting to sync"	Likes, comments, edits
C	The form is disabled, with a note saying why	Sign-in, payments
D	The content is replaced by an offline message	Account deletion, checkout

Queued writes are saved to disk, replayed in the order they were made after a restart, and carry one idempotency key for every attempt, so a write sent twice is applied once. A banner under the header counts the changes waiting to sync. A write that picks no pattern fails at once offline, so nothing is queued by accident.

Rules the build enforces

The architecture is in the linter, not a wiki page. Layers import downward only, features can't reach into each other's files, text on screen must go through translations, and accessibility uses one set of ARIA props everywhere. ESLint and dependency-cruiser fail the check otherwise. When a rule is wrong for your app, you change it in one place and write down why: the decisions behind the template are kept as ADRs in the repo.

Built for AI coding agents

The repo ships an AGENTS.md, its decision records and React Native agent skills, plus generators (pnpm gen feature | screen | endpoint) that write a schema, API hooks, a mock, strings and a test the way the rest of the code does. An agent that follows them writes code that passes the same checks as your team's.

I built much of Bareship with Claude Code, so these files were tested on an agent from the start: when it broke a rule, the fix went into the linter or AGENTS.md, not into a comment on a pull request.

It runs with no accounts

The dev build serves sample data from a mock backend inside the app, so you can sign in, scroll the feed and test offline mode on a simulator or a phone before any backend exists. Crashlytics, Analytics, Remote Config and push turn on when you add a Firebase file and fall back to logging without one. Tokens are stored in the Keychain and Keystore from day one.

Also included: light and dark themes, English and Hindi (with right-to-left support you can switch on), deep links, force-update and maintenance screens, environments for dev, staging and prod, fastlane release lanes and a demo build you can install on a phone.

Try it

npx create-bareship Acme
cd Acme
pnpm android   # or: pnpm ios

create-bareship checks your tools first, asks for a bundle id and display name, installs everything and makes the first commit.

Sped up: the real run took 1 min 15 s to create the app. The full-quality video is on my blog. The first Android build compiles the native libraries and takes a while (about 20 minutes on my 8 GB M1, a few minutes on a faster machine); builds after that are quick.

psingh2907 / bareship

Production-ready, offline-first bare React Native template for teams and AI agents. Create an app: npx create-bareship MyApp

What's next

Bareship is at 0.3.2. Next on the list: turning CI back on in the repository, and a series of posts on how the pieces work, starting with the offline queue and idempotency keys. If it saves you a week, a star on GitHub helps other people find it, and issues are the best way to tell me what's missing.

In short:

npx create-bareship Acme creates a bare React Native 0.87 app for iOS and Android in one command.
Each write picks one of four offline patterns; queued writes survive a restart and are applied once.
Layers, feature boundaries, translations and accessibility are enforced by ESLint and dependency-cruiser.
AGENTS.md, ADRs, skills and generators give AI coding agents the same rules as your team.
It runs with no backend, Firebase or Apple account; you add each service when you need it.

Docs: bareship.praveensingh.co.in

On-device AI in React Native, late 2026: one AI SDK call, two engines, measured

Praveen Singh — Mon, 12 Oct 2026 04:55:34 +0000

At a glance

Problem: Run an LLM inside a React Native app, with no server and no API key
Fix: Two on-device engines behind one AI SDK call, plus a model picker that checks each engine actually works
Result: 20 vs 2 (valid structured outputs out of 20: Apple's guided generation vs a 1B ExecuTorch model)

Short answer: On-device AI in React Native is practical now, but the two engines suit different jobs. Use Apple's Foundation Models when the device has it: no download, and guided generation returned valid structured output 20 times out of 20. Use ExecuTorch for everything else, but not for structured output from a 1B model: only 2 of 20 responses matched my schema. Keep a cloud fallback, and check that each engine really works rather than trusting its availability flag.

React Native got a lot of AI news this year. WWDC26 expanded Apple's Foundation Models framework (image input, Private Cloud Compute, third-party models behind the same API). Software Mansion rewrote ExecuTorch for 0.10 with Core ML, MLX and Vulkan backends. Callstack's react-native-ai put Apple's model, llama.rn, MLC and Gemini Nano behind the Vercel AI SDK. An expo-ai package is in review in the Expo repo.

Release posts tell you what's possible. I wanted to know what it takes, so I built one small React Native 0.87 app that calls both engines through the same streamText / generateObject code, and measured them on the same tasks.

Everything is in a public repo: code, raw results and the failures.

The setup, and what I couldn't measure. React Native 0.87.1, AI SDK 6, @react-native-ai/apple 0.12.0, react-native-executorch 0.10.4 running Llama 3.2 1B. An Apple M1 with 8 GB of memory, the iPhone 17 simulator on iOS 26.3, no physical devices. ExecuTorch ran in the app on the simulator. Apple's model wouldn't run in the simulator (more below), so I ran the same tasks against it from Swift on the Mac. These are Mac numbers, not iPhone numbers: use them to compare the two engines, not to predict latency on a phone. Gemini Nano on Android needs a supported phone, so it's covered from the docs only.

The two tasks

Five store-audit notes, written the way an auditor types them on a phone:

Freezer 2 door seal torn, temp reading -12 instead of -18. Aisle 4 lights flickering. Fire exit at the back blocked by two pallets of water.

Summary: streamed, two sentences, most urgent issue first. I measured time to first text and total time.
Checklist: structured output, validated against a Zod schema with generateObject. One item per issue, each with an area, an issue and a severity of low, medium or high. 10 runs per engine, per run of the benchmark.

One call site for both engines

Apple's model already has an AI SDK provider. ExecuTorch doesn't, so I wrote a small adapter. Version 0.10 makes this easier: below the useLLMChatSession hook it exposes the runner and the model's chat template as separate pieces.

I didn't use the chat session itself. It keeps a growing conversation in the model's cache, which suits a chat screen but not a one-off generateText call. The adapter resets the runner and renders the AI SDK prompt from scratch on every call:

src/lab/executorchModel.ts (excerpt)

async function run(options: LanguageModelV3CallOptions, onToken: (t: string) => void) {
  const schema = options.responseFormat?.type === 'json' ? options.responseFormat.schema : undefined;
  const messages = toMessages(options.prompt, schema); // AI SDK prompt -> chat messages
  runner.reset(); // stateless: no history from earlier calls
  const prompt = preprocessor.process(messages, messages.length, { addGenPrompt: true });
  preprocessor.clear();
  const genConfig = { maxNewTokens: options.maxOutputTokens ?? 512, temperature: options.temperature ?? 0.7 };
  return generateAsync(runner, prompt, genConfig, stopTokens, onToken); // runs on a worklet thread
}

doGenerate and doStream wrap that, and after that the calling code is the same for both engines:

const result = streamText({ model, system, prompt, maxOutputTokens: 160 });
const { object } = await generateObject({ model, schema: checklistSchema, system, prompt });

There's one difference the code can't hide. Apple's model fills the schema through guided generation: the framework restricts what the model can output to fit the type. ExecuTorch has no equivalent here, so the adapter puts the schema in the prompt and hopes. That difference decided the structured-output results.

Getting it to build took seven fixes

None of these are hard, but each one stops the app from building or running, and I didn't find any of them in the docs:

Problem	Fix
iOS build fails: `unknown type name 'RCTCxxBridge'` in `RnExecutorch.mm`	React Native 0.87 removed it. Patch the module to install its JSI bindings through `RCTTurboModuleWithJSIBindings` (patch)
CocoaPods: "required a higher minimum deployment target"	`platform :ios, '17.0'` in the `Podfile`
Metro: "Export namespace should be first transformed"	Add `@babel/plugin-transform-export-namespace-from`, the v7 release (v8 needs Babel 8)
ExecuTorch native calls fail	`react-native-worklets/plugin`, last in the Babel plugins
`Property 'TextDecoder' doesn't exist`	Polyfills for the AI SDK on Hermes (below)
`ai@latest` installs 7.x	Pin `ai@6`: the React Native AI providers implement the v6 spec
npm 11 skips ExecuTorch's postinstall	Approve it after reading it: it downloads the native libraries from the project's GitHub releases

The polyfills:

src/polyfills.ts

import 'web-streams-polyfill/polyfill'; // ReadableStream, TransformStream
import 'fast-text-encoding'; // TextDecoder
import { TextDecoderStream, TextEncoderStream } from '@stardazed/streams-text-encoding';
import structuredClone from '@ungap/structured-clone';

const g = globalThis as any;
g.TextEncoderStream ??= TextEncoderStream;
g.TextDecoderStream ??= TextDecoderStream;
g.structuredClone ??= (value: unknown) => structuredClone(value);

Gotcha: Use the global ReadableStream in your adapter. My first streaming run died with "First parameter has member 'readable' that is not a ReadableStream". I had imported ReadableStream from web-streams-polyfill, which is a different class from the global one the polyfill installs, and the AI SDK checks against the global. Build streams with globalThis.ReadableStream.

Gotcha: ExecuTorch sends download analytics by default. Version 0.10 reports anonymous download events to Software Mansion unless you call setTelemetryEnabled(false). That's easy to miss, and it matters if you picked on-device AI for privacy.

Two things that failed on the simulator

Apple's model said it was available, then failed every call. apple.isAvailable() returned true in the iOS 26.3 simulator, and all 30 calls across two runs failed with GenerationError error -1. The simulator log had the real reason: the model catalog had no assets (UnifiedAssetFramework Code=5000). The same model worked from Swift on the Mac, which runs macOS 26.6, so my guess is a mismatch between the simulator runtime and the Mac's model assets. Either way, the availability flag isn't proof.

The MLX build of the model downloaded, then wouldn't load. I picked LLAMA3_2_1B.MLX_INT4 to compare against the CPU backend. It downloaded all 1.18 GB, then failed with Error::NotFound. The podspec explains it: the MLX backend is only linked into device builds, because the simulator SDK lacks the Metal APIs it needs. .DEFAULT would have avoided this, because it only picks backends that are actually linked into the build.

Both lead to the same rule, and it's built into the model picker below: check that an engine works with a real call, and use the library's defaults rather than hard-coding a variant.

Speed: similar once warm

	ExecuTorch, Llama 3.2 1B (simulator)	Apple Foundation Models (Mac)
Download before first use	1.14 GB, 6 min 12 s	none, part of the OS
Load from disk	4.4–5.3 s	none
First call, time to first text	0.6–0.8 s	9.7–19.2 s
Later calls, time to first text (median)	579 ms	580 ms
Later calls, full summary (median)	2.5 s	2.9 s
Generation speed (median)	43 tokens/s	not reported
App memory while generating (median)	907 MB	not in the app's process

Once both were warm, they were close. The differences are at the edges:

ExecuTorch's cost is up front. A 1.14 GB download on first use, then about 5 s to load the model on each launch. While generating, the app used about 900 MB of memory, which matters on phones that kill background apps.
Apple's cost is the first call. That first call took 10–19 s on this Mac, and later calls took about half a second. The model runs in a system process, so it adds nothing to your app's memory, and there's nothing to download.

How I measured. Two full runs per engine: 5 summaries and 10 checklists each, plus a third set of 10 checklists for the prompt fix below. The first call of each run is reported separately. Memory is the app process's resident size, sampled on the Mac at each result. The Mac was swapping during the runs (5.6 of 6 GB of swap in use), which hurts the Apple numbers most. The raw results and the summary script are in the repo's metrics and scripts folders.

@react-native-ai/apple reports zero tokens to the AI SDK, so its token counts and tokens per second are missing. Compare time to first text and total time instead.

Structured output: 2 out of 20 vs 20 out of 20

This is the biggest difference between the two engines:

Checklist output that passed the Zod schema	Valid
ExecuTorch, schema in the prompt	2 / 20
ExecuTorch, example in the prompt, plus a repair step	6 / 10
Apple, guided generation	20 / 20

The 1B model failed in three ways:

It returned the schema. In 5 of the 9 failures in one run, it replied with the JSON Schema itself ({"$schema": "http://json-schema.org/draft-07/schema#", ...}) instead of filling it in.
Wrong case: "severity": "High" where the schema says "high".
Not JSON at all: a bulleted list wrapped in braces.

Two cheap changes raised the pass rate from 1 in 10 to 6 in 10 in the same run. Show an example instead of the schema, and lower-case the enum values before validation:

const { object } = await generateObject({
  model,
  schema: checklistSchema,
  prompt,
  // The adapter puts this example in the prompt instead of the JSON Schema.
  providerOptions: { executorch: { jsonExample: '{"items":[{"area":"Aisle 2","issue":"Spilled milk","severity":"high"}]}' } },
  experimental_repairText: async ({ text }) => text.replace(/"(low|medium|high)"/gi, (m) => m.toLowerCase()),
});

6 out of 10 still isn't good enough to ship, and passing the schema doesn't mean the content is right. I read every valid checklist from the 1B model:

Two of the six copied my example into the store's checklist: "Aisle 2: Spilled milk on floor" was never in the note.
Fields got mixed up: "Back fire exit: Expired yoghurt found in dairy fridge".
Items were duplicated, and every item, in every valid checklist, was marked high.

Apple's 20 checklists listed every issue in each note, in sensible areas, and never invented one. It rated a few minor issues too high (a frozen checkout scanner as high), but the fire, rodent and food-safety issues were high every time.

Neither engine was good at the summaries. The 1B model opened every one with "Here is a two-sentence summary", then often wrote three or four. It also misread the notes: once it said the torn freezer seal was blocking the fire exit, once that a leaking roof was "not an issue". Apple's summaries were shorter (177 characters against 396), but half came back as Markdown bullet lists rather than two sentences. One left out the wet floor, and another ranked the frozen scanner above expired food.

If your feature needs structured output, a 1B model in your app isn't enough. Use the system model, a larger downloaded model (Llama 3.2 3B is in ExecuTorch's catalog), or the cloud.

Choosing a model at runtime

Here's the picker the lab uses. The order is fixed: Apple's model if it really works, then a downloaded model if the user agreed to the download, then the cloud. The result is cached for the session.

src/lab/router.ts

// apple.isAvailable() said true in the simulator while every call failed,
// so it's only a first filter. A one-token call is the real check.
async function appleWorks() {
  if (Platform.OS !== 'ios' || !apple.isAvailable()) return false;
  try {
    await generateText({ model: apple(), prompt: 'Reply with OK.', maxOutputTokens: 2 });
    return true;
  } catch {
    return false;
  }
}

export function pickModel(cloud: LanguageModel, opts: { allowDownload: boolean }): Promise<Route> {
  return (cached ??= (async (): Promise<Route> => {
    if (await appleWorks()) return { model: apple(), where: 'on-device (Apple)' };
    if (opts.allowDownload) {
      // DEFAULT only picks backends linked into this build.
      const et = createExecutorchModel('llama-3.2-1b', models.llm.LLAMA3_2_1B.DEFAULT);
      try {
        await et.load();
        return { model: et.model, where: 'on-device (downloaded model)' };
      } catch {}
    }
    return { model: cloud, where: 'cloud' };
  })());
}

where is for the UI. If people chose your feature because their text stays on the phone, tell them when it doesn't. That applies to the cloud fallback, and to Apple's Private Cloud Compute when iOS 27 sends a request there.

This code is type-checked but not benchmarked; the lab measured each engine on its own.

Android: Gemini Nano, from the docs

I couldn't test this one: Gemini Nano needs a supported Android 14+ phone, and an emulator won't do. On paper it fits the same pattern. @react-native-ai/adk is another AI SDK provider, so it would be one more branch in pickModel. Its availability check comes in steps: isNanoSupported() (can this phone run it?), isAvailable() (is it ready?) and prepareNano(). Given what happened with Apple's flag, I'd still add a probe call. ExecuTorch also runs on Android, using Vulkan for the GPU, so the downloaded-model branch carries over unchanged.

What to use, and when

Use Apple's Foundation Models first on iOS. There's nothing to download, it doesn't use your app's memory, and guided generation makes structured output reliable. Expect a slow first call, so warm the model up before the user needs it.

Use ExecuTorch when there's no system model, for short free-text tasks where a person reads the result: rewording, suggestions, drafts. Check its output before you act on it. Ask before the 1 GB download, show progress, and turn off telemetry. Don't depend on a 1B model for JSON.

Keep a cloud fallback, and label it in the UI.

Watch expo-ai. It's in review with an Apple provider, streaming and tool calls. If it lands, most of the setup fixes above become Expo's problem rather than yours.

Takeaways

Put both engines behind the AI SDK so the calling code stays the same; ExecuTorch needs a small adapter.
Pin ai@6 for the React Native AI providers, and add stream, TextDecoder and structuredClone polyfills for Hermes.
ExecuTorch 0.10.4 needs a one-file patch to build on React Native 0.87 iOS.
Don't trust apple.isAvailable() alone: make a tiny probe call and cache the result.
Use ExecuTorch's .DEFAULT variants; MLX variants download and then fail on the simulator.
A 1B model returned schema-valid JSON 2 times in 20; an example prompt and a repair step got it to 6 in 10.
Apple's guided generation returned valid output 20 times in 20.
Turn off ExecuTorch telemetry, and show users when a request leaves the device.

I write about React Native in practice, measured and with public code, at praveensingh.co.in/blog.

Giving your coding agent eyes on a React Native app: Argent vs agent-device, measured

Praveen Singh — Fri, 09 Oct 2026 10:50:06 +0000

At a glance

Problem: Let a coding agent run, tap through and profile a React Native app by itself
Fix: Argent or agent-device, each given alone to Claude Code, on three planted bugs
Result: 12 / 12 (runs fully solved, by both tools; agent-device used about a fifth of the tokens)

Short answer: Both tools let a coding agent reproduce, fix, verify and profile real React Native bugs. Every one of the 12 scored runs got full marks. The difference is cost and setup. agent-device runs used about a fifth of the tokens and a third of the money, because it answers with compact text instead of a screenshot after every action. Argent's React profiler worked with no setup on React Native 0.87, while agent-device's needed a package installed and two project files patched first.

Coding agents used to stop at "it compiles". In 2026 a set of tools lets them run the app, tap through it, read the screen and profile it. Two are built with React Native in mind: Software Mansion's Argent and Callstack's agent-device. Both claim to close the loop. I wanted to know what that looks like on a real app, and what it costs.

So I planted three bugs in a small React Native 0.87 app and gave Claude Code the same bug reports twice: once with only Argent, once with only agent-device. Everything is in a public repo: the app, the harness, the rubric, every transcript and every score.

The setup. The store-audit app from my 0.87 upgrade post, on React Native 0.87.1 with FlashList, in the iPhone 17 simulator on an Apple M1 with 8 GB of memory. Argent 0.26.0 (its MCP server, skills and rules, as argent init installs them) against agent-device 0.21.19 (its CLI, skills from npx skills add, and the CLAUDE.md text its docs recommend). Claude Code 2.1.42 in headless mode with claude-sonnet-5-5, one session per run. Three tasks, two runs per tool per task, 12 scored runs.

The three bugs

Each run got one bug report, written the way a store auditor would send it, plus a line saying the app is installed and Metro is running. Nothing pointed at files or causes.

Reproduce: "I tapped yes on 'Fire exit clear of obstructions'. When I scrolled down, other questions I never touched showed yes too." Each row kept its own copy of the answer in useState, and FlashList recycles rows, so a recycled row shows the previous question's answer. The agent had to reproduce it in the app and explain it, without changing code.
Fix and verify: "The yes/no buttons are missing on questions with long titles." The question text couldn't shrink, so long titles pushed the buttons off screen. The agent had to fix it and prove both long and short rows look right in the app.
Performance: "Typing in the Notes box feels laggy." The note's state lived in the screen, so every keystroke re-rendered every visible row, and each row ran a slow keyword check (about 8 ms per row). The agent had to find out why with real measurements, fix it, and measure again.

I wrote the scoring rubric and committed it before the first scored run: three points per task, and points that need evidence from the running app don't count if the agent only read the code.

Making it a fair test took four fixes

A comparison like this is only fair if each session sees exactly one tool. My machine has Argent installed globally, so that took more work than I expected:

Problem	Fix
`--setting-sources project` still loaded my global `~/.claude/CLAUDE.md` and rules, including Argent's. A probe session in the agent-device setup quoted Argent's tapping rule back to me	`CLAUDE_CODE_DISABLE_CLAUDE_MDS=1` and `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1`
Argent's global skills are relative symlinks, so copying them into a plugin folder copied broken links	Copy with `cp -RL`
My lab's commit messages described the planted bugs, and agents can read `git log`	Agents work in a separate copy of the app with a single, history-free commit, reset between runs
One agent installed a package to profile, then removed it, leaving empty folders in `node_modules`	`npm prune` and remove empty folders before each run

Each tool's skills went in through --plugin-dir, its MCP config through --strict-mcp-config, and its rules through --append-system-prompt. The other tool's command was shadowed on PATH. A probe run before the real ones confirmed that each session listed only its own tool.

Gotcha: You can't start Claude Code from inside Claude Code. Running claude -p from an agent session fails with "Claude Code cannot be launched inside another Claude Code session". I started the runs from a separate terminal. The command-line tool also needs its own claude auth login; being signed in to the desktop app isn't enough.

Both tools solved every task

Task	Argent	agent-device
Reproduce	6 / 6	6 / 6
Fix and verify	6 / 6	6 / 6
Performance	6 / 6	6 / 6

Every run reproduced or verified in the running app, named the right cause, and the fixes type-checked. In two runs the agent went beyond the report: one Argent run noticed the recycled-row bug while fixing the layout bug, and one agent-device run fixed the slow keyword check as well as the state problem, after checking that the new version gives identical results on all 48 questions.

So on tasks like these, either tool is enough. The model does the reasoning; the tool decides how expensive it is to see the app.

Where they differed: context and cost

Median per run	Argent	agent-device
Time	138 s	108 s
Tool calls	34	16.5
Screenshots in the conversation	11	0.5
Text returned by tools	59 KB	17 KB
Tokens processed	1.84 M	0.34 M
Cost per run (average)	$1.27	$0.41

The difference comes from what each tool sends back. Every Argent interaction (tap, swipe, launch) returns a screenshot and the full accessibility tree, so the agent always sees the screen, and every image stays in the conversation. agent-device's commands return a compact text snapshot or a diff, with short references like @e8 to tap, and screenshots only when the agent asks for one. Over a session, that's the difference between about 1.8 million and 0.3 million tokens.

The text-first approach had one concrete advantage in this app. agent-device's snapshot printed the pill's selected state as text:

@e29 [button] "yes for Entrance mats clean" [selected]

Argent's tree didn't include the selected state, so Argent's agent found the stray "yes" by looking at screenshots. One of its reports says so directly. Both got there; one needed the image.

Where they differed: profiling setup

Both tools can profile React renders, and both agents found and measured the slow typing:

Performance runs	Argent	agent-device
Before the fix	155–179 ms per slow commit, 162 row re-renders	145–153 ms average per keystroke, every visible row re-rendered
After the fix	no commit over 16 ms	about 1 ms per keystroke
Time per run	195 s, 229 s	296 s, 517 s

Argent's profiler worked straight away on React Native 0.87. It also sampled the CPU, which pointed straight at the slow code: RegExp construction took 943 ms of the 1.6 seconds of JavaScript work while typing.

agent-device's React DevTools needed setup first. On 0.87 both agent-device runs had to install agent-react-devtools into the project and run its init, which patches index.js and metro.config.js. Both agents undid it afterwards, but it made these its slowest runs. In one, a react-devtools wait --connected call hung and the agent had to restart the helper. Even so, agent-device's performance runs cost less: $0.80 each against $2.00.

Gotcha: Check what a profiling setup leaves behind. One agent installed the DevTools package with --save-dev, so it went into package.json until the agent removed it again. If you let an agent set up profiling in your real repo, review the diff for index.js, metro.config.js and package.json changes before you commit.

Different habits

One pattern held in all four fix-and-verify runs. Both Argent runs looked at the broken screen first, then changed the code and checked again. Both agent-device runs changed the code straight from reading it, then checked the app. The rubric didn't require seeing the bug first, and all four fixes were correct. But on a less obvious bug, fixing what the code suggests rather than what the app shows could miss.

I can't tell from four runs whether this comes from the tools. agent-device's guidance tells the agent to "start immediately", and every Argent action shows the screen, which may encourage looking first.

What the numbers don't show

One model, one app, two runs per task. I planned three runs; after two rounds every run had full marks, so I stopped. These tasks didn't separate the tools on success; harder tasks might.
One run was cut off. The account running the sessions hit its usage limit during Argent's second performance run. I re-ran it once the limit reset. The cut-off attempt is in the repo, excluded from the totals.
The simulator, not a phone. Both tools also drive Android and physical devices; I tested neither.
I scored them with Claude. The rubric was committed first, the points need evidence from tool output rather than the agent's own claims, and every transcript is public so you can check.

Which should you use?

Use agent-device when you run agents on the app a lot: many UI checks, CI, or long sessions. It was about three times cheaper per run and quicker on the everyday tasks, and its text snapshots carry states like [selected] that you'd otherwise need a screenshot for.

Use Argent when profiling is the main job, or you want the agent to see the screen by default. Its React and CPU profiler worked on React Native 0.87 with no project changes, and it pointed straight at the slow code.

Either way, help the tool. Both rely on the accessibility tree. The planted app had accessibilityLabel and accessibilityState on its buttons, and that's what let both agents find the right row and read its state. If your app doesn't, the agent falls back to screenshots and coordinates.

Takeaways

Both Argent and agent-device let Claude Code reproduce, fix, verify and profile real React Native bugs: 12 of 12 runs got full marks.
agent-device used about a fifth of the tokens and a third of the cost, because it returns text snapshots instead of a screenshot after every action.
Argent's React and CPU profiler worked on React Native 0.87 with no setup; agent-device's needed agent-react-devtools installed and two files patched.
Review the diff after an agent sets up profiling: index.js, metro.config.js and package.json can change.
Add accessibilityLabel and accessibilityState to interactive elements; both tools read the accessibility tree first.
To compare agent tools fairly, isolate each session: --setting-sources project doesn't stop global CLAUDE.md and rules loading.
Keep git history out of the agent's workspace if your commits describe the bugs you're testing.

I write about React Native in practice, measured and with public code, at praveensingh.co.in/blog.