# How Native Code Is Organized in React Native for Android and iOS

> Explore how React Native organizes native code into ReactAndroid ReactApple and ReactCommon directories for efficient cross-platform development.

- Repository: [Meta/react-native](https://github.com/facebook/react-native)
- Tags: internals
- Published: 2026-02-25

---

**React Native organizes native code into three top-level directories—`ReactAndroid` for Java/JNI, `ReactApple` for Objective-C/Swift, and `ReactCommon` for shared C++—enabling a single JavaScript bundle to run across platforms.**

The `facebook/react-native` repository uses a clean separation of concerns to support both Android and iOS while maximizing code reuse. Native code is organized in `packages/react-native/` under three primary pillars that handle platform-specific implementations and a shared C++ core.

## The Three-Pillar Directory Structure

React Native’s native implementation lives in three top-level groups that map directly to the supported platforms and the shared C++ core.

### ReactAndroid – The Android Native Stack

Located at `packages/react-native/ReactAndroid`, this directory contains Android-specific Java code, JNI C/C++ bindings, and the bridge that connects Java to the shared core. It includes `ReactInstanceManager`, `ReactPackage` definitions, and Java bridge modules.

### ReactApple – The iOS and macOS Native Stack

Found at `packages/react-native/ReactApple`, this directory houses iOS-specific view managers, bridge modules, Swift UI wrappers, and Xcode podspecs. It contains Objective-C implementations that interface with the shared C++ runtime.

### ReactCommon – The Shared C++ Core

Situated at `packages/react-native/ReactCommon`, this directory contains the platform-agnostic runtime including `CatalystInstance`, TurboModules, the Yoga layout engine, and JSI/JNI bindings. This code is compiled into native libraries used by both Android and iOS.

## Deep Dive into Android Native Organization

### Entry Point: ReactInstanceManager

The `ReactInstanceManager` class serves as the primary entry point for Android native code. Located at [`packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java`](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java), this manager creates the **CatalystInstance**, loads native modules, and wires the Java `ReactPackage`s supplied by the application.

### Package Interface: ReactPackage

The `ReactPackage` interface defines the contract for supplying native modules and view managers. Found in the same directory as `ReactInstanceManager`, a package returns a list of native modules (`List<NativeModule>`) and view managers (`List<ViewManager>`) that become available to JavaScript.

### Bridge Modules: ReactContextBaseJavaModule

Native modules extend `ReactContextBaseJavaModule` and implement methods annotated with `@ReactMethod`. For example, [`DeviceInfoModule.java`](https://github.com/facebook/react-native/blob/main/DeviceInfoModule.java) in `packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/device/` demonstrates how modules expose native functionality to JavaScript through the bridge.

### JNI Glue: C/C++ Bindings

The JNI layer resides in `packages/react-native/ReactAndroid/src/main/jni/`. Key files like [`react/turbomodule/ReactCommon/TurboModuleManager.cpp`](https://github.com/facebook/react-native/blob/main/react/turbomodule/ReactCommon/TurboModuleManager.cpp) implement the C++ side of the bridge, forwarding calls between Java and the C++ `CatalystInstance` in `ReactCommon`.

## Deep Dive into iOS Native Organization

### Entry Point: RCTBridge

On iOS, the `RCTBridge` class serves as the entry point, defined in the React podspec at `packages/react-native/React/React.podspec`. The bridge initializes the JavaScript runtime and connects Objective-C modules to the shared C++ core.

### View Managers and Native Extensions

View managers extend `UIView` with React-specific behavior. The file `packages/react-native/React/Views/UIView+React.m` adds properties and methods that allow the React Native layout system to control standard UIKit views.

### Swift UI Wrappers

React Native supports SwiftUI through Objective-C wrappers. The file `packages/react-native/ReactApple/RCTSwiftUIWrapper/RCTSwiftUIContainerViewWrapper.m` demonstrates how SwiftUI components are bridged to React Native, enabling modern SwiftUI views to render within the React Native hierarchy.

### Build Configuration: Podspecs

The Apple side uses CocoaPods for distribution. The [`packages/react-native/ReactApple/README.md`](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactApple/README.md) provides an overview of how the native code is packaged for Xcode, defining the static libraries that link against the shared C++ core.

## The Shared C++ Architecture

Both Android and iOS link against the same C++ core located in `packages/react-native/ReactCommon`. This shared layer contains the runtime, layout engine, and module system.

### TurboModules

TurboModules provide high-performance native modules using code generation. The implementation in [`packages/react-native/ReactCommon/react/turbomodule/ReactCommon/TurboModuleManager.cpp`](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/turbomodule/ReactCommon/TurboModuleManager.cpp) handles module registration and method dispatch for both platforms.

### Yoga Layout Engine

The Yoga layout engine performs cross-platform layout calculations. Located at [`packages/react-native/ReactCommon/yoga/yoga/YGNode.cpp`](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/yoga/yoga/YGNode.cpp), Yoga implements the Flexbox algorithm in C++, ensuring consistent layout behavior across Android and iOS.

### JSI and JNI Bindings

The JavaScript Interface (JSI) provides direct communication between JavaScript and C++ without serialization overhead. Files in `ReactCommon/jsiexecutor/` such as [`JSIExecutor.cpp`](https://github.com/facebook/react-native/blob/main/JSIExecutor.cpp) manage script execution and native call marshaling.

### Native Module Registry

The [`NativeModuleRegistry.cpp`](https://github.com/facebook/react-native/blob/main/NativeModuleRegistry.cpp) in `packages/react-native/ReactCommon/cxxreact/` maintains the set of loaded native modules at runtime, providing lookup capabilities for both the Android and iOS bridges.

## Practical Code Examples

### Adding an Android Native Module

Create a module by extending `ReactContextBaseJavaModule`:

```java
// MyExampleModule.java
package com.myapp;
import com.facebook.react.bridge.ReactApplicationContext;
import com.facebook.react.bridge.ReactContextBaseJavaModule;
import com.facebook.react.bridge.ReactMethod;
import com.facebook.react.bridge.Callback;

public class MyExampleModule extends ReactContextBaseJavaModule {
  public MyExampleModule(ReactApplicationContext ctx) { super(ctx); }

  @Override public String getName() { return "MyExample"; }

  @ReactMethod
  public void multiply(int a, int b, Callback cb) {
    cb.invoke(null, a * b);
  }
}

```

Implement the `ReactPackage` interface to register the module:

```java
// MyAppPackage.java
package com.myapp;
import com.facebook.react.ReactPackage;
import com.facebook.react.bridge.NativeModule;
import com.facebook.react.uimanager.ViewManager;
import java.util.Collections;
import java.util.List;

public class MyAppPackage implements ReactPackage {
  @Override public List<NativeModule> createNativeModules(
      ReactApplicationContext ctx) {
    return Collections.singletonList(new MyExampleModule(ctx));
  }

  @Override public List<ViewManager> createViewManagers(
      ReactApplicationContext ctx) {
    return Collections.emptyList();
  }
}

```

Register the package in your `ReactNativeHost` where `ReactInstanceManager` consumes the list.

### Adding an iOS Native Module (Objective-C)

Create a module conforming to `RCTBridgeModule`:

```objc
// MyExampleModule.h
#import <React/RCTBridgeModule.h>

@interface MyExampleModule : NSObject <RCTBridgeModule>
@end

```

```objc
// MyExampleModule.m
#import "MyExampleModule.h"

@implementation MyExampleModule
RCT_EXPORT_MODULE();

RCT_EXPORT_METHOD(multiply:(NSInteger)a
                  b:(NSInteger)b
                  resolver:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
{
  resolve(@(a * b));
}
@end

```

The `RCTBridge` automatically scans for `RCT_EXPORT_MODULE` during initialization.

### Adding an iOS Native View (Swift)

Expose SwiftUI components through Objective-C wrappers:

```swift
// MySwiftView.swift
import SwiftUI
import React

@objc(MySwiftView)
class MySwiftView: RCTViewManager {
  override static func moduleName() -> String! { "MySwiftView" }

  override func view() -> UIView! {
    let hosting = UIHostingController(rootView: Text("Hello from SwiftUI"))
    return hosting.view
  }
}

```

Link the Swift view through the `RCTSwiftUIWrapper` system in `packages/react-native/ReactApple/RCTSwiftUIWrapper/RCTSwiftUIContainerViewWrapper.m`.

## Summary

- **React Native organizes native code in three main directories**: `ReactAndroid` for Java/JNI, `ReactApple` for Objective-C/Swift, and `ReactCommon` for shared C++.
- **Android uses `ReactInstanceManager`** as the entry point, implementing `ReactPackage` to register modules that extend `ReactContextBaseJavaModule`, with JNI glue in `packages/react-native/ReactAndroid/src/main/jni/`.
- **iOS uses `RCTBridge`** to initialize the runtime, with modules implementing `RCTBridgeModule` and SwiftUI components exposed through `RCTSwiftUIContainerViewWrapper.m` in `ReactApple`.
- **Both platforms share `ReactCommon`**, containing [`TurboModuleManager.cpp`](https://github.com/facebook/react-native/blob/main/TurboModuleManager.cpp) for high-performance modules, [`YGNode.cpp`](https://github.com/facebook/react-native/blob/main/YGNode.cpp) for the Yoga layout engine, and [`JSIExecutor.cpp`](https://github.com/facebook/react-native/blob/main/JSIExecutor.cpp) for JavaScript-to-native binding.

## Frequently Asked Questions

### Where is the Android native code located in the React Native repository?

Android native code resides in `packages/react-native/ReactAndroid`. This directory contains Java implementations of the bridge in `src/main/java/com/facebook/react/`, including [`ReactInstanceManager.java`](https://github.com/facebook/react-native/blob/main/ReactInstanceManager.java) and [`ReactPackage.java`](https://github.com/facebook/react-native/blob/main/ReactPackage.java), alongside JNI C/C++ bindings in `src/main/jni/` that connect Java to the shared C++ core.

### How does React Native share code between Android and iOS?

React Native shares platform-agnostic code through `packages/react-native/ReactCommon`, a C++ layer compiled into native libraries for both platforms. This shared core includes the CatalystInstance runtime, TurboModules for high-performance native modules, the Yoga layout engine ([`YGNode.cpp`](https://github.com/facebook/react-native/blob/main/YGNode.cpp)), and JSI bindings ([`JSIExecutor.cpp`](https://github.com/facebook/react-native/blob/main/JSIExecutor.cpp)), ensuring consistent behavior across Android and iOS.

### What is the entry point for iOS native modules in React Native?

The entry point for iOS is `RCTBridge`, defined in the React podspec at `packages/react-native/React/React.podspec`. The bridge initializes the JavaScript runtime and automatically discovers native modules that implement the `RCTBridgeModule` protocol and use the `RCT_EXPORT_MODULE()` macro, connecting them to the shared C++ core through Objective-C++ bindings.

### How are SwiftUI components integrated into React Native?

SwiftUI components are integrated through the `ReactApple` directory, specifically via Objective-C wrappers in `packages/react-native/ReactApple/RCTSwiftUIWrapper/RCTSwiftUIContainerViewWrapper.m`. Developers create a class extending `RCTViewManager` that returns a `UIHostingController` view, bridging SwiftUI's declarative interface to React Native's component hierarchy while maintaining compatibility with the Objective-C runtime.