Building High-Performance Native Modules for React Native with Nitro

• Legacy Native Modules (traditional bridging approach)
• Turbo Modules (JSI-powered approach for better performance)
• Expo Modules (simplified native module creation within the Expo ecosystem)
• Nitro (a new approach that aims to improve native module development further)

In this article, we will explore Nitro, its benefits, and how it compares to other approaches. We'll also walk through an example of building a native module using Nitro.

With different approaches available, developers must decide which one best fits their project based on performance, ease of implementation, and ecosystem support.

How Nitro Works

• Nitro Module: A library built with Nitro containing one or more Hybrid Objects
• Hybrid Object: A native object implemented in C++, Swift, or Kotlin that can be accessed directly from JavaScript
• Nitrogen: A code generator that creates native bindings from TypeScript interfaces, ensuring perfect type alignment between JavaScript and native code

1. Exceptional Performance

• Lightweight Layer: While built on JSI, Nitro maintains efficiency with compile-time type-checking using C++ templates or constexpr, introducing zero runtime overhead
• Direct Swift/C++ Interop: Unlike other frameworks, Nitro doesn't rely on Objective-C at all, using Swift's C++ interop capabilities for near-zero overhead
• jsi::NativeState: Hybrid Objects are built on jsi::NativeState rather than jsi::HostObject, allowing for proper native prototypes and memory management

2. Strong Type Safety

Nitro Modules are both type-safe and null-safe. The code generator (Nitrogen) uses TypeScript specs as the single source of truth, with native interfaces generated to exactly match the declared types:

3. Object-Oriented Approach

Every Hybrid Object in Nitro is a native object that can be created, passed around, and destroyed. This allows for a true object-oriented programming model:

Functions are also first-class citizens in Nitro, meaning they can be kept in memory, called as needed, and automatically cleaned up when no longer needed.

1. Initialize the Template

Start by creating a new Nitro Module using the CLI:

2. Define Your TypeScript Interface

Create a TypeScript interface that extends HybridObject:

3. Generate Native Interfaces

Run Nitrogen to generate the native interface specifications:

4. Implement Native Classes

Implement the generated specifications in Swift and/or Kotlin:

5. Register Your Hybrid Objects

Configure the nitro.json file to autolink your Hybrid Objects:

6. Use in JavaScript

Now you can use your Hybrid Object in JavaScript:

Creating a Nitro View

• Declare your view's interface:

• Generate code with npx nitro-codegen
• Implement the native view:

• Configure in nitro.json and run Nitrogen again
• Initialize in JavaScript:

• Use in your components:

Key Features

• Rich Types: Use any Nitro-supported type as props, including other Hybrid Objects
• Callbacks: Functions must be wrapped in an object: onEvent={{ f: (data) => console.log(data) }}
• Methods: Access methods through refs:

Turbo Modules

Advantages of Turbo Modules:

• Shipped with React Native core: Unlike Nitro, Turbo Modules are part of React Native core. Users don't need to install any additional dependencies to build or use them.
• Part of the official React Native architecture

Disadvantages compared to Nitro:

No direct Swift support: Turbo Modules must go through Objective-C to reach Swift, creating an additional bridge layer:

• No properties (must use getter/setter methods)
• Not object-oriented (modules are singletons)
• No tuples or callbacks with return values
• Uses less efficient jsi::HostObject instead of jsi::NativeState
• Codegen runs on app build (not package build)
• Codegen cannot resolve imports

Legacy Native Modules

Disadvantages compared to Nitro:

• Much slower due to serialization/deserialization
• Deprecated in favor of Turbo Modules
• All the same limitations as Turbo Modules

Expo Modules

Advantages of Expo Modules:

• Swift and Kotlin support: Like Nitro, Expo Modules can be written in Swift instead of Objective-C
• Kotlin coroutines for async functions
• Property support

Disadvantages compared to Nitro:

Indirect Swift bridge: While Expo Modules support Swift, they still bridge through Objective-C, creating an additional layer:

• No code generator (less type safety)
• No tuples or callbacks with return values
• Uses less efficient jsi::HostObject

• Nitro is significantly faster than alternatives
• It provides strong type safety and null safety
• It supports a true object-oriented programming model
• It embraces modern languages (Swift, Kotlin) without legacy bridges
• It offers comprehensive type support

Whether you're building a complex image processing library, a high-performance AR experience, or just need to bridge efficiently to native SDKs, Nitro provides the tools to build robust, type-safe, and lightning-fast native modules.