Issue #10
We’re making a couple of changes around here—nothing dramatic, but think of it as spring cleaning for your inbox.
First up, The React Native Rewind is moving to a biweekly schedule. Once a month felt like we were cramming for finals, and while we love a good deep dive, we’d rather keep things snappy, digestible, and regular enough that you don’t forget what Expo released two weeks ago.
Second, The Hitchhiker’s Guide to React Native is getting its own dedicated space on our site. So next time you hit a confusing term—be it JSI, TurboModules, or something Evan Bacon dreamt up at 3 a.m.—you’ll find the explanation (with memes, obviously) just a click away.
Because learning React Native shouldn’t feel like decoding alien tech. Unless you’re into that.
With Expo SDK 53, the New Architecture has officially moved from “nice-to-have” to “deal-with-it.” It's now enabled by default in all new projects. If you're still clutching onto the old bridge like it’s a cherished childhood blankie, you can opt out—but Expo is pretty clear: resistance is futile. As of April 2025, 74.6% of SDK 52 builds on EAS were already on the New Architecture, so the tide has turned. That means you’re getting JSI, Fabric, the concurrent renderer, and all the performance promises React Native 0.76 has been stacking up like unread Slack notifications.
Expo’s new Expo BackgroundTask module replaces the now-deprecated Expo BackgroundFetch, and it’s not just a rename—it’s a full overhaul. The old module (Expo BackgroundFetch) leaned on Apple’s Background Fetch API, which has been deprecated since iOS 13, and was barely holding it together with different mechanisms across Android and iOS (like JobScheduler). The result? Inconsistent behavior and barely any control for developers who needed something more than a background shrug.
In contrast, Expo BackgroundTask takes full advantage of platform-native APIs like WorkManager (Android) and BGTaskScheduler (iOS). It’s built for running deferrable tasks that won’t torch your user’s battery: cleaning up stale cache, syncing local data, or fetching updates via Expo Updates. It’s more modern, more predictable, and finally gives you the control you’ve been pretending you had.
If you’ve ever squinted at your React Native app and thought, “What if this also ran serverless functions like it was 2020 again?”—Expo Router v5 has your answer, and it’s not playing around anymore.
Previously a playground for dev builds, API Routes (files like app/hello+api.ts that handle requests like a mini server) are now first-class citizens in production. That means you can ship universal apps—UI, logic, and backend—all bundled with your native build.
Even better: debugging doesn’t suck anymore. Expo CLI’s error handling has been completely rewritten. Logs are now cleaner, context-aware, and honestly… kind of beautiful? Developers who’ve spent too long decoding spaghetti stack traces in monospaced purgatory will appreciate this one.
Oh, and in the same spirit of "what if mobile worked like the web?", you can now wipe all runtime JS state—just like a page reload—with location.reload(). That’s right. No 👌 surgical state resets. No tracking down rogue refs. Just hit reload and move on with your life. It clears the Hermes engine, React state, everything.
Wondering why we’re talking about EAS Hosting in a React Native newsletter? You’re not alone. But here’s the thing: if 2025 has a theme, it’s React Native finally making good on the “write once, run everywhere” promise.
Whether it’s Expo Router shipping first-class web support, Tamagui targeting native and browser UIs, or OneStack trying to merge it all under one holy framework, the community is converging on the idea that React Native isn’t just for mobile anymore—it’s multi-platform. And EAS Hosting is part of that shift. You can now build your app once and deploy it—client and server—across mobile and web, without duct tape or a separate DevOps team.
At the heart of it is expo export:web, a tool that’s been quietly powering Expo web deployments. But now, with full support for API routes in production, versioned deployments, and subdomains, EAS Hosting is no longer just a nice-to-have—it’s the hosting layer for your full-stack universal app.
In response to developer requests, the platform now supports:
It’s still one custom domain per project, but wildcard support goes a long way. You can stage, test, and segment deployments without wrangling multiple DNS setups.
Also worth noting: EAS Hosting’s dashboard now includes a file browser for worker deployments, showing your server code and client assets side-by-side. A tiny, obvious feature, sure—but one that removes a whole class of "wait, what did I deploy?" anxiety.
👉 EAS Hosting Changelog & Updates
No, your eyes aren’t deceiving you—WebGPU is running in React Native, and not in a “we rendered a spinning cube in a blog post once” kind of way. This is legit, performant GPU access inside a React Native app, and it’s… surprisingly smooth?
In a recent demo titled "Game On - Bringing WebGPU to React Native", the team showed off full integration of WebGPU—the modern graphics API that sits closer to the metal than WebGL—inside a React Native runtime. This means real access to compute shaders, modern rendering pipelines, and the kind of graphical fidelity that was previously the domain of native game engines or extremely patient OpenGL ES developers.
How? In short: by wrapping WebGPU bindings and exposing them through a native module tied to the JavaScript interface (JSI). Combine that with React Native Skia or CanvasKit and suddenly you’re looking at mobile apps that can push far beyond skeuomorphic UIs and into interactive 3D, data visualizations, or yes—actual games.
It’s early, and this isn’t in the Expo SDK (yet), but the implications are serious. We’re inching closer to a future where React Native isn’t just “good enough for apps”—it’s a legitimate canvas for GPU-heavy creative work.
👉 Watch the full WebGPU demo on YouTube
ExecuTorch 0.4.0 just dropped, and it's shaping up to be the Swiss Army knife of on-device AI in React Native. No, not just running a tiny model to recognise a banana—this version adds support for tool calling, text embeddings, multilingual speech-to-text, OCR, and even image segmentation. Basically, it’s what you'd expect from a cloud-hosted AI stack... except it runs entirely on your phone.
The real power here? No network latency. No server costs. No privacy trade-offs. Everything is executed directly on-device using Meta’s ExecuTorch runtime, exposed through native modules in React Native. That means LLMs can now live right inside your app and call tools like it’s a miniature LangChain, minus the server wrangling.
This release also makes it way easier to build intelligent UIs that can see, hear, and read. Want to transcribe a conversation, parse the screen with OCR, and respond intelligently in Korean? You’re covered. All of it runs on-device, without sacrificing speed or control.
And yes—ExecuTorch 0.4.0 is still open source and actively developed by @swmansion, who seem to be on a mission to make React Native smarter, faster, and way more private.
👉 React Native ExecuTorch 0.4.0 Release Blog
Hooks, they said. A beautiful abstraction, they said. And they are… until your component starts to resemble a five-headed hydra with memoized tentacles. At some point, that elegant useEffect starts feeling less like clean architecture and more like bait on a hook. You know—the kind that grabs ya by the britches.
Which brings us to Render Hooks, a new library from @brandonmcconnell that proposes something wild: calling hooks from inside your render return—without breaking the Rules of Hooks™.
Yep. It introduces a special wrapper component—<$>—which safely scopes hook usage to a function inside your render tree. Think of it like a portal for logic. Here's what it looks like:
This means you can colocate logic directly alongside the UI it powers, without having to write custom hooks or hoist state six files away. It’s still in early days, but the implications are big: hook scoping without the boilerplate, logic that travels with its view, and a mental model that’s a little closer to how we actually think about UI.
But.
We still need to talk about hooks. Because while they started as a way to "just manage state," they’ve since spiraled into a kind of architectural gravity well. They couple your business logic to your render cycle. They punish encapsulation. They get weird around async flows. And every new abstraction to tame them? It ends up being a hook too.
We’re all trying to get out from under the hook problem—but we're still dangling. Render Hooks is a fresh attempt, and it’s worth watching. But just know what you're tying your logic to.
React Native’s New Architecture is here (for real this time), but if you’ve ever found yourself deep in node_modules wondering whether react-native-super-obscure-scanner supports it, you’re not alone. Package Checker is a dead-simple tool that tells you which dependencies in your project are ready for the New Architecture—and which ones are still living in 2019. Paste in your package.json, and it’ll break things down by compatibility, linking directly to libraries’ GitHub repos and support status.
It’s fast, visual, and genuinely useful for planning an upgrade—or just satisfying that itch to know why your app is crashing in Fabric with no helpful error message.
Radon IDE continues to chip away at the dream of a native-first React Native dev experience, and the latest releases are exactly what you'd hope for: less jank, more tools, and smoother profiling.
v1.6 shipped with React Profiler integration, so you can finally pinpoint which components are re-rendering like it’s their side hustle. It also introduced conditional and expression-based breakpoints, making debugging feel less like spelunking and more like actual development. Plus, Expo SDK 53 support is in, keeping Radon aligned with the latest toolchain.
v1.7 was mostly bug fixes, but important ones—especially around simulator management and file watching (which were sometimes just… not). It’s not glamorous, but it’s the kind of polish that makes Radon feel less like a beta experiment and more like an actual IDE replacement.
If you’ve been bouncing between VSCode, Chrome DevTools, and three terminal tabs, Radon is worth a spin. It’s got momentum—and fewer tabs might just mean more sanity.
👉 Radon IDE 1.6, Radon IDE 1.7
This is the React Native Rewind. But here we are, talking about Lynx 3.2. Why? Because apparently, if you render a <View> and use CSS, you’re part of the React Native community now. ByteDance’s homegrown cross-platform framework continues to evolve, now with a full unit testing library for Lynx components and new CSS features like outline, filter, and backdrop-filter. Visual effects finally get their moment, and microtask scheduling improvements mean better cross-platform performance without the cursed stack traces.
Lynx is still doing its own thing—DOM-less rendering, native threads, and a styling system web developers can understand—but it’s shipping fast, touching enough adjacent tools that it’s hard to ignore. Whether it turns into a real alternative or just stays TikTok’s in-house Flexbox whisperer, we’ll keep an eye on it.
