react-native-compressor has moved to Nitro Modules Huge thanks to @margelo_com for Nitro 🙌 Repo: github.com/numandev1/react-n… @reactnative @expo #ReactNative #expo #NitroModules

This is using the latest react-native-macos (thanks @SaadNajmi) on new architecture with LegendList, react-native-enriched-markdown (thanks @G_Moskaliuk and @swmansion), and NitroModules (thanks @mrousavy and @margelo_com). Excited to clean it up and release an MVP soon!

And maybe this is what we should be doing in React Native, too. Build out systems in TypeScript, get it working well, and then switch to TurboModules (or NitroModules, ExpoModules) for the most performant version before shipping. Just thinking out loud. Giant grain of salt.

The standard fetch in React Native is a JavaScript polyfill. Every response gets parsed, decoded, and wrapped in JS before you touch it. react-native-nitro-fetch, developed by the team at Margelo, just hit its 1.0.0 milestone, a drop-in replacement for the standard Fetch API, built on the Nitro Modules core. 𝗪𝗵𝗮𝘁'𝘀 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴? React Native's built-in fetch is a spec-compliant JavaScript implementation sitting on top of the platform's native networking stack. That means every response goes through JS-side decoding, Response/Blob wrapping, and text parsing before your code sees a single byte. For small JSON payloads, it's fine, but for large responses, streaming, or anything latency-sensitive, that JS work adds up. react-native-nitro-fetch moves that pipeline into C . By leveraging Nitro's JSI-based architecture, response handling happens natively and hands off to your JavaScript with zero serialisation in between. 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀? ➡️ 𝗗𝗿𝗼𝗽-𝗶𝗻 𝗥𝗲𝗽𝗹𝗮𝗰𝗲𝗺𝗲𝗻𝘁: It follows the standard Fetch API specification, meaning you can often switch libraries just by changing your import statement without rewriting your logic. ➡️ 𝗡𝗶𝘁𝗿𝗼-𝗣𝗼𝘄𝗲𝗿𝗲𝗱 𝗦𝗽𝗲𝗲𝗱: By using C and Nitro Modules, it bypasses the traditional bottlenecks of the React Native bridge for significantly faster response parsing. ➡️ 𝗦𝘁𝗿𝗲𝗮𝗺𝗶𝗻𝗴 𝗦𝘂𝗽𝗽𝗼𝗿𝘁: It supports efficient body streaming, which is a game-changer for handling large datasets or real-time AI responses without spiking memory usage. ➡️ 𝗧𝘆𝗽𝗲 𝗦𝗮𝗳𝗲𝘁𝘆: Since it’s built with Nitro, it integrates seamlessly with TypeScript, ensuring that your network layer is as robust as the rest of your app. The release of 𝟭.𝟬.𝟬 marks a shift toward making React Native networking as performant as native code. If you’re building data-heavy applications or just want to shave those extra milliseconds off your load times, it's worth a look. #ReactNative #NitroModules #Networking #Performance #MobileDev #JavaScript #TypeScript #OpenSource #SoftwareEngineering #Margelo #API #WebDev

If you've ever tried to build a drag-and-drop grid in React Native, you know the struggle. Getting those smooth, fluid animations while items reshuffle their positions without dropping frames is a massive performance hurdle. Most solutions end up feeling "janky" because they can't handle the heavy layout calculations fast enough on the main thread. 𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗿𝗲𝘀𝗵𝘂𝗳𝗳𝗹𝗲𝗱 is a specialised grid layout library designed to solve exactly that. 𝗪𝗵𝗮𝘁’𝘀 𝗶𝗻𝘀𝗶𝗱𝗲? ➡️ 𝗡𝗶𝘁𝗿𝗼-𝗽𝗼𝘄𝗲𝗿𝗲𝗱 𝗘𝗻𝗴𝗶𝗻𝗲: The library now utilises 𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗻𝗶𝘁𝗿𝗼-𝗺𝗼𝗱𝘂𝗹𝗲𝘀. This allows for near-instant communication between the native side and JavaScript, ensuring that complex grid reshuffling remains butter-smooth even with dozens of items. ➡️ 𝗼𝗻𝗗𝗿𝗮𝗴𝗘𝗻𝗱 𝗪𝗼𝗿𝗸𝗹𝗲𝘁 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀: You can now execute custom logic directly on the 𝗨𝗜 𝘁𝗵𝗿𝗲𝗮𝗱 when a drag interaction finishes. By using 𝘄𝗼𝗿𝗸𝗹𝗲𝘁𝘀, you bypass the asynchronous nature of the standard bridge, allowing for immediate response and state synchronisation. ➡️ 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲𝗱 𝗚𝗿𝗶𝗱 𝗟𝗼𝗴𝗶𝗰: The underlying reshuffling algorithm has been refined to handle dynamic item movements more predictably, eliminating the "flicker" often seen in less optimised grid libraries. 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀? The biggest challenge in mobile UI development isn't just making it look good—it's making it feel responsive. By leveraging 𝗡𝗶𝘁𝗿𝗼 and 𝘄𝗼𝗿𝗸𝗹𝗲𝘁𝘀, 𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗿𝗲𝘀𝗵𝘂𝗳𝗳𝗹𝗲𝗱 minimises the execution time for expensive layout changes. It transforms the drag-and-drop experience from a heavy JavaScript task into a high-performance native interaction. If you're building a dashboard, a photo gallery, or a customisable home screen, this update makes 𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗿𝗲𝘀𝗵𝘂𝗳𝗳𝗹𝗲𝗱 one of the most performant ways to handle interactive grids in the ecosystem right now. #ReactNative #NitroModules #MobileDev #OpenSource #JavaScript #TypeScript #UIUX #GridToolkit #SoftwareEngineering #Reanimated #DeveloperTools #MobileApps

Solution: A C gRPC client shared across iOS and Android via @mrousavy's NitroModules. The entire request lifecycle, inclduing protobuf encoding, api call and response decoding, runs on a background thread. The only thing hitting JS is a JSON.parse() call.

Native gRPC architecture for @reactnative JS → NitroModules (thanks @mrousavy) -> Swift background thread → gRPC call → protobuf decode → JSON string → back to JS Only JSON.parse() blocks the main thread. Everything else is off-thread. Building this now. Thoughts?

Marc Rousavy continues his habit of releasing blazingly fast NitroModules-based libraries with react-native-nitro-image, which allows image manipulation without having to wait for file I/O.

Native markdown rendering for React Native using Nitro Modules. Offloads parsing to C to keep the JS thread free. Fully compatible with Expo. github.com/JoaoPauloCMarra/r… #ReactNative #Expo #NitroModules #MobileDev @mrousavy nitro modules are amazing!

TIL in NitroModules you can just access the react application context like this on Android

𝗪𝗮𝗻𝘁 𝘂𝗹𝘁𝗿𝗮‐𝗳𝗮𝘀𝘁 𝗱𝗲𝘃𝗶𝗰𝗲 𝗶𝗻𝗳𝗼 𝗮𝗰𝗰𝗲𝘀𝘀 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗥𝗲𝗮𝗰𝘁 𝗡𝗮𝘁𝗶𝘃𝗲 𝗮𝗽𝗽? 𝗦𝗮𝘆 𝗵𝗲𝗹𝗹𝗼 𝘁𝗼 𝗿𝗲𝗮𝗰𝘁‐𝗻𝗮𝘁𝗶𝘃𝗲‐𝗻𝗶𝘁𝗿𝗼‐𝗱𝗲𝘃𝗶𝗰𝗲‐𝗶𝗻𝗳𝗼 — built on the new architecture of react‑native‑nitro‑modules for direct, synchronous access to native device details. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗯𝗿𝗶𝗻𝗴𝘀: ➡️ Over 100 device properties, including model, brand, system version, memory/storage stats. ➡️ Most APIs are synchronous now — e.g., DeviceInfoModule.deviceId instead of an async call. ➡️ Developer‑first: full TypeScript definitions, migration path from the older react‑native‑device‑info. 𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: ➡️ If your app bootstraps and immediately needs device info (before UI or JS flows), a synchronous API can simplify logic. ➡️ Less overhead: no await/Promise for simple device queries. ➡️ Aligns with the new architecture strategy: using JSI/JS‑native interface. Do you have a use case where you need device‑info very early (startup, native modules, heavy logic) where synchronous access gives you an advantage? #ReactNative #NitroModules #DeviceInfo #MobileDev #OpenSource #JSI #TypeScript #Performance #NativeModules #CrossPlatformDev

And of course NitroModules and what @mrousavy has moved forward in the community with mmkv is also very notable.

Ever wanted to access calendar events in a React Native app? Apple provides an API called EventKit — a native framework that lets iOS apps read and write to the user’s calendar and reminders. It’s used for things like: ➡️ Fetching upcoming calendar events ➡️ Creating and editing new events ➡️ Integrating with the system calendar UI ➡️ Accessing reminders or alerts That’s where this new module comes in: react-native-nitro-event-kit brings EventKit to React Native using NitroModules — the new module system designed for the modern architecture. 𝗪𝗵𝗮𝘁’𝘀 𝗮 𝗡𝗶𝘁𝗿𝗼𝗠𝗼𝗱𝘂𝗹𝗲? It’s a modern way to write native modules in React Native. ➡️ You define your module’s interface in TypeScript ➡️ Native bindings (Swift/Kotlin) are generated via codegen ➡️ JS communicates with native code directly through JSI. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝗺𝗼𝗱𝘂𝗹𝗲 𝗱𝗼𝗲𝘀: ➡️ Wraps Apple’s EventKit framework via a NitroModule ➡️ Exposes calendar access to JavaScript in a safe, typed way ➡️ Can be used in apps that rely on native calendar integration — booking, scheduling, reminders, productivity tools. ➡️ iOS only (EventKit is not available on Android) Do you have a use case for EventKit in your app? #ReactNative #EventKit #NitroModules #NewArchitecture #MobileDev #iOSDevelopment #NativeModules #JSI #Swift #CalendarAPI #OpenSource

react-native-mmkv has dropped v4. 𝗜𝘁’𝘀 𝗮 𝗳𝘂𝗹𝗹 𝗿𝗲𝘄𝗿𝗶𝘁𝗲 𝘂𝘀𝗶𝗻𝗴 𝗡𝗶𝘁𝗿𝗼 𝗠𝗼𝗱𝘂𝗹𝗲𝘀 — and that brings real benefits for both performance and developer experience. If you haven’t used it before, 𝗠𝗠𝗞𝗩 𝗶𝘀 𝗮 𝗵𝗶𝗴𝗵-𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗸𝗲𝘆/𝘃𝗮𝗹𝘂𝗲 𝘀𝘁𝗼𝗿𝗮𝗴𝗲 𝗲𝗻𝗴𝗶𝗻𝗲 𝗯𝗮𝘀𝗲𝗱 𝗼𝗻 𝗧𝗲𝗻𝗰𝗲𝗻𝘁’𝘀 𝗖 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 (used in WeChat). It gives you synchronous, on-device storage with near-zero overhead. 𝗪𝗵𝘆 𝗡𝗶𝘁𝗿𝗼𝗠𝗼𝗱𝘂𝗹𝗲𝘀 𝗺𝗮𝘁𝘁𝗲𝗿: Nitro isn’t a new runtime — it’s a better way to define native modules in projects already using the New Architecture. Instead of writing native boilerplate in Objective-C, Java/Kotlin, or C , you define a TypeScript interface, and Nitro handles the native bindings through codegen. ➡️ You get type safety, no manual registration, and modules that feel like regular JS packages — but run on the same underlying system as JSI-native modules. ➡️ This clarity in DX is what makes Nitro compelling — especially for small utilities and widely shared packages. If you’re curious, Marc Rousavy’s talk “The Past, Present & Future of Nitro” is a great primer. 𝗪𝗵𝗮𝘁’𝘀 𝗻𝗲𝘄 𝗶𝗻 𝘃𝟰? ➡️ Fully rewritten on top of Nitro Modules. ➡️ Auto-generated native bindings from a TypeScript interface — no boilerplate C or ObjC. ➡️ Full type safety IDE support. ➡️ Still supports the Old Architecture (up to RN 0.82), thanks to Nitro’s flexible build system. 𝗕𝗲𝗳𝗼𝗿𝗲 𝘆𝗼𝘂 𝘂𝗽𝗴𝗿𝗮𝗱𝗲: ➡️ Read the v4 Upgrade Guide. ➡️ There are breaking changes and config updates. Are you already using MMKV in your app? #ReactNative #NitroModules #DeviceInfo #MobileDev #OpenSource #JSI #TypeScript #Performance #NativeModules #CrossPlatformDev

No SMS permissions. No user prompts. Just automatic OTP detection — handled natively on Android. Introducing @huymobile/react-native-sms-retriever-nitro-module, a React Native library that brings Google Play Services SMS Retriever API to the new architecture — built with Nitro Modules 💨. That means: ➡️ No READ_SMS permission. ➡️ No fake “SMS access” dialogs. ➡️ Automatic OTP retrieval (no permissions) ➡️ React Hook API — useSMSRetriever() ➡️ Full TypeScript support ➡️ Works with React Native 0.76 ℹ️ How it works: Your app registers with the SMS Retriever API, which watches incoming messages for your app’s unique hash (via getAppHash()). When a message arrives containing that hash, Google Play Services delivers the OTP straight to your app — without exposing full SMS contents or needing user consent. Privacy-safe, permissionless, and fully on-device. Built with Nitro Modules— not a legacy bridge wrapper. Designed for speed, smaller JS overhead, and clean interop with the new React Native runtime. Because nobody opens an OTP text thinking, “Ah yes, I can’t wait to type this in manually.” #ReactNative #AndroidOnly #NitroModules #TurboModules #OpenSource #MobileDev #OTP #TypeScript #ReactNativeRewind #GooglePlayServices

I've managed to get rid of macros and wrap async/promisified JSI code in a nice way It is still more verbose compared to NitroModules or ExpoModules but so much better than what I had before while still leaving room for fine tuned control. Besides the lambda declarations it's pretty straightforward so this I will definitely keep and use

𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗺𝗺𝗸𝘃 𝘃𝟰 is here — and as 𝗠𝗮𝗿𝗰 𝗥𝗼𝘂𝘀𝘀𝗮𝘃𝘆 teased at React Universe Conf 2025, it’s not just an update. It’s a 𝗿𝗲𝘄𝗿𝗶𝘁𝗲. If you haven’t used it before — 𝗿𝗲𝗮𝗰𝘁-𝗻𝗮𝘁𝗶𝘃𝗲-𝗺𝗺𝗸𝘃 𝗶𝘀 𝗮 𝗥𝗲𝗮𝗰𝘁 𝗡𝗮𝘁𝗶𝘃𝗲 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝘁𝗵𝗮𝘁 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝘀 𝗳𝗮𝘀𝘁, 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 𝗸𝗲𝘆-𝘃𝗮𝗹𝘂𝗲 𝘀𝘁𝗼𝗿𝗮𝗴𝗲 by wrapping Tencent’s MMKV engine — a native C library originally built for WeChat. 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗵𝗼𝗼𝗱, Tencent’s MMKV stores data in memory-mapped files, giving near-instant read/write access directly from native memory. By leveraging that engine through a native bridge, react-native-mmkv avoids the JSON serialisation and asynchronous bridge calls that make AsyncStorage slower. This version marks the next major evolution of one of React Native’s most efficient storage solutions — 𝗿𝗲𝗯𝘂𝗶𝗹𝘁 𝗲𝗻𝘁𝗶𝗿𝗲𝗹𝘆 𝗼𝗻 𝗡𝗶𝘁𝗿𝗼 𝗠𝗼𝗱𝘂𝗹𝗲𝘀. ➡️ 𝗙𝘂𝗹𝗹 𝗡𝗶𝘁𝗿𝗼 𝗿𝗲𝘄𝗿𝗶𝘁𝗲 — meaning faster calls, cleaner bridging, and full compatibility with the New Architecture. ➡️ Works again on old architecture too (up until React Native 0.82). ➡️ Uses 𝗠𝗠𝗞𝗩𝗖𝗼𝗿𝗲 from CocoaPods/Gradle instead of bundling source — no more duplicate symbols when mixing with native code. ➡️ set(...) now throws a useful error if a value can’t be saved ➡️ remove(...) returns a boolean ➡️ useMMKVKeys() hook added ➡️ AppGroup support is back ➡️ remove() and clearAllKeys() now notify listeners properly Under the hood, this version leans into the Nitro runtime, improving performance and reliability across both Android and iOS. ℹ️ 𝗕𝗲𝗳𝗼𝗿𝗲 𝘂𝗽𝗴𝗿𝗮𝗱𝗶𝗻𝗴 — 𝗿𝗲𝗮𝗱 𝘁𝗵𝗲 𝗩𝟰 𝗺𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗴𝘂𝗶𝗱𝗲. There are subtle but important breaking changes if you rely on older behaviours or manual native integrations. What storage solution are you using in your React Native apps right now — MMKV, AsyncStorage, or something custom? 👇 #ReactNative #MMKV #NitroModules #Performance #MobileDev #OpenSource #ReactNativeRewind #NewArchitecture #AsyncStorage #MarcRoussavy

React Native (New) Architecture offers many performance opportunities. Check our article by @breskin67 for tips on using: ✨ Worklets & Reanimated feature flags ⚡ useLayoutEffect 🔧 Hermes V1 🔥 NitroModules Link in 🧵

Cooking something with Yoga layout and the skia rendering engine. Basic layouting and styling is working. Next up is JSX syntax and more draw cmds. Also many thanks @mrousavy for creating NitroModules. This makes it such a joy to create native modules github.com/samuelscheit/reac…

Voice recording setup of my app in summary: DISASTER >Tried react-native-audio-recorder: 4.4.0, 3.5.3, 3.4.0 - all required NitroModules and didnt get it to work >Installed react-native-nitro-modules separate, got TypeScript errors >updated Pod repo a million times >Tried Expo AV but kept throwing "Cannot read property NativeModule of undefined" >Rebuilt app completely a couple times with iOS clean, same NativeModule error >Tried npx install-expo-modules@latest multiple times >Created react-native.config.js to exclude audio-recorder-player from autolinking, no go >Expo modules installation with CLI integration >Fixed react-native-community/cli-platform-ios missing module >Created PodFile with tons of different configs: hard coded relative paths, no-based resolution, Direct file paths, Expo autolinking attempts with different paths, all no go >Deintegrated Pod and reinstalled over 15 times >Removed DerivedData multiple times >Tried Swift bridging header for ExpoModulesCore >Modified AppDelegate.swift to inherit from ExpoAppDelegate >Set iOS Deployment Target to 15.1 >Tried removing use_frameworks from Podfile Final attempt was npx expo upgrade 53 for which I got "not supported in local CLI So the whole day was NO F*CKING GO lol. Let's see if we can tackle this tomorrow, spend tons of hours on this yesterday and almost 10 hours today. 😵‍💫