# react-native-brownfield puts a React Native root view inside an existing native app > React Native Brownfield is a Callstack project of helper packages, a Gradle plugin and a CLI that let a Swift, Kotlin, Java or Objective-C app embed React Native screens without a full rewrite. It suits a team doing incremental React Native adoption, and it trades away the single-root-view assumption most React Native tutorials assume. **callstack/react-native-brownfield** — Set of helpers to make your brownfield integration smooth and easy. - Repository: https://github.com/callstack/react-native-brownfield - Website: http://oss.callstack.com/react-native-brownfield/ - Stars: 552 · Forks: 57 - Language: TypeScript - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/callstack-react-native-brownfield ## The problem: a native app that cannot become a React Native app Most React Native guidance assumes the app is a React Native app, with one root view and a JavaScript navigation tree on top of it. That assumption breaks for an existing product. A shipping Swift or Kotlin codebase has its own navigation stack, its own view lifecycles, its own build pipeline and its own release process, and rewriting all of that to adopt React Native is a decision few teams can justify. The description of this repository is short, a set of helpers to make your brownfield integration smooth and easy, and that phrase is doing the real work. The project exists to remove the mechanical parts of embedding React Native into an app that was not written for it, so that a team can adopt React Native incrementally, one screen at a time, without restructuring the host application first. The full documentation is hosted at oss.callstack.com/react-native-brownfield, and the project is MIT licensed with the code written in TypeScript. The last push to the repository was on 2026-10-22, and the release list shows brownfield at 6.0.1 together with @callstack/react-native-brownfield at 6.0.1 on the same day, plus a Brownfield Gradle Plugin at 2.0.0-alpha11. ## One method to start React Native and reuse the instance The feature list names two mechanisms that define how the integration works. The first is starting React Native with one method and invoking code as soon as it is loaded, which removes the split between starting the runtime and then waiting for a promise or a callback before your JavaScript can run. The second is reusing the same instance of React Native between different components, which is the part that matters for a brownfield setup. In a normal React Native app there is one runtime and one root view, so the question never comes up. In a brownfield app, a React Native view might be pushed onto an iOS navigation controller in one flow and embedded in an Android fragment in another, and the alternative to a shared instance is booting a separate runtime per view, with the memory and startup cost that implies. The list also claims compatibility with both the legacy and the new React Native architecture, which is what allows a team running an older app to adopt the helpers without first migrating its rendering layer. ## Native building blocks, gestures and hardware buttons Beyond the runtime mechanics, the README lists a set of native components crafted for React Native that the helpers ship, plus the ability to disable and enable native gestures and hardware buttons from JavaScript. That last item is the kind of detail that only appears in a real brownfield project. A native screen that hosts a React Native view has two gesture systems and two sources of button behaviour, the native one and the JavaScript one, and in practice the native side keeps responding to a swipe or a back gesture that the React Native screen was supposed to own. Being able to turn the native handlers off from JavaScript, and back on again when the React Native screen goes away, is what makes the embedded view feel like a normal screen rather than a fight between two input systems. The feature list also states that the helpers work well with any native navigation pattern, as well as with any React Native JavaScript-based navigation, so the React Native view can be a screen in the native stack, a modal, or a tab inside a JavaScript navigator that the native side presents. ## Languages and UI frameworks on both platforms The compatibility claim is specific, which is what makes it checkable. The helpers are stated to work with Objective-C, Swift, Java and Kotlin, and to support UIKit and SwiftUI on iOS and Fragments and Jetpack Compose on Android. In practice that means a team can drop a React Native view into a UIKit view controller, a SwiftUI hosting controller, an Android Activity that uses Fragments or Compose, and an older Objective-C or Java codebase, without maintaining four separate integration paths by hand. The repository layout supports the impression of a broader surface than a single package. It is a monorepo named @callstack/brownfield-monorepo with Yarn workspaces over packages/*, apps/*, docs and gradle-plugins/*, driven by turbo for task orchestration, and the packages are published to npm under the brownfield and @callstack/react-native-brownfield names. There is a gradle-plugins/ directory with its own publish scripts, which is where the Android half of the build integration lives. ## The CLI that automates the build wiring The last item on the feature list is an out-of-the-box CLI that automates the build process, and it is the piece that decides how much of the setup you do by hand. The repository layout shows where it lives: a packages/ directory for the libraries, apps/ for the example applications, docs/ for the documentation site, and scripts/ for tooling. The monorepo package.json exposes a generate:schema script that runs in the @callstack/brownfield-cli workspace, and the workspace layout means the CLI, the native helpers and the example apps are versioned together in one repository, with changesets driving the release. The build and quality scripts are short and consistent. ```json "lint": "turbo run lint", "typecheck": "turbo run typecheck", "build": "turbo run build", ``` Because the workspace list includes gradle-plugins/*, a turbo build covers the Gradle plugin as well as the TypeScript packages, and lint and typecheck run across the same set, which is what keeps the native and JavaScript halves from drifting apart. The Gradle plugin has its own release path, with separate scripts for publishing it locally, generating its release notes and synchronising its version, and a check mode for that synchronisation that can run in CI. ## A repository that also teaches: docs, examples and skills Callstack runs this as more than a library, and the tree shows it. There is an apps/ directory holding example applications that demonstrate the integration in practice, a docs/ directory for the documentation site, and the README links to a free ebook on incremental React Native adoption in native apps, which is the thinking behind the package. The repository also contains a skills/ directory alongside a skillgym/ directory and a skillgym.config.ts, with a script that runs a named suite through the skillgym tool, which suggests the project is now used as a test case for AI agent tooling as well as for developers. There is an AGENTS.md file, a lefthook.yml for git hooks, an eslint setup split across three config files for base, React Native and TypeScript rules, and a CI workflow directory. The build badge points at CircleCI, and the version badge points at the npm package page for @callstack/react-native-brownfield. ## Where react-native-brownfield is the wrong tool The boundaries are worth being blunt about. The first is greenfield. If you are starting an app today, a plain React Native project with one root view is less code, fewer native packages and no bridging layer, and this whole repository exists to solve a problem you do not have. The second is that the value depends on the host app's native build system being under your control, since the CLI automates build steps and the Gradle plugin injects tasks into the Android build, and if your native build is bespoke or locked down by a platform team, the integration work moves from code into negotiation. The third is version coupling: brownfield at 6.0.1 and the Gradle plugin at 2.0.0-alpha11 were published on 2026-10-20, and a plugin still carrying an alpha tag suggests the Android build integration is the less settled half of the project. The fourth is that the documentation is where the detail lives, at oss.callstack.com, and the README itself is a feature list, so the claims about working with any native navigation pattern and with both React Native architectures are things you will confirm by reading the docs and by trying one screen, not by reading this repository. The fifth is a different alternative worth weighing, which is a web view or a cross-platform framework for the new feature instead of React Native, since for a single new screen the native approach may cost more than it saves. ## Conclusion Adopt react-native-brownfield if your team already has a shipping native app and wants React Native added feature by feature, because the whole point of the helpers is that a native screen can host a React Native view and the same React Native instance is reused across components. Do not adopt it for a greenfield app, where a plain React Native project is simpler and has fewer moving parts, and do not adopt it if you cannot accept owning the native build steps, since the Gradle plugin and the CLI sit between you and the platform toolchain. Verify two things first: that your app's navigation pattern is one the helpers can mount into, since the README claims compatibility with any native navigation pattern and with React Native JavaScript-based navigation but that claim rests on the documentation rather than on a test matrix, and that your React Native version is covered by the legacy or new architecture support the project advertises. The practical first step is to add @callstack/react-native-brownfield to the native project, run its CLI to generate the build wiring, and mount one React Native view inside one native screen before committing to a broader rollout. ## FAQ ### What is react-native-brownfield? It is a Callstack project of helper packages, a Gradle plugin and a CLI that make it possible to embed React Native views in an existing native application. The packages are published to npm as brownfield and @callstack/react-native-brownfield, and the licence is MIT. ### Which native languages and UI frameworks does react-native-brownfield support? The README states compatibility with Objective-C, Swift, Java and Kotlin, with support for UIKit and SwiftUI on iOS and Fragments and Jetpack Compose on Android. The helpers are written in TypeScript and the repository is a monorepo with packages, apps, docs and Gradle plugin workspaces. ### Can I reuse one React Native instance across several native screens? Yes. One of the listed features is reusing the same instance of React Native between different components, and another is starting React Native with one method and invoking code as soon as it is loaded. The helpers are also stated to be compatible with both the legacy and the new React Native architecture. ### How do I install react-native-brownfield in an existing app? The project ships an out-of-the-box CLI that automates the build process, and the documentation for the full setup is at oss.callstack.com/react-native-brownfield. The monorepo also carries example applications in the apps/ directory that show the integration in place, which is the fastest reference for the wiring. ### Is react-native-brownfield still being maintained? The repository is not archived and the last push was on 2026-10-22, with brownfield 6.0.1 and @callstack/react-native-brownfield 6.0.1 published the same day, and Brownfield Gradle Plugin 2.0.0-alpha11 also published on 2026-10-20. Releases are driven by changesets. ## Sources - [callstack/react-native-brownfield on GitHub](https://github.com/callstack/react-native-brownfield) - [License: MIT](https://github.com/callstack/react-native-brownfield/blob/main/LICENSE) - [Project website](http://oss.callstack.com/react-native-brownfield/) - [README](https://github.com/callstack/react-native-brownfield/blob/main/README.md) - [Releases](https://github.com/callstack/react-native-brownfield/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/callstack-react-native-brownfield