Issue #22
We just got back from RNLConf London. If we met you in person, it was great to meet you! If we didn’t, make sure to subscribe—you’ll get a discount and maybe even a free ticket next time. Plus, you’ll get to enjoy: à la carte lunches, the thoughtful dialog about frameworks, and the chance to pretend you’re cultured in front of your peers—just like we did.
Without further ado, you’re reading The React Native Rewind #22.
So… Valdi (not a misspelling of Aldi) is probably something you’d expect to see while shopping for a new desk on the IKEA website. Although, it is not a cheap piece of DIY furniture shipped to your door.
It’s Snapchat’s new cross-platform framework for building iOS and Android apps, and — sigh — once again everyone is whispering… “Does this mean React Native is dead?”
Valdi, according to its README, is a cross‑platform UI framework from Snap Inc built on declarative TypeScript and compiling directly to native views on iOS, Android and macOS (so no web‑view wrapper, no JavaScript bridge). The appeal is obvious: ship with proper native feel and high performance. It also claims features like automatic view‑recycling, its own layout engine, and hot reload support.
Is Valdi faster than React Native? Probably.
It skips the JS bridge, compiles straight to native views, and has fewer moving parts. On paper, that should mean speed. But so does Flutter — and we’re not all rewriting our apps in Dart, are we?
Performance isn’t a problem React Native needs solving. It’s good enough for Instagram, Shopify, Starlink and Tesla — and unless you’re rendering particle systems in your onboarding flow, it’s good enough for you.
And that’s where Valdi starts to fade — like a Snap after 10 seconds.
Snapchat says it’s been using Valdi in production for eight years.
Cool. But outside of their app?
There’s no real ecosystem yet. No plugins, no Stack Overflow breadcrumbs, no conference talks, no open-source libraries you can drop in and get home in time for dinner. Just you, a shiny new framework, and a lot of problems to solve alone.
Meanwhile, React Native has spent nearly a decade building an actual ecosystem — massive plugin support, rich dev tooling, familiar syntax, and broad platform reach. Want to ship to iOS, Android, web, tvOS, or even Vision Pro? Go for it.
CI/CD? Bitrise, GitHub Actions, EAS — all dialled in.
And just look at the AI wave. Every other startup with a GPT wrapper and a Stripe account is sprinting to MVP (Minimal Viable Product) — and they’re not doing it in Valdi.
They’re shipping in React and React Native. Because when you’re moving at AI-speed, you don’t pick the cute new framework with one maintainer and no ecosystem — you pick the one that lets you build fast, hire easily, and deploy everywhere.
Every tool in your Twitter feed with a “magic” button?
You can bet it’s running on something from the React stack.
Not Flutter. Not Lynx, and not Valdi.
Because in 2025, you’re not building your AI startup on a framework named after a forgotten Eurodance DJ.
You’re building it on React Native.
👉 Valdi
So at RNLConf in London, Saad Najmi (@SaadNajmi) and Jay Meistrich (@jmeistrich) unveiled the latest updates to React Native macOS, you can checkout the talk slides here. But before we dive into what was announced, let’s briefly go over how macOS support actually works in React Native.
React Native macOS is a fork of React Native maintained by Microsoft, but don’t worry — it does NOT overwrite your normal react-native package.
When you add macOS support, you simply install an extra package called react-native-macos next to the regular one (they live side-by-side in node_modules).
Your iOS and Android builds keep using the official react-native exactly like before.
The magic happens in the generated Xcode project file:
It tells the macOS build:
“Hey, when someone runs the macOS app, run the bundling script from react-native-macos instead of the normal react-native.”
Metro still serves the same JavaScript bundle to all platforms, but when Xcode builds the macOS version, it quietly links to Microsoft’s fork. Your mobile apps never even notice the fork exists. One codebase, three platforms, zero drama.
Now, at RNLConf in London, Electron was causing quite the stir.
Electron’s been the default answer for cross-platform desktop apps, but let’s be honest —it’s basically Chrome wearing a fake moustache.
A full Chromium runtime is bundled into every app means your Hello World clocks in at ~260 MB and eats ~80 MB of RAM doing basically nothing. Spotify, somehow, burns 25% CPU to play an MP3. Because sure, let’s render UI with a web engine built for YouTube.
React Native macOS doesn’t play that game. It uses native views, native APIs, native performance. No Chromium. A Hello World app? ~20 MB in size, ~2 MB Memory. And it feels like a proper desktop app — you get things like drag-between-windows, native window management, proper keyboard events, without shoving postMessages across sandboxed browser contexts.
Microsoft has been pushing to stabilise the platform internally, aligning dependencies and closing gaps with the new architecture. Hermes now works. Fabric is in. Writing native modules has gotten way less painful.
Expo’s been getting involved too.
You can now wire up Expo Modules inside your macOS apps. There’s a bit of configuration needed, and not all modules are supported yet, but it’s a solid start toward making macOS development more streamlined.
And yes, people are shipping.
Infinite Red is rewriting Reactotron in React Native macOS.
Expo’s building tools like Expo Orbit.
Want to get in early while there’s still room to define the space?
If you maintain a native module, adding macOS support is probably one PR away from making you the default.
Lastly, they released new documentation, so go and check that out.
👉 React Native MacOS
If you don’t know about the Jelly Slider, congratulations—you haven’t been doom-scrolling social media and clearly have more impulse control than we do.
Anyway, we’ll save you the swipe (pun very much intended).
This is what the Jelly Slider looks like:
The Jelly Slider was making the rounds last week…
I guess for its “jellyness” and the fact that everyone seems to have forgotten what a sensible user experience looks like. Layering blur and effects onto everything like some kind of cyberpunk Kardashian.
You may not know, WebGPU is the new, super-fast way to talk directly to your GPU (Graphics processing unit) from JavaScript — perfect for silky-smooth 3D, animations, and effects.
That same “Jellyness” was re-created and is possible in React Native thanks to William Candillon (@wcandillon). A single GPU backend that spans iOS, Android, Web and visionOS (Apple's spatial computing thing).
So what is a single GPU backend? It means your app uses one single piece of code that talks directly to the graphics card, no matter if it’s running on iPhone, Android, Mac, or in the browser.
Under the hood it uses Dawn (Google’s open-source WebGPU engine) on native platforms, but automatically switches to the browser’s built-in WebGPU when you open the app in Chrome/Safari.
Same exact JavaScript code, same Three.js scenes, same spring physics — and no platform-specific hacks.
With react-native-wgpu v0.4.0, you’re looking at what the WebGPU specification promised for browsers, but now inside React Native apps too. Here is what the code looks like:
According to its maintainers, this release brings full web compatibility, meaning your WGSL shaders written once can target everything from mobile, desktop to web.
So what could react-native-wgpu realistically be used for?
Well, it actually has a great use case for building VR applications. React Native for Meta Horizon is starting up, and they’re giving out $1.5 million in cash prizes in a hackathon this month.
Yes, $1.5 million—enough to buy…
A modest one-bedroom in San Francisco with “character”…. and probably on the suburbs.
👉 react‑native‑wgpu v0.4.0
If you’ve been following us lately, you probably already know what Nitro is.
If not, we did a breakdown of it in the previous issue: #21.
More React Native libraries are going Nitro.
react-native-ble-nitro by @zykeband gives you a high-performance BLE API across iOS and Android, BLE (Bluetooth Low Energy) is a wireless protocol for short-range communication with minimal power drain—great for talking to sensors, wearables, and smart gadgets.
You can scan like this:
It also covers Bluetooth state detection, connection management, RSSI filtering, and includes TypeScript types out of the box.
On the other side, react-native-nitro-event-kit by Vladyslav Martynov targets iOS’s EventKit API (Apple’s native framework for accessing calendar and reminder data), letting you read and write calendar data natively.
.png)
It handles permission checks, calendar fetching, event CRUD, and even alarms — all through a modern JSI-native interface.
The Nitro wave is about rewriting the expectations.
These modules don’t just run faster—they feel better to use. Typed, modern, and actually enjoyable to drop into a React Native codebase.
Looking to join the Nitro wave?
👉 Awesome Nitro Modules
.png)