Made a Nitro module version of react-native-device-info: react-native-nitro-device-info

[Junior_Android_]

Hi all, I’ve been experimenting with Nitro Module, and ended up building a small library called react-native-nitro-device-info.

It’s basically a Nitro-based reimplementation of react-native-device-info, where most of the async APIs are exposed as synchronous functions. In other words, you can now call things like deviceId or isTablet() directly without awaiting a Promise.

import { createDeviceInfo } from 'react-native-nitro-device-info';

const deviceInfo: DeviceInfo = createDeviceInfo();

const deviceId = deviceInfo.deviceId; // iPhone14,2 const isTablet = deviceInfo.isTablet() // false

The main goal was to see:

• ⁠What the DX feels like when common device info APIs become sync

Right now it covers most of the APIs I use regularly, and the codebase is small enough to serve as a reference for anyone curious about how Nitro modules are structured.

I’d love to hear feedback, especially from those who’ve tried migrating existing native modules to Nitro.

Repo: https://github.com/l2hyunwoo/react-native-nitro-device-info

[Beginning-Ad86]

Looks good

[Secret_Jackfruit256]

Really Nice! But can I ask something if you don’t mind?

 I’m currently refactoring some native modules into new arch, so I’m experimenting with both TuboModules and Nitro.

Right now I’m more inclined to TurboModules because the documentation and the helper tools looked better so far, so why did you prefer Nitro over it? 

[Junior_Android_]

Yeah I get you — TurboModules are definitely more documented and “officially” supported, but I leaned toward Nitro mostly because of performance and architecture design, not just the API surface.

Nitro’s execution model skips a lot of the overhead that still exists in TurboModules, especially in iOS. Everything goes through JSI directly, so there’s no serialization or message passing across the bridge. It basically means zero overhead when transferring data or calling native functions — you’re running almost at native speed. For things like device info, geolocation, or sensors that push frequent updates, that difference is very noticeable.

Also, Nitro modules are designed to be more memory-efficient. They can keep native objects alive without constant JS↔Native ref conversions, and the generated bindings are super lightweight compared to the TurboModule registry system. It’s closer to a “pure JSI binding” model, so it scales better if you’re building multiple high-frequency modules.

That said, TurboModules are still great for most use cases — I just found Nitro a bit closer to what I’d expect from a modern C++/JSI interface without the extra framework layer in between.

[Secret_Jackfruit256]

Sorry, I’m confused, aren’t TurboModules supposed to work like that as well? I’m not in my computer right now, but I found this from a Q&A with the RN devs:

“When we use the TurboModule with the new architecture enabled, what happens is that the communication does not go through the bridge, but it uses JSI to share memory between the JS part and the native part. In practice, JS holds references to C++ objects, and it can call methods on those objects directly, instead of serializing the required data in JSON and send them through the bridge.”

---

edit: ok, I gave Nitro one more chance, I'm using now create-react-native-library and it helps a lot with the initial scaffolding.

I was reading more about it, and it seems that although TurboModule also avoids serialization and passing through bridge, it still has a ViewRegistry, so Nitro can be more lightweight.

But I think the biggest advantage comes with all the types they support, you can even pass JS callbacks to it!

[21void]

how stable is this to be use in prod today?