Who’s Actually Driving This Thing?

By now, you’ve probably clocked this — React Native isn’t driven by a central authority. It’s a constellation of companies, solo maintainers, rogue conference talks, and more than a few late-night GitHub cowboys.


You want to know who’s moving things forward?

Marc Rousavy — The C++ Master

Okay, so when we talk about Marc Rousavy, we need to unpack why he’s an important figure in the React Native community. To do that, we need to talk about Turbo Native Modules — and the shift to the New Architecture.

If you remember yesterday’s email, we broke down the difference between the old bridge and the newer system that lets JavaScript call into native code directly — faster, type-safe, and without serialising everything into JSON.

That system is called JSI (JavaScript Interface), and it’s the foundation for Turbo Modules.

A Turbo Native Module — often just called a Turbo Module — is React Native’s newer system for writing native modules. It’s part of the New Architecture and replaces the old bridge-based approach.

Turbo Native Modules are written in native code (Java, Objective-C, C++), but they rely on a TypeScript interface file to define the API surface. React Native uses this file to auto-generate the glue code that connects JS to native.

To illustrate the verbose nature of Turbo Modules, here’s what that looks like:

Then you’d need to do something like this:

Then you’d need to write up a header file (for example, if you’re building a module on iOS):

A lot of code, right? And we haven’t even gotten to implementation yet.

So, that is where Nitro Modules come in.

Nitro Modules are a community-built alternative to Turbo Modules, led by Marc Rousavy. Like TurboModules, they use JSI and run on the New Architecture — but they flip the developer flow.

Instead of starting with a TypeScript spec and generating native bindings, you define your module’s API once — using Nitro’s .nitro.ts format — and it handles generating both the native and JavaScript sides for you. This reduces boilerplate, keeps your types in sync.

They’re also fast — not because of some magic optimisation, but because they cut out layers. Nitro Modules use JSI to create statically generated bindings between JavaScript and C++, minimizing runtime indirection and avoiding the React Native Codegen/TurboModule infrastructure.

That tighter connection means less overhead and fewer round trips — which matters when you’re doing things like streaming camera frames, decoding images, or handling gestures in real time.

Evan Bacon — The Platform Whisperer

React Native launched in 2015 as a way to use React (and JavaScript) to build native apps for iOS and Android. Its ambition: learn once, write anywhere — share logic across platforms while still delivering native performance and feel.

As the ecosystem evolved, developers asked:

“Why stop at mobile? Why not web, desktop, even wearables?”

That gave rise to efforts like react‑native‑web (React Native Web allows React Native components and APIs to run seamlessly on web browsers using standard web technologies like HTML, CSS, and JavaScript). 

But translation‑layers only go so far.

Differences in navigation, routing, performance, and UX soon exposed the friction of “one codebase for all screens”.

One of the biggest friction points in multi-platform React Native has always been navigation.

Native platforms expect stacks and gestures. The web expects URLs and deep linking. WatchOS expects compact flows. Desktop expects windowed layouts.

Trying to abstract over all of that has historically meant picking a lowest common denominator — or wiring up a Frankenstein combo of React Navigation, deep link handlers, and screen nesting logic. It worked. Kind of. But it never felt like one coherent app.

That’s where Expo Router came in.

Instead of treating routing like a platform-specific problem, Expo Router treats it like a shared concern — with one solution that works across screens. Inspired by Next.js, it uses your file system as the source of truth. You create files like /settings/profile.tsx and Expo handles the rest: routing, params, layout nesting, deep linking — even web URLs.

This is React Native with a proper mental model. Navigation becomes predictable. Layouts are composable. Deep linking “Just Works”™.

And because it’s built on top of Expo, it works the same way across platforms — from Android and iOS to the web, visionOS, and even watchOS.

Evan Bacon is behind this push. He’s not just leading the work on Expo Router — he’s pushing React Native to be the frontend layer for every platform. The same app, running everywhere.

Krzysztof Magiera — The Interaction Architect

React Native promised native performance — but for years, that promise came with a caveat: as long as you didn’t need complex gestures or smooth animations.

The built-in gesture system (known lovingly as the “Gesture Responder System”) ran in JavaScript, on the same thread as your business logic and React updates. That meant every swipe, drag, or tap had to wait its turn. Fine for basic taps. A nightmare for fluid interactions.

Animations weren’t much better. The original Animated API worked — barely — but felt like animating through a straw. Frames dropped, interactions stuttered, and the whole system felt like it was bolted on after the fact.

For anything beyond a fade-in or transform, you were either writing native code or giving up on polish.

This is the world Krzysztof Magiera stepped into.

First with React Native Gesture Handler, he rewrote how gestures work in React Native — moving recognition to the native side, enabling reliable composition (like drags inside scrolls), and unlocking gesture patterns that weren’t even possible before.

Then came Reanimated — a complete rethink of how to run animations in React Native.

Reanimated doesn’t just run animations on the UI thread. It lets you write small, isolated pieces of logic — “worklets”. In React Native, worklets are small JavaScript functions that run on a separate UI thread, enabling smooth, high-performance animations and interactions without blocking the main JavaScript thread.

The result? Swipeable cards that snap. Bottom sheets that glide. Scroll interactions that feel native, because they are. And all of it — gestures, animations, layout updates — orchestrated in a way that plays nicely with React’s lifecycle and the New Architecture.

Krzysztof didn’t just patch the pain points. He redefined how React Native apps feel. And in doing so, made it possible to build interfaces in JS that don’t just run on mobile — they feel like they were born there.

And of course, we missed about 98% of the community who are also driving projects in React Native — but hey, if we tried to cover everything, this email would be about 233 pages long.