React Native Vision Camera vs Expo Camera: On-Device AI Guide

If you are building a React Native app that does anything interesting with the camera, you have two realistic options in 2030: React Native Vision Camera (VisionCamera) by Marc Rousavy, and Expo Camera from the Expo team. On the surface, they both give you a camera preview and let you take photos. Below the surface, they are fundamentally different tools built for fundamentally different use cases.

VisionCamera is a low-level, high-performance camera library designed for developers who need direct access to camera frames, native ML pipelines, and custom processing logic. Expo Camera is a higher-level abstraction that prioritizes ease of use, managed workflow compatibility, and rapid development. Picking the wrong one will cost you weeks of refactoring, or worse, force you to live with performance limitations that your users will feel every time they open the camera.

This guide covers everything you need to make that decision: frame processing architecture, ML model integration, real-time performance benchmarks, barcode scanning, AR overlays, and the practical tradeoffs between Expo managed workflow and bare React Native. If you are building on-device AI mobile apps, this comparison will save you from expensive mistakes.

Understanding the architecture of each library is the fastest way to know which one fits your project. They solve the same high-level problem (expose the device camera to React Native), but their internal designs reflect very different priorities.

VisionCamera's Architecture

VisionCamera V4 (the current major version) is built on top of CameraX on Android and AVFoundation on iOS. It exposes a thin React Native bridge layer on top of these native camera APIs, giving you near-native control over camera configuration: format selection, FPS targeting, HDR, low-light boost, focus modes, zoom, torch, and exposure. The key architectural feature is the Frame Processor system. Frame processors are JavaScript (or more precisely, Worklet) functions that run on a separate thread and receive every camera frame as a native buffer. You can then pass that buffer to native plugins for ML inference, image manipulation, or custom processing without crossing the React Native bridge for each frame.

This architecture means VisionCamera can deliver 30 FPS frame processing on most modern devices, and 60 FPS on flagships, without jank in the camera preview. The frame data stays on the native side until you explicitly bring results back to JavaScript, which is critical for performance.

Expo Camera's Architecture

Expo Camera takes a different approach. It wraps the native camera APIs behind a simplified, declarative component. You get a <CameraView> component with props for facing direction, flash mode, and barcode scanning. Under the hood, it uses the same native APIs (CameraX and AVFoundation), but the abstraction layer is thicker. Expo Camera does not expose a per-frame processing pipeline. Instead, it offers specific, built-in features: photo capture, video recording, barcode/QR scanning, and face detection.

This design works well for apps that need standard camera functionality. You do not need to understand native camera frame formats or threading models. The API surface is smaller, the learning curve is shallower, and it integrates seamlessly with Expo managed workflow. But if you need to run a custom ML model on every frame, Expo Camera does not give you that hook.

This is where the two libraries diverge most sharply, and where your decision will likely be made. If your app requires real-time ML inference on camera frames, VisionCamera is the only option that gives you a production-grade path.

VisionCamera Frame Processors

Frame processors in VisionCamera are functions decorated with the 'worklet' directive that execute on a dedicated camera thread. They receive a Frame object containing the native image buffer, dimensions, pixel format, orientation, and timestamp. You do not decode or re-encode images in JavaScript. Instead, you pass the frame reference to native plugins that operate directly on the buffer.

The plugin ecosystem is where VisionCamera really shines. vision-camera-tflite lets you run any TensorFlow Lite model on each frame with a single function call. You load a .tflite file, pass frames in, get inference results back as JavaScript objects. On an iPhone 15 Pro, a MobileNetV3 classification model runs in about 8ms per frame, leaving plenty of headroom for 60 FPS processing. vision-camera-mlkit wraps Google's ML Kit for text recognition, face detection, and pose estimation. For iOS, vision-camera-coreml gives you direct Core ML integration, which means you can use Apple's Neural Engine for maximum inference speed.

ONNX Runtime also has a VisionCamera plugin that lets you run ONNX models cross-platform. This is useful if your ML team trains in PyTorch and exports to ONNX, because you get a single model format that runs on both platforms with hardware acceleration. Inference times for YOLOv8 Nano on a Snapdragon 8 Gen 3 device are around 12ms per frame through this path.

Expo Camera's ML Story

Expo Camera does not have frame processors. It has built-in barcode scanning (which uses ML Kit under the hood on Android and Vision framework on iOS) and face detection, but you cannot plug in arbitrary models. If you need custom ML inference, your options in the Expo managed workflow are limited to using expo-camera for capture and then processing the resulting photo or video file with a separate library like expo-image-manipulator or a cloud API. That works for non-real-time use cases (scan a document, analyze a photo after capture), but it is not viable for live camera processing.

Some developers try to work around this by capturing frames at intervals using takePictureAsync in a loop. Do not do this. It caps you at roughly 2 to 4 FPS, introduces visible shutter lag, and burns battery. It is a hack, not a solution.

Barcode and QR scanning is one of the most common camera features in production apps, from retail inventory to event check-in to mobile payments. Both libraries support it, but the implementation quality and flexibility differ significantly.

Barcode Scanning

Expo Camera has built-in barcode scanning via the onBarcodeScanned callback. You pass an array of barcode types you want to detect (QR, EAN-13, Code 128, etc.), and the library fires a callback with decoded data whenever a matching barcode enters the frame. Setup takes about three lines of code. It works well for simple scanning use cases, and because it runs natively, performance is good: detection latency is typically under 100ms from the moment a barcode is visible.

VisionCamera handles barcode scanning through the vision-camera-code-scanner plugin, which wraps ML Kit's barcode API. The interface is slightly more verbose, but you get additional control: you can restrict the scanning region to a portion of the frame (useful for scanner UIs with a targeting box), access raw barcode corner points for overlay rendering, and process barcodes alongside other frame processor logic. If your app needs to scan a barcode and simultaneously run object detection on the rest of the frame, VisionCamera lets you chain those operations in a single frame processor pass.

Real-Time Object Detection

For real-time object detection, VisionCamera is the clear winner. You can run YOLOv8, MobileNet-SSD, or EfficientDet models through the TFLite or Core ML plugins and get bounding box coordinates at 30+ FPS. Those coordinates come back to JavaScript on every frame, which means you can render detection overlays using React Native views or Skia canvas elements that update in real time.

A common production setup looks like this: VisionCamera captures 1080p frames at 30 FPS, a frame processor downscales to 320x320 and runs YOLOv8 Nano through TFLite, inference completes in 10 to 15ms, bounding boxes are returned to the JS thread, and a Skia overlay renders detection rectangles with class labels. Total pipeline latency from frame capture to overlay render is about 25 to 40ms on a mid-range 2028+ device. That feels instantaneous to users.

Expo Camera simply cannot do this. There is no mechanism to run a custom detection model on live frames. You can use ML Kit's built-in object detection through the face detection API (which also detects generic objects), but you cannot bring your own model or customize the detection classes.

Numbers matter more than marketing claims. Here are real-world benchmarks from production apps and our own testing across both libraries. All tests were run on three devices: iPhone 15 Pro, Samsung Galaxy S24 Ultra (Snapdragon 8 Gen 3), and Pixel 8 Pro (Tensor G3).

Camera Preview FPS

Both libraries deliver smooth 30 FPS camera previews out of the box. VisionCamera can push to 60 FPS if you explicitly configure the camera format for high frame rate capture. Expo Camera locks to 30 FPS in most configurations. For standard photo and video apps, this difference does not matter. For AR overlays or high-speed scanning, 60 FPS preview makes a noticeable difference in perceived smoothness.

Frame Processing Throughput

This is where VisionCamera pulls ahead dramatically. Running a MobileNetV3 classification model per frame, VisionCamera sustains 28 to 32 FPS on the iPhone 15 Pro and 24 to 28 FPS on the Galaxy S24 Ultra. The frame processor thread runs independently from the UI thread, so the camera preview stays smooth even under heavy inference load. Running the same model via the ONNX Runtime plugin gives slightly different numbers: 26 to 30 FPS on iPhone and 22 to 26 FPS on Android, reflecting the overhead of ONNX's cross-platform abstraction layer versus native Core ML or TFLite.

Expo Camera's "frame processing" (capturing photos in a loop) maxes out at 3 to 4 FPS. That is not a meaningful benchmark for real-time inference. It is a workaround, and a poor one.

Startup Time

Camera initialization matters for user experience. VisionCamera takes 300 to 500ms to initialize and display the first preview frame. Expo Camera is slightly faster at 200 to 400ms, likely because it defers some configuration until needed. Both are acceptable, but if your app opens directly to a camera screen, every millisecond counts.

Battery Consumption

Running VisionCamera with a frame processor and continuous ML inference consumes roughly 15 to 20% battery per hour of continuous use on an iPhone 15 Pro. Expo Camera with barcode scanning active uses about 10 to 12% per hour. The difference is the ML inference workload, not the camera library itself. If you run the same inference task on the same device, the battery cost is comparable regardless of which library feeds the frames. Plan your UI accordingly: do not leave ML inference running when the camera is in the background or when the user is reviewing results.

Beyond raw ML performance, there are practical development factors that influence which library you should pick.

AR Overlay Capabilities

Building AR-style overlays (bounding boxes, segmentation masks, pose skeletons drawn on top of the camera preview) requires two things: fast frame data and a performant rendering layer. VisionCamera provides the frame data side. For rendering, most teams pair it with react-native-skia from Shopify, which gives you a GPU-accelerated 2D canvas that can render complex overlays at 60 FPS. The combination of VisionCamera frame processors feeding coordinates to a Skia overlay is the standard architecture for AR-lite React Native apps in 2030.

Expo Camera does not provide the per-frame coordinate data needed for custom AR overlays. You can render static overlays (like a scanner target box) using regular React Native views positioned over the camera preview, but dynamic overlays that track detected objects in real time are not possible without frame-level data.

Expo Managed Workflow Compatibility

This is Expo Camera's strongest advantage. It works in the Expo managed workflow without ejecting or creating a development build. You install it with npx expo install expo-camera, add it to your component, and it works. No native code, no Xcode, no Android Studio. For teams that chose Expo specifically to avoid native toolchain management, this is a major selling point.

VisionCamera requires native code. In the Expo ecosystem, that means you need a development build (created via EAS Build or locally with npx expo prebuild). You cannot use VisionCamera in Expo Go. This is not necessarily a dealbreaker, because most production Expo apps already use development builds, but it does add a build step and some complexity. If you are in a bare React Native project (no Expo), VisionCamera installs like any other native library with pod install and gradle sync.

Developer Experience and Documentation

VisionCamera has excellent documentation, maintained actively by Marc Rousavy. The API reference is thorough, the guides cover common use cases, and the GitHub issues are responsive. The learning curve is steeper than Expo Camera because there is more to learn: frame formats, worklet threading, plugin architecture, camera device selection. Budget two to three days for a developer who is new to VisionCamera to become productive with frame processors.

Expo Camera's documentation is part of the broader Expo docs, which are consistently well-organized. The API surface is small, so the learning curve is minimal. A developer can go from zero to a working barcode scanner in about an hour. The trade-off is that when you hit the boundaries of what Expo Camera can do, the documentation cannot help you because the feature simply does not exist.

After building production apps with both libraries across dozens of client projects, here is our practical decision framework. This is not theoretical. It reflects real project outcomes and the feedback from teams that made the wrong choice and had to migrate.

Choose Expo Camera When

• Your camera needs are standard. Photo capture, video recording, QR/barcode scanning, and basic face detection. If your app's camera features could ship using the stock iOS or Android camera app, Expo Camera covers it.
• You are in Expo managed workflow and want to stay there. If your team chose Expo to avoid native complexity, switching to VisionCamera means adopting development builds and native tooling. That overhead is only worth it if you genuinely need frame-level processing.
• Speed of development is the priority. Expo Camera gets you from zero to working camera feature in hours, not days. For MVPs, proof-of-concept apps, or features where the camera is not the core value proposition, Expo Camera is the pragmatic choice.
• Your team does not have native mobile experience. VisionCamera's plugin system sometimes requires debugging at the native layer. If nobody on your team can read Objective-C, Swift, Java, or Kotlin error logs, you will struggle when things go wrong.

Choose VisionCamera When

• You need real-time ML inference on camera frames. Object detection, image classification, pose estimation, text recognition with custom models, or any feature that requires processing every frame. This is VisionCamera's core purpose and Expo Camera's hard limitation.
• You are building AR-style overlays. Dynamic bounding boxes, segmentation masks, or any visual element that tracks objects in the camera feed. You need frame-level data for this, and only VisionCamera provides it.
• You need fine camera control. Custom formats, manual focus, exposure compensation, 60 FPS capture, RAW photo output, or simultaneous front/back camera use. VisionCamera exposes these native capabilities. Expo Camera does not.
• Performance is non-negotiable. Warehouse scanning apps that process 500+ barcodes per hour, quality inspection systems on manufacturing lines, accessibility tools that need sub-50ms response times. These use cases demand the frame processor architecture.
• You plan to integrate TFLite, Core ML, or ONNX models. VisionCamera's plugin ecosystem has mature, maintained integrations for all major ML runtimes. Trying to achieve this with Expo Camera will lead you to architectural dead ends.

The Middle Ground

If you are unsure, start with Expo Camera and a development build. You get the simplicity of Expo's camera API today, and because you are already on a development build, migrating to VisionCamera later is a swap of one library, not an architectural overhaul. The key is making the development build decision early so you are not locked into Expo Go when you realize you need more power. For teams building computer vision for business applications, VisionCamera is almost always the right starting point because the requirements inevitably grow beyond what Expo Camera can support.

Whichever path you choose, the React Native camera ecosystem in 2030 is mature enough to build genuinely impressive on-device AI experiences. The tooling works, the performance is real, and the gap between native and cross-platform camera apps has narrowed to the point where most users cannot tell the difference.

If you need help choosing the right camera architecture for your mobile AI project, or you want a team that has shipped production VisionCamera apps with real-time ML inference, book a free strategy call and let us walk through your requirements together.