Issue #21
Make sure to read until the end — we’ve packed this one with an exclusive discount for the upcoming and long-awaited RNLConf London, perfect for those of you craving a last-minute, spontaneous tech adventure.
.png)
There’s a quiet but significant shift happening in the React Native ecosystem: the way we build and consume native modules is evolving — fast. Two recent libraries, powered by Nitro Modules, signal where we are heading.
But wait… let’s rewind a bit.
In React Native, a native module is the bridge between your JavaScript and the platform-specific APIs — things like camera access, file storage, or device information. Historically (before the New Architecture), these modules relied on the asynchronous “bridge” system to shuttle data back and forth between JS and native code. It worked — but often at the cost of speed, type safety, and developer sanity.
React Native’s New Architecture changed that with Turbo Modules — a system built on JSI (JavaScript Interface) that enables direct, synchronous calls from JS to native code. It was a huge leap forward: faster, tighter, and designed for the concurrent rendering model introduced with Fabric (React Native’s new renderer that makes UI updates faster and more efficient with direct, async-free access to native views).
Nitro Modules take that foundation and add some very sharp developer ergonomics. Instead of hand-writing all your native bindings in C++, Objective-C, or Kotlin, Nitro lets you write a TypeScript definition file — and it auto-generates everything else. You get full type safety, no boilerplate, and a native module that feels like a regular JavaScript package. If you want to learn more about Nitro Modules we recommend a talk, The Past, Present & Future of Nitro by Marc Rousavy.
react-native-mmkv is a blazing-fast key/value storage library by @mrousavy, and it just hit version 4 — and this isn’t just a version bump. It’s a full rewrite on top of Nitro Modules.
If you’re unfamiliar, MMKV is a wrapper around Tencent’s MMKV — a high-performance C++ storage engine used in WeChat and other large-scale mobile apps. The React Native wrapper exposes its APIs, allowing for synchronous access from JavaScript. Think of it as AsyncStorage, but with a Red Bull addiction and no time for callbacks.
With the Nitro version 4 rewrite it simplifies the internal codebase significantly, optimises native calls even further, and does something clever: it restores support for the Old Architecture (at least up to RN 0.82), using Nitro’s flexible build setup. So if you’re still stuck in pre-Fabric land (god bless you), you can still use it. Although, there are some things you’ll need to do before upgrading, so don’t just close your eyes and hit install, go read the V4 Upgrade Guide.
That is not all.
Hey, we said this was a Nitro Revolution, right?
We also now have been gifted with react-native-nitro-device-info by @l2hyunwoo. It’s essentially a Nitro-powered reimplementation of react-native-device-info with 100% API compatibility, offering over 100 device properties (like manufacturer, OS version, memory, etc.) — but exposed synchronously, with full TypeScript support out of the box, and promises faster results.
Why does this matter? Because device info is one of those things you often need immediately — during app bootstrap, for conditional logic, or for telemetry (i.e. collecting environment data to help debug, monitor, or optimise your app in real-world usage) — and waiting on an async call adds unnecessary complexity.
Most methods are now direct property accessors for instant synchronous access:
Instead of complicating your application logic with:
Welcome to the future, where robots like Neo teach your dog emotional regulation, babies are grown in artificial pods, and we can finally write synchronous cross platform code.
👉 react-native-mmkv v4.0.0
👉 react-native-nitro-device-info
In the past, building a Universal App meant nervously tweaking webpack.config.js, sprinkling in .web.tsx files, and praying that react-native-web wouldn’t melt your layout.
Solito was created by @FernandoTheRojo to end that particular era of pain. It’s a small but powerful library that lets you share navigation and routing logic across React Native (Expo) and Next.js, without rewriting your app twice. In a Solito project, your native app and your website share screens, routes, and logic — with each platform still rendering the right components, at the right time.
In your native app, you use React Navigation:
In your website, the exact same ArtistScreen is rendered through a Next.js route:
And inside your shared screen, navigation stays consistent:
But let’s be clear: Solito already worked well before v5. So what does Solito 5 actually improve?
A lot — but quietly.
Solito has dropped react-native-web from its core. Instead of wrapping everything in View and Text, your components now render as native web elements on the web. That means your SolitoLink or screen components behave like regular DOM nodes — accepting className, inline style, and any standard HTML attribute. No extra wrappers. No config detours.
One question you may be asking is: how is Solito different from Expo Router?
Expo Router is ideal if you want a pure React Native experience, end to end — even on the web. That means your entire codebase uses the React Native primitives (View, Text, Pressable, etc.), and on the web, it’s rendered via react-native-web: a compatibility layer that maps those components to HTML under the hood. This gives you one universal component system, powered by Expo, and it “just works™” across platforms — mobile, web, and beyond — without touching Next.js or worrying about platform-specific routing.
Solito, on the other hand, is built for teams that want React Native for mobile, and Next.js for the web. It lets you share screens, navigation logic, and state across both — but each platform renders the right components for the job. On the web, you get actual DOM elements (div, a, span), not react-native-web shims. On mobile, you get real native views.
👉 Solito 5 Documentation
Remember when game engines and React Native lived in entirely separate universes — one focused on draw calls and real-time rendering, the other trying to scroll a FlatList without jank?
Well, forget all that.
@borndotcom just released react-native-godot, and it does exactly what the name says: it lets you embed a full-blown Godot engine instance inside your React Native app.
If you’re unfamiliar, Godot is a lightweight, open-source game engine for building 2D and 3D games. Think Unity, but without the multi-gigabyte installer or annual license debates. It’s got a scene graph, built-in physics, animation tools, scripting (via GDScript or C#), and it’s popular among indie devs for a reason: it’s fast, focused, and weirdly delightful.
The integration here is surprisingly elegant. You get a native <RTNGodotView> component you can drop into your RN layout. The engine runs on its own thread (not JS, not UI), so you can throw particle systems, skeletal animations, or full scenes at it without breaking your React Native frame rate. All of it’s controllable via TypeScript: instantiate objects, set properties, trigger events, hook up signals — just like you would in Godot’s native scripting environment, but from JavaScript.
This isn’t about building entire games in React Native — it’s about extending your app with real-time, interactive, embedded game like experiences where it makes sense. Think: character customisers, 2D/3D world viewers, interactive tutorials, physics-based learning tools, a 3D mascot that dances when your form passes validation.
You still build your menus, navigation, and screens in React Native. But when you need to drop in a fully interactive game engine? You treat it like a Video component — just one that happens to be alive.
👉 react-native-godot
There’s a new bottom tab navigator in town — and no, you’re not hallucinating that blur effect. React Navigations createNativeStackNavigator()’s sibling has arrived: createNativeBottomTabNavigator(), built for iOS and Android with full native performance and proper support for translucent, glassy, dare-we-say-it-again, Liquid Glass.
This isn’t your average JS-tab-bar-in-disguise. It’s rendered using native components under the hood, giving you smooth transitions, adaptive layout, and effects like iOS-style blur without resorting to hacks or overlays. Think of it as the tab bar version of react-native-screens — leaner and ready to blend into the OS like it belongs there.
.gif)
But before you go replacing all your createBottomTabNavigator calls, a quick disclaimer: this API is experimental. That means it’s subject to change, and it currently only supports iOS and Android. If you’re targeting web, you’ll still want to stick with the classic bottom tab navigator — for now.
So why use it? Simple: if you’re already working with React Navigation and want a completely native tab bar—complete with blur, a native feel, and improved gesture handling.
👉 Native Bottom Tabs Navigator
Btw, I — @lukebfarrell — will be at RNLConf thanks to @VadimNotJustDev from notjust.dev whom gifted me the ticket. So I will be possibly throwing down bars about Expo and Tamagui. Just joking. Maybe not. If you want to meet in person and chat about React Native, shoot me a DM — we can debug our apps while under our umbrellas in the London drizzle.
Oh, and we’ve got you a 10% discount for RNLConf tickets, just for Rewind readers with the code “REWIND10”. Because, as the saying goes — (now read like five people shouting in unison) “friends don’t let friends pay full price for conferences”.
👉 RNLConf Tickets - 10% off with “REWIND10”
