React Native ExecuTorch: on-device inference for React Native, and the price of the native build
High-performance, privacy-first on-device AI inference library for React Native, powered by PyTorch's ExecuTorch runtime
At a glance
- What is it?
- React Native ExecuTorch runs ExecuTorch models inside a React Native app through ready-made task hooks. It buys offline inference at the cost of the New Architecture, iOS 17 and Android 13 floors, and a development build.
- Who is it for?
- Reach for React Native ExecuTorch if you already ship a New Architecture app on React Native 0.83 or Expo SDK 55 and you want chat, OCR, transcription or embeddings to run without a server. Skip it if you depend on Expo Go, support iOS 16 or Android 12 and below, or want a hosted model API instead of a native build.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What React Native ExecuTorch solves, and for whom
The library's stated purpose is to run machine learning models directly on the user's phone, with zero network calls after the model download. That framing targets a specific group: React Native teams that need language models, computer vision, speech-to-text, text-to-speech or embeddings inside an app, and cannot or will not send user content to a server. The README makes the privacy argument explicitly, saying no data ever leaves the device.
The practical motivation is cost and offline behaviour as much as privacy. A cloud inference endpoint bills per request and fails when the network does. On-device inference moves both the latency and the bill to the user's hardware. The trade is that the model has to be downloaded, stored, and executed on a phone, which constrains model size far more than a server deployment does.
The library is not a general React Native ML toolkit. It is a binding to ExecuTorch, Meta's on-device inference runtime, and the models it accepts are .pte files. If your model cannot be exported to that format, this project does not help you, regardless of how well its hooks fit your UI.
The two-layer architecture: task hooks above, tensors below
The README describes a two-layer design. The upper layer is a set of ready-to-use task hooks named use<Task>, covering LLMs, computer vision, speech and embeddings, with automatic caching and lifecycle management. The lower layer exposes the runtime itself: low-level tensor operations, native operators, schema validation and worklet threading, so you can build custom pipelines in TypeScript.
That split matters because the two layers fail differently. A task hook such as useLLMChatSession handles model download, readiness state and token streaming for you, which is why the quickstart example is roughly thirty lines. The cost is that you inherit the hook's assumptions about session shape and message format. The lower layer gives you control over the graph you execute, but you own orchestration, threading and memory behaviour.
Execution itself is delegated to native backends. The Key Features list names XNNPACK for CPU, Core ML and MLX for Apple Silicon, and Vulkan for Android GPU. Those are the acceleration paths; the library does not implement its own kernels. Model weights come either from the pre-exported catalog reachable through the models registry and Software Mansion's Hugging Face collections, or from your own .pte file. The download path goes through react-native-blob-util, which is why that package is a required peer dependency rather than an optional one.
Installing React Native ExecuTorch and running a first LLM call
Installation is one package plus two peer dependencies. The README gives npm, yarn and pnpm variants; the npm form is below.
npm install react-native-executorch react-native-worklets react-native-blob-utilThe README marks several requirements as important: the New Architecture must be enabled, the app must run React Native 0.83 or newer or Expo SDK 55 or newer with Development Builds, react-native-worklets must be at version 0.10 or newer within the range >=0.10.0 <0.13.0, and the platform floors are iOS 17.0 and Android 13 with minSdkVersion at least 26. Expo Go is explicitly not supported, because the library ships custom C++ native libraries. The monorepo pins react-native-worklets to 0.10.3 in its resolutions field, which is a useful signal for the version to start with.
With the app building, the first real use is a chat session. The README's example imports the models registry and the useLLMChatSession hook, then sends a message and logs each streamed token.
import { Button, View } from 'react-native';
import { models, useLLMChatSession } from 'react-native-executorch';
export function App() {
const session = useLLMChatSession(models.llm.LFM2_5_1_2B.DEFAULT);
const handleGenerate = async () => {
if (!session.isReady || !session.sendMessage) return;
const turn = await session.sendMessage(
'Explain on-device AI in one sentence.',
(token) => console.log(token)
);
console.log('Result messages:', turn.messages);
};The button label in the full README example reads session.downloadProgress while the session is loading, which tells you what to expect on first launch: a model download before any inference happens. The hook exposes isReady, sendMessage, downloadProgress and the returned turn with its messages array. Nothing in the README suggests the download is resumable or that a partial download survives an app restart, so treat first-run download as a state your UI must handle.
Where React Native ExecuTorch is the wrong tool
The hardest constraint is the platform floor. iOS 17.0 and Android 13 with minSdkVersion 26 exclude a large share of devices still in use, and the README states these as requirements rather than recommendations. If your app supports older Android versions, this library cannot be added without dropping them.
The second constraint is Expo Go. Because the library depends on custom C++ native libraries, Expo Go is not supported and a development build is required. Teams that use Expo Go for fast iteration lose that workflow for any build containing this package.
The third is model size and download. Everything the library runs has to be fetched to the device before it can run. The quickstart uses a 1.2B parameter model, which is a real download over mobile data and a real amount of storage on the device. The README does not document a rollback path if a model download is interrupted or a model file is corrupted, and it does not describe how to evict cached models. If your use case needs a small, always-available model with no first-run download, a cloud endpoint or a much smaller exported model is the better fit.
Finally, the repository's top-level LICENSE is reported as NOASSERTION, meaning no standard license identifier was detected. The README does not state licensing terms for the library or for the pre-exported models in the Hugging Face collections, and model licenses are frequently separate from library licenses. That is a question for whoever reviews dependencies in your organisation, not something to assume.
How it compares with MLC and a hosted API
The related searches around this project include React Native AI MLC, which points at the other well-known route to on-device models in a React Native app. The difference is at the runtime layer, not the UI layer. MLC-based approaches compile and serve models through their own stack and typically require you to wire the native module and the model pipeline yourself. React Native ExecuTorch instead binds to ExecuTorch and ships task hooks that already know how to download a model, report readiness, stream tokens and manage the session lifecycle. You get less control over the execution graph in exchange for not writing the plumbing.
The other alternative is not on-device at all: call a hosted inference API. That removes every constraint listed above, including the OS floors, the development build and the model download, and it lets you use models far larger than a phone can hold. It also reintroduces per-request cost, network dependency and the data-egress question the library exists to avoid. For a chat feature where the content is not sensitive and connectivity is reliable, the hosted API is usually the cheaper engineering decision. For OCR of documents, transcription of voice notes, or anything a user would not want uploaded, on-device is the point.
Maintenance, releases and upgrade cost
The repository is not archived, and the last push was on 2026-09-13. Releases are frequent and come in two flavours: v0.10.3-libs and v0.10.2-libs alongside plain v0.10.2, all within the same week. The -libs suffix suggests the native library artifacts version separately from the JavaScript package, which is worth knowing before you pin a version in package.json, because a JS upgrade may or may not imply a native artifact change.
The monorepo uses Yarn 4.1.1 with workspaces covering packages/*, apps/* and apps/legacy/*. A LEGACY_REMOVAL.md file at the repository root, plus a package.json comment describing apps/legacy/* as preserved legacy example apps to remove when legacy apps are dropped, indicate that older example apps are being carried forward deliberately rather than maintained as current. If you copy code from a legacy example, check it against the current docs.
The upgrade cost is dominated by the peer dependency range on react-native-worklets, >=0.10.0 <0.13.0, and the React Native 0.83 or Expo SDK 55 floor. A React Native upgrade that moves worklets outside that range will block a library upgrade until the constraint is relaxed. The repository also excludes react-native-executorch-webrtc from its lint and typecheck scripts, which is a small sign that not every workspace is held to the same checks.
Editorial conclusion
Reach for React Native ExecuTorch if you already ship a New Architecture app on React Native 0.83 or Expo SDK 55 and you want chat, OCR, transcription or embeddings to run without a server. Skip it if you depend on Expo Go, support iOS 16 or Android 12 and below, or want a hosted model API instead of a native build. Before committing, confirm three things on your own machine: that your app builds with react-native-worklets pinned to 0.10.3, that your target .pte model exists in the Software Mansion Hugging Face collection at a size your users will accept downloading, and that the LICENSE file's NOASSERTION status has been reviewed by whoever signs off on dependencies.
Frequently asked questions
Does React Native ExecuTorch work with Expo?
Yes, with Expo SDK 55 or newer and Development Builds. Expo Go is not supported because the library depends on custom C++ native libraries.
Which platforms and versions does React Native ExecuTorch require?
The README states iOS 17.0 or newer and Android 13 or newer with minSdkVersion at least 26, plus the New Architecture enabled and React Native 0.83 or newer.
Where do the models for React Native ExecuTorch come from?
The library ships a pre-exported catalog accessible through the models registry and Software Mansion's Hugging Face collections. You can also bring your own .pte model and plug it into an existing pipeline.
Community notes