Issue #11
In a move that’s as crisp as its ❄️ emoji, React Native maintainer @cipolleschi confirmed that as of June 2, 2025, the Legacy Architecture is frozen. No more features. No more bug fixes. No more test coverage. Starting with 0.81, any app still running on the old bridge is officially in “good luck” territory.
This shouldn’t come as a shock: the New Architecture has been stable since 0.76 and is the default in Expo SDK 53. What’s new in 0.80 is the introduction of runtime warnings in React Native DevTools—your app will now gently (but firmly) warn you if you’re using APIs that won’t work under the new system. If your library still talks to native code like it’s 2017, it’s time to start moving to TurboModules and Fabric.
But React Native 0.80 isn’t just freezing the Legacy Architecture—it’s also laying the foundation for a more stable JavaScript API. Historically, the react-native package let you import just about anything if you knew the right file path. For example:
These internal paths weren’t part of the public API—they just happened to be reachable. If Meta moved or renamed a file, your app broke, and you were left wondering why a minor upgrade triggered TypeScript chaos.
To fix this, 0.80 introduces the Strict TypeScript API: an opt-in type system that only includes what’s exported at the top-level of the react-native package:
The magic here is under the hood: the new types are generated directly from the actual React Native source code, not hand-written or community-maintained. That means they’re more accurate, better aligned with how the runtime behaves, and way less likely to drift over time.
To opt in, update your tsconfig.json like this:
That one line tells TypeScript to resolve types from React Native’s new types_generated/ directory—an auto-generated set of types built directly from the source code.
If you’ve never had issues with React Native’s types, that’s kind of the point. The old system worked, but it was duct-taped together and prone to silent breakage. Opting in gives you a cleaner boundary and makes future upgrades safer.
As for @types/react-native, it’s still in use—but not for long. We predict the goal is to ship types with React Native itself, no DefinitelyTyped required. Strict mode is the first real step in that direction.
And if nothing breaks when you opt in? Congrats. You’re already ahead of the curve.
👉 Freezing the Legacy Architecture
👉 Moving Towards a Stable JavaScript API
Microsoft just opened a draft PR that proposes adding Node-API (N-API) support to Hermes.
Node-API is the low-level interface that native modules use to plug into Node.js. It’s how modules like SQLite, bcrypt, or native image processing libraries get their speed—by skipping JavaScript entirely and hooking into C++ or Rust under the hood. If Hermes eventually supports this, React Native could start reusing those same battle-tested native Node modules, instead of relying on hand-written native bridges or rewrites that barely survive major SDK upgrades.
But here’s the real kicker: the Hermes team wants to use Node-API internally, too. Instead of reimplementing massive JavaScript features like Intl (for internationalization) or Temporal (for handling time and dates), Hermes could load them as precompiled native modules. That means faster performance, better spec compliance, and fewer edge-case bugs when your app needs to support a dozen languages or complex date logic.
Right now, it’s still early days—this pull request isn’t merged, and there are open questions about static builds and architecture. But even as a proposal, it shows Hermes is trying to level up—not just as “the JS engine for React Native,” but as a first-class JavaScript runtime that can share code, modules, and capabilities with the wider JS world.
Storybook 9 is out, and it’s not shy about its ambitions. If you’re new here, Storybook is a tool for developing UI components in isolation—basically a sandbox for your design system. This release positions Storybook not just as a component explorer, but as a full-on testing workbench—pulling in Playwright for interaction testing, Vitest for unit coverage, and weaving in a unified test widget UI so you can click a button and feel like QA royalty. Add in accessibility and visual regression tools, and suddenly Storybook’s looking like the DevTools equivalent of a Swiss Army knife.
The headline features include smarter story generation, tag-based organization (finally, some structure in our lives), and global story-level settings for theme, viewport, and locale. Oh, and it’s 48% leaner thanks to modular installs. Minimal bloat, maximum clout.
But here’s the real flex for mobile devs: React Native and React Native Web can now run side-by-side in the same project. That means you can develop components on real devices or simulators, and test and document those same components using the full-featured Storybook Web UI—all in one codebase. It’s a dual-mode setup that lets you stay native and enjoy the perks of browser tooling.
In Rewind #3, we mentioned that Storybook was aiming for synchronised web/native releases. With v9, that promise is looking more like a practice. The React Native v9 changelog confirms support for the new test runner, visual regression features, and docs mode enhancements—yes, even on mobile.
This also hints at a broader trend: more tooling is going cross-platform without splitting the ecosystem. As Expo, Radon IDE, and Storybook blur the lines between web and native, Storybook’s newfound unity means we can stop saying “React Native version coming soon” and start saying “Try it now.”
👉 React Native v9 Release Notes
Apple dropped Liquid Glass at WWDC 2025 like it was announcing a new iPhone made entirely of vibes. Translucent panels, blurred tab bars, glowing switches, and app icons that gently bubble—as if dipped in a high-tech resin. It’s not quite skeuomorphic, not quite flat. It’s giving… frosted LaCroix.
The response? Somewhere between meh and MAKE IT STOP. Reddit threads are flooded with critiques of the new Clock icon (“a real mess”), design folks are panicking over accessibility issues, and meme culture has already branded it “iOS LAVA LAMP.” Meanwhile, the general tech mood has been: “We asked for AI. Apple gave us vibes.”.
But here’s the kicker for React Native devs: this shift isn’t just aesthetic—it’s functional. Native components like Switch, Button, and even navigation elements now inherit Liquid Glass automatically, as confirmed by @Baconbrix. He’s running it in Expo using stock React Native components—no sorcery, no blur hacks. If you’re using React Navigation (which Expo Router is built on), you’re probably already compatible.
So yes, your app can look like iOS 26 with zero effort—unless you want to go off-road with custom frosted headers, modals, or bottom sheets. In that case, react-native-blur and reanimated are still your friends.
Just be careful: too much blur and your app starts looking like a Lana Del Rey album cover during a heatwave. You want subtle mist, not full fog machine.
expo-pencilkit-ui is a new wrapper around Apple’s PencilKit, the iPadOS-native drawing framework that powers Notes-style sketching. This package lets you embed a true PencilKit canvas inside your Expo app—no ejecting, no Xcode wrangling, and no Objective-C flashbacks required.
Created by @tarikfp, the library leans on the power of expo-dev-client, allowing you to run custom native modules in an Expo project. Under the hood, it uses a small bit of native glue code to expose a <PencilKitView /> component to React Native. From there, you can draw, erase, and export your creations as base64-encoded PNGs.
This might not replace Figma, but it will make your kid think you’re a genius when you turn your iPad into a colouring app.
