Powering Native Apps with React Native Brownfield

There are many ways to develop React Native apps. One popular method is starting from scratch, creating an empty repository and building upon it. While ideal for new projects, this doesn't suit everyone, particularly teams with existing codebases and established workflows.

What is brownfield development?

In software engineering, brownfield development refers to the practice of building new systems or features within an existing software infrastructure. For React Native, "brownfield" describes integrating React Native components into established native Android and iOS applications.

Brownfield React Native development is inherently complex because:

• Every decision impacts existing systems.
• Communication between technologies cause runtime and development overhead.
• Build systems need to handle two or more types of technologies.

To address the pain points and make React Native brownfield development more accessible, we've created a library called React Native Brownfield.

React Native Brownfield

Initially, React Native Brownfield only handled the navigation between native and React Native screens. However, with the ^1.0.0 release, this has changed and we've added many new interesting features.

Loading React Native components as native views

One of the biggest features of brownfield React Native applications is the ability to present React Native components in native screens. We've introduced a new view loader API to React Native Brownfield that can load React Native components as:

• SwiftUI views
• UIKit view controllers
• UIKit views
• Jetpack Compose views
• Android fragments
• Android views

The loaded components can operate either as standalone screens or as embedded widgets. The lifecycle management of these components is seamlessly handled by React Native Brownfield.

SwiftUI example

UIKit example

or as a view:

Jetpack Compose example

Android Views example

or as a view:

Packaging: xcframework and aar support

Integrating React Native into native apps requires bundling JavaScript and native dependencies. Two primary strategies exist:

Single repository integration

In this approach, Android, iOS, and React Native code is hosted in a single repository. The folder structure often looks like this:

This approach works well enough as a simpler integration. All the capabilities of React Native can be utilized. However, there are a few downsides, such as:

• Android, iOS, and the React Native app teams have to work in a single repo.
• The iOS app needs a Cocoapods integration.
• The Android app needs to install React Native specific dependencies using Gradle.

Despite all the downsides, this integration is perfect for teams that need a simpler setup.

Separate repositories with native packages

A more sophisticated strategy involves separate repositories for each platform, where React Native is packaged into native-friendly formats like ^.xcframework and ^.aar files. This setup promotes encapsulation, simplifies developer environments, and keeps React Native specific tools isolated from native developers.

The resulting repos look like this:

In addition to ^{.xcframeworks}, we also plan to support first-party integration with the Swift Package Manager.

This approach works perfectly for teams with more sophisticated setups. It promotes better encapsulation, and native app developers don't need to install JavaScript-specific tooling. However, implementing it requires a deep technical understanding of how React Native is architected.

With this release, we've introduced full support for the packaging approach. More content about the packaging approach will be released later.

Common entry patterns to initialize React Native

For brownfield apps, native code initiates the React Native runtime.

In brownfield React Native apps, the native code serves as the entry point and it's responsible for spawning the React Native screens. We've created flexible APIs for initialization:

iOS

AppDelegate

SwiftUI

Android

Using a React Native Host Delegate

Passing Options Directly

Recommended use cases for React Native Brownfield

Based on our experience, we recommend using React Native Brownfield in the following scenarios as it's a perfect fit:

• Gradually transitioning to React Native: Converting your entire app to React Native in one go may be impractical. A gradual transition, feature by feature, can reduce risk and cost.
• Enabling web developers to build native apps: Web teams already familiar with React can seamlessly transition to developing mobile app features.
• Replacing webviews: Native apps often use webviews for certain user interactions such as handling payments, managing user accounts, and support. However, many teams are not happy with the user experience of webviews. React Native screens are perfect replacements in such cases.
• Sharing UI components across platforms: Common UI elements can easily be reused across Android, iOS, and web, streamlining maintenance and ensuring consistency.

Conclusion

Brownfield development with React Native lets you add React screens to existing native apps without starting from scratch. Teams can gradually extend their apps, involve new developers, and avoid the high risks of full rewrites. We built React Native Brownfield by capturing the lessons and best practices from real brownfield projects, making it a practical, battle-tested solution that simplifies integration, packaging, and flexibility in real-world apps.

‍