Issue #19
We’ve spoken to a lot of you, and one request keeps bubbling up: “when can React Native apps ship Live Activities?”
It’s obvious why — there’s something beautifully smug about watching your app update itself on the lock screen without ever reopening it. But yeah, the devil is in the iOS widget weeds, and that’s exactly why we’re picking this as our first deep dive.
Live Activities are Apple’s framework for showing real-time updates outside your app — on the Lock Screen, and on newer iPhones, inside the Dynamic Island. Think of them as reactive widgets for the real world: a countdown timer, a delivery tracker, or that ever-hopeful “Your driver is nearby” message.
The Dynamic Island, despite all the branding sparkle, isn’t a separate feature. It’s just one of the places iOS renders a Live Activity. On iPhone 14 Pro and newer, the system automatically adapts your Live Activity layout into that little pill at the top of the screen. You don’t “build for the Dynamic Island” — you build a Live Activity, and iOS does the rest.
So what can React Native do right now with these advanced features?
Software Mansion Labs is paving the way with expo-live-activity, a tidy Expo module that lets you start, update, and stop Live Activities directly from JavaScript. It auto-generates the native SwiftUI target for you, so you can skip Xcode altogether. A simple example looks like this:
Under the hood, this spins up a predefined SwiftUI layout — title, subtitle, progress bar, image — and calls it a day. You can change colours, tweak some padding, swap an icon, or switch the timer style, but you’re still decorating someone else’s template. There’s no control over the layout, no custom SwiftUI views, and no way to inject logic or interactivity beyond what the config allows.
So yes, it works — but only if your idea of design freedom is picking between “left image” or “right image.” For now, expo-live-activity feels less like a toolkit and more like a demo that grew legs: a quick way to tick the “supports Live Activities” checkbox, not a canvas for building something truly bespoke.
That’s why Saúl Sharma’s (@saul_sharma) tease of Voltra immediately turned heads. While Software Mansion’s implementation wraps Apple’s API in Expo-flavoured convenience, Voltra seems to be chasing something bolder — a system that lets you define Live Activities, Widgets, and even Dynamic Island UIs directly in React. No Swift, no manual Xcode target setup, no silent prayers to the provisioning gods.
If it delivers, it could flip the model entirely: instead of JSON configs piped into a locked Swift template, you’d be writing declarative React components that compile down to native SwiftUI layouts. Real control. Real customisation. Real risk that we’ll all start building over-animated flight trackers for no reason other than because we can.
Right now, Voltra’s still in teaser territory — a few tweets, some screenshots, and the hint of a broader “React for native extensions” idea — but if it lands anywhere near the hype, it could be the first tool that actually makes Live Activities feel like part of the React Native ecosystem, not an awkward bolt-on borrowed from iOS.
👉 Expo Live Activity
NativeWind 5.0 is here — or at least peeking over the horizon — and it’s looking like the biggest shake-up since the library first brought Tailwind syntax to React Native. The library premieres with Tailwind 4 support, a cleaner setup, and, most intriguingly, a brand-new React Native CSS engine that aims to bring real CSS semantics to native styling.
The team behind NativeWind says the goal is simple: less wiring, more styling. The installation guide is now mercifully short — gone are the multi-step Metro tweaks and endless Babel configs. Just install, run, and Tailwindify away.
But the real story here is React Native CSS — a new library built to provide the most complete CSS support ever seen in React Native. Instead of a clever translation layer, it’s an honest-to-goodness implementation of CSS properties, cascades, and inheritance running natively. That means things like custom properties (CSS variables), selectors, and complex layout behaviour could finally act as they do on the web — without React Native’s usual “good enough” shim.
This update quietly turns NativeWind into what it was always meant to be — a true Tailwind layer across React and React Native, not another styling abstraction.
Under the hood, NativeWind now compiles your Tailwind classes into StyleSheet.create objects on native, while reusing real CSS stylesheets on web. That means one Tailwind config, one class naming system, and consistent behaviour across both worlds — no more maintaining parallel design tokens or rewriting responsive logic twice.
Of course, NativeWind isn’t the first to chase cross-platform styling. Frameworks like Unistyles and Tamagui already deliver shared design systems that work on web and native allowing us to build Universal Apps. The difference here is NativeWind 5.0 doubles down on CSS. It’s less “a new framework,” more “React Native finally learning to speak fluent CSS.”
Of course, with great power comes great migration guides. The v5 preview is still early, and the docs (see the NativeWind 5.0 Preview) make it clear that some APIs and behaviours are changing. You may need to refactor utilities, update variants, and re-test your class precedence logic.
Still — NativeWind 5.0 feels like a major step toward closing the gap between CSS and React Native styling once and for all. If the new engine performs as advertised, this could finally be the version that makes “Tailwind everywhere” more than a slogan.
👉 NativeWind 5.0 Preview
If you enjoy fetching as much as my Border Collie, you’re going to love the new library Marc Rousavy (@mrousavy) just threw at us.Nitro Fetch is a new network library built on top of Nitro Modules — Rousavy’s shiny C++–powered framework for creating lightning-fast native modules in React Native. The goal? Replace the ageing, bridge-bound fetch() API with something truly native, low-latency, and JS-thread-free.
Unlike the standard fetch, which involves JavaScript bridge communication, Nitro Fetch runs directly on the native layer using Cronet on Android (Google’s ultra-optimised HTTP stack) and URLSession on iOS. That means support for HTTP/1, HTTP/2, HTTP/3, Brotli compression, disk caching, and — the real flex — prefetching. You can literally warm up your network requests before you need them.
But the clever bit is how Nitro Fetch handles mapping. You can transform or parse responses directly inside a worklet (a JavaScript function that runs off the main JS thread) using react-native-worklets-core — meaning no more JSON parsing jank mid-scroll.
Now, before you start replacing every network call in your app. Nitro Fetch is still in early alpha. There’s no streaming support yet, no WebSockets, and limited middleware-like interception. Think of it as a proof of concept for what Nitro Modules can do when they’re let off the leash.
The potential, though, is massive. For years, React Native’s networking stack has been limited by the old bridge — every request crossing that boundary adds latency, churn, and, occasionally, tears. With Nitro Fetch, we’re looking at a world where data fetching, caching, and transformation happen natively, leaving JavaScript to orchestrate, not babysit.
👉 Nitro Fetch
We mentioned in issue #14 the Node API coming to React Native. In plain English, that means the React Native runtime is gaining low-level access to the same system APIs Node.js uses — think file I/O, network sockets, and OS-level operations — but running inside React Native instead of a browser or server.
At the time, plenty of folks (us included) blinked at that and thought: “ah, another mysterious term we pretend to understand in meetings.”. Well — we’re beginning to see hints of what it can do.
Jamie Birch (@birch_js) recently teased direct API access from JavaScript into native layers — yes, you read that right: you might soon be calling Swift APIs directly from JS.
No, we’re not at “plug-in one library and do all the magic” yet. This is early, experimental, and exploratory. But the seed is planted, and conversations among community leaders — folks like Marc Rousavy — are underway to define safe, ergonomically sane APIs for this kind of sorcery.
There are big questions to solve: safety, threading, error boundaries, memory management, versioning, and how this plays with existing RN architecture like Fabric, TurboModules, JSI, etc. But what Jamie sketched is a glimpse of what could be next.
👉 Jamie Birch Tweet
