Nitro gets attention for speed, but Marc Rousavy makes a different case for it in this interview. The bigger shift is that Nitro gives React Native modules a more powerful and more flexible API surface to build on. Native state, first-class array buffers, C++ interop, and stateful native objects are part of that. Some of the workloads he points to simply do not fit the older patterns.

Vision Camera is the clearest example. A camera frame is a stateful native object, and Nitro gives Marc a way to represent that directly. That is also why Vision Camera V5 opens up more room for native extensions, ML Kit, OpenCV, computer vision pipelines, and GPU-heavy workflows that would be harder to model in older module systems.

The web GPU work pushes that even further. Marc talks through importing Vision Camera frames as web GPU textures and running compute shaders on top of them. That means zero-copy GPU buffer reuse and a path toward computer vision workloads that stay close to JavaScript and shader code instead of dropping straight into custom native dependencies for everything.

The same pattern shows up in Nitro Image. Before that, image workflows often meant copying files to disk, passing file paths around, or even moving base64 strings through the system. Here the image stays in memory as a binary type. That cuts out one of the most wasteful parts of older image-picking and image-processing flows.

He also points to a bigger ecosystem question. If more modules move to Nitro, there is room for a more unified API style, shared types, and reusable building blocks across libraries. That is already starting to happen with types like Nitro Image.