React Native Brownfield Migration
CallstackOfficialPublished by Callstack
- Skill
- Tool integration
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The react-native-brownfield-migration skill provides a structured, step-by-step approach for adopting React Native within an existing native codebase. It supports both Expo and bare React Native workflows, guiding developers through initial setup, artifact packaging (XCFrameworks or AARs), and host integration. The skill emphasizes a phased rollout, ensuring that React Native surfaces are integrated into native hosts reliably while maintaining isolation through a facade-based approach.
What it does
- Guides the selection between Expo and bare React Native migration paths.
- Automates the setup of the brownfield integration environment.
- Facilitates the packaging of React Native source code into native-compatible artifacts like XCFrameworks or AARs.
- Provides instructions for integrating React Native surfaces into existing iOS and Android host applications.
- Includes validation steps for runtime initialization and UI rendering.
- Offers troubleshooting guidance for common integration and build issues.
When to use it
- When you have an existing native mobile app and want to introduce React Native incrementally.
- When you need to package a React Native app as a library for a native host.
- When you are setting up the initial brownfield configuration for an Expo or bare project.
- When you need to integrate specific React Native screens or features into a native iOS or Android host.
Advantages
- Enables incremental adoption of React Native without requiring a full rewrite.
- Supports both Expo and bare React Native workflows.
- Provides a clear, standardized path for artifact generation and host integration.
- Promotes a clean architecture by encouraging a facade-based approach between host and RN code.
- Includes built-in validation and troubleshooting steps to ensure stable deployments.
Usage examples
- “How do I start migrating my existing native Android app to React Native using brownfield?”
- The agent will guide you through the path selection process, help you verify your Android library module, and provide the commands to package your React Native code into an AAR.
- “I need to generate an XCFramework from my React Native app for my iOS host.”
- The agent will walk you through the bare iOS XCFramework generation steps, ensuring your project is correctly configured for the brownfield CLI.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/callstackincubator/react-native-brownfield-migration/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip react-native-brownfield-migration.zip -d .agents/skills
Documentation by Callstack
Migrating to React Native
Use this skill only after the decision to adopt brownfield migration has been made. When the user is still choosing between brownfield, greenfield, a checkpoint-based path, defer, or no migration, use assess-react-native-migration first.
Overview
Prescriptive workflow for incremental adoption of React Native in existing native apps using @callstack/react-native-brownfield, from initial setup through phased host integration.
Expo track
Bare React Native track
Use one track per task unless the user explicitly asks for migration or comparison.
Migration Strategy
Use this strategy for brownfield migration planning and execution:
Assess app state and select Expo or bare path.
Perform initial setup with
@callstack/react-native-brownfield.Package RN artifacts (
XCFramework/AAR) from the RN source app.Integrate one RN surface into the host app and validate startup/runtime.
Repeat integration by feature/screen for incremental rollout.
Agent Guardrails (Global)
Apply these rules across all reference files:
Select one path first (Expo or bare) and do not mix steps.
Use placeholders from the docs (
<framework_target_name>,<android_module_name>,<registered_module_name>) and resolve from project files.Validate each packaging command before moving to host integration.
Run
npx brownfield <command> --helpbefore relying on any flag table in these references; help output wins.Write stable project settings once into
brownfield.config.*instead of repeating flags — see cli-and-config.md.Prefer official docs for long platform snippets and CLI option details.
Keep host apps isolated from direct React Native APIs when possible (facade approach).
For startup/runtime verification, use
agent-deviceto open the host app, navigate to the RN surface, capture snapshots/screenshots, and collect device evidence. If it is missing and verification needs it, install it through the environment's approved/trusted path or ask the user to install or enable it.
Canonical Docs
Path Selection Gate (Must Run First)
Before selecting any reference file, classify the project:
If no React Native app exists yet, use Expo creation path:
If React Native app exists, inspect
package.jsonandapp.json:Expo if
expois present or Expo plugin workflow is requested.Bare RN if native folders and direct RN CLI workflow are used without Expo path requirements.
If still unclear, ask one disambiguation question.
Continue with exactly one path.
When to Apply
Reference this package when:
Implementing an accepted incremental migration from native-only apps to React Native or Expo
Creating brownfield integration flows for Expo or bare React Native projects
Performing initial setup with
@callstack/react-native-brownfieldGenerating iOS XCFramework artifacts from a React Native app
Generating and publishing Android AAR artifacts from a React Native app
Integrating generated artifacts into host iOS/Android apps
Quick Reference
| File | Description |
|---|---|
| quick-start.md | Shared preflight and mandatory path-selection gate |
| cli-and-config.md | CLI commands, full flag sets, config file, artifact layout, codegen side effects |
| runtime-api.md | Host <-> RN API surface (JS, Swift, Kotlin) and reference apps |
| expo-create-app.md | Scaffold a new Expo app before Expo brownfield setup |
| expo-quick-start.md | Expo plugin setup and packaging readiness |
| expo-ios-integration.md | Expo iOS packaging and host startup integration |
| expo-android-integration.md | Expo Android packaging, publish, and host integration |
| bare-quick-start.md | Bare React Native baseline setup |
| bare-ios-xcframework-generation.md | Bare iOS XCFramework generation |
| bare-android-aar-generation.md | Bare Android AAR generation and publish |
| bare-ios-native-integration.md | Bare iOS host integration |
| bare-android-native-integration.md | Bare Android host integration |
Problem -> Skill Mapping
| Problem | Start With |
|---|---|
| Need migration path decision first | assess-react-native-migration |
| Need Expo vs bare path decision | quick-start.md |
| Need a CLI flag, the config file shape, or the artifact paths | cli-and-config.md |
| Need a host <-> RN API name, signature, or a working example app | runtime-api.md |
| Need shared state between host and RN, or typed RN -> native navigation | brownie / brownfield-navigation skills |
| Need to create a new Expo app for brownfield | expo-create-app.md |
| Need Expo brownfield setup and plugin wiring | expo-quick-start.md |
| Need Expo iOS brownfield integration | expo-ios-integration.md |
| Need Expo Android brownfield integration | expo-android-integration.md |
| Need bare RN baseline setup | bare-quick-start.md |
| Need bare RN iOS XCFramework generation | bare-ios-xcframework-generation.md |
| Need bare RN Android AAR generation/publish | bare-android-aar-generation.md |
| Need bare RN iOS host integration | bare-ios-native-integration.md |
| Need bare RN Android host integration | bare-android-native-integration.md |
Related Skills
Assess React Native migration before selecting the migration path.
brownie(shared host <-> RN state) andbrownfield-navigation(typed RN -> native navigation) ship from another repo: invoke them by name, and fall back to the canonical docs if they are not installed.
Files
- ATTRIBUTION.mdAdded by AutoGineer885 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md8.0 KiB
- agents/openai.yaml472 B
- references/bare-android-aar-generation.md4.2 KiB
- references/bare-android-native-integration.md3.2 KiB
- references/bare-ios-native-integration.md3.6 KiB
- references/bare-ios-xcframework-generation.md3.4 KiB
- references/bare-quick-start.md2.0 KiB
- references/cli-and-config.md9.4 KiB
- references/expo-android-integration.md3.6 KiB
- references/expo-create-app.md1.6 KiB
- references/expo-ios-integration.md11.3 KiB
- references/expo-quick-start.md3.8 KiB
- references/quick-start.md2.2 KiB
- references/runtime-api.md10.1 KiB
references/runtime-api.md
title: Brownfield Runtime API impact: HIGH tags: react-native, brownfield, api, swift, kotlin, javascript, host-boundary
Skill: Brownfield Runtime API
The host <-> React Native boundary surface: what JavaScript can call, what the native host sets up, and which mechanism to pick for a given task. Read this before hand-rolling a bridge.
Choosing a boundary mechanism
| Need | Use |
|---|---|
| Leave the RN surface and return to the native stack | popToNative() |
| Hand the back gesture / hardware back button to native | setNativeBackGestureAndButtonEnabled() |
| Call a typed, named native screen or action from RN (navigate to a native screen, ask the host for a confirmation) | Brownfield Navigation — brownfield-navigation skill (if installed) |
| Share state between host and RN (session, user, theme) with a single source of truth | Brownie — brownie skill (if installed) |
| One-off, untyped signal in either direction | postMessage() / onMessage() |
Prefer the typed options. postMessage is the escape hatch: it is a JSON string with no contract,
so it does not survive refactoring the way a generated navigation or store binding does.
JavaScript
@callstack/react-native-brownfield default-exports exactly four methods.
import ReactNativeBrownfield from '@callstack/react-native-brownfield';
import type { MessageEvent } from '@callstack/react-native-brownfield';
ReactNativeBrownfield.popToNative(true); // `animated` is iOS-only
ReactNativeBrownfield.setNativeBackGestureAndButtonEnabled(true);
ReactNativeBrownfield.postMessage({ text: 'hello', id: 2 }); // must be JSON-serializable
const subscription = ReactNativeBrownfield.onMessage((event: MessageEvent) => {
console.log(event.data);
});
subscription.remove();Notes:
popToNative(animated)ignoresanimatedon Android.postMessagecallsJSON.stringifywithout catching — serialization errors are the caller's.onMessageparses the incoming payload as JSON and falls back to the raw string on failure.BrownfieldConfigis re-exported as a type, for annotatingbrownfield.config.js.
Swift
Module name is ReactBrownfield. Entry point is ReactNativeBrownfield.shared.
Properties set before startReactNative:
| Property | Notes |
|---|---|
bundle: Bundle | Where the JS bundle is looked up. Defaults to .main, which is wrong for a brownfield host — see below |
preferEmbeddedBundleInDebug: Bool | Default false. Set true to run a Debug framework without Metro |
entryFile: String | Defaults to index, or the Expo virtual metro entry in an Expo project |
bundlePath: String | Defaults to main.jsbundle |
bundleURLOverride: (() -> URL?)? | Full control over bundle resolution |
Lifecycle and rendering:
// three overloads
ReactNativeBrownfield.shared.startReactNative()
ReactNativeBrownfield.shared.startReactNative(onBundleLoaded: { })
ReactNativeBrownfield.shared.startReactNative(
launchOptions: launchOptions,
preloadBundle: true, // loads and evaluates the bundle now; first RN screen appears faster
onBundleLoaded: { }
)
ReactNativeBrownfield.shared.stopReactNative()
// rendering
ReactNativeView(moduleName: "<registered_module_name>") // SwiftUI, iOS 15+
ReactNativeViewController(moduleName: "<registered_module_name>",
initialProperties: nil) // UIKit
ReactNativeBrownfield.shared.view(moduleName: "<registered_module_name>",
initialProps: nil) // raw UIView
// messaging
ReactNativeBrownfield.shared.postMessage("<json string>")
let token = ReactNativeBrownfield.shared.onMessage { message in }There is no startReactNative(onBundleLoaded:launchOptions:) overload. Pass launchOptions
through the three-argument form, or forward the app delegate callbacks below.
App delegate forwarding — forward every callback the host actually implements:
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool
func application(_ application: UIApplication,
willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool
func application(_ application: UIApplication, continue userActivity: NSUserActivity,
restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> BoolDeep links into the RN surface need the open url and continue userActivity forwards, not just
didFinishLaunchingWithOptions.
Two symbols that are not library exports
ReactNativeBundle and ensureExpoModulesProvider() are generated into the packaged framework
(FrameworkInterface.swift) — by the Expo config plugin for Expo projects, or written by hand for a
bare framework target. They come from import <framework_target_name>, not from ReactBrownfield.
Omitting shared.bundle = ReactNativeBundle leaves the host without a bundle URL and the RN surface
renders blank with no crash.
Kotlin
Package com.callstack.reactnativebrownfield. Hosts should call a project-owned
ReactNativeHostManager facade rather than these APIs directly.
// recommended: the factory lambda runs after native libs are loaded
ReactNativeBrownfield.initialize(application, onJSBundleLoaded) { reactHost }
// also supported
ReactNativeBrownfield.initialize(application, packages: List<ReactPackage>, onJSBundleLoaded)
ReactNativeBrownfield.initialize(application, options: HashMap<String, Any>, onJSBundleLoaded)
// option keys: packages, mainModuleName, bundleAssetPath, bundleFilePath, useDeveloperSupport
// DEPRECATED: the reactHost argument is evaluated before native libs load, which breaks
// ExpoReactHostFactory. Use the factory-lambda overload instead.
ReactNativeBrownfield.initialize(application, reactHost, onJSBundleLoaded)Rendering and messaging:
ReactNativeFragment.createReactNativeFragment("<registered_module_name>", initialProps)
ReactNativeBrownfield.shared.createView(
activity, // FragmentActivity?
"<registered_module_name>",
reactDelegate = null,
launchOptions = null,
) // -> FrameLayout
// five-argument overload adds `lifecycleOwner` for a container shorter-lived than the activity
ReactNativeBrownfield.shared.postMessage("<json string>")
ReactNativeBrownfield.shared.addMessageListener(listener)
ReactNativeBrownfield.shared.removeMessageListener(listener)In Compose, mount the fragment with AndroidFragment<ReactNativeFragment> and pass arguments using
the ReactNativeFragmentArgNames constants (ARG_MODULE_NAME, ARG_LAUNCH_OPTIONS) rather than
raw strings.
OnJSBundleLoaded and OnMessageListener are fun interfaces, so a lambda works for both.
Reference apps
The react-native-brownfield repo carries working producers and hosts. Read the one matching your
path before writing integration code — they are more current than any snippet.
| App | Role |
|---|---|
apps/RNApp | Bare RN producer: framework target, Podfile nesting, Gradle library module, ReactNativeHostManager; JS config with a BrownfieldConfig type annotation |
apps/ExpoApp57 | Expo producer driven entirely by brownfield.config.json; package scripts are bare commands |
apps/ExpoApp58 | Expo producer with config under the package.json brownfield key; packaging flags stay on the scripts |
apps/AppleApp | iOS host: linked XCFrameworks, SwiftUI @main startup, app delegate forwarding, navigation delegate |
apps/AndroidApp | Android host: mavenLocal(), per-producer flavors, Compose AndroidFragment<ReactNativeFragment> |
Canonical Docs
Common Pitfalls
Expecting
ReactNativeBundleorensureExpoModulesProvider()fromimport ReactBrownfieldCalling a
startReactNativeoverload that does not exist (onBundleLoaded:launchOptions:)Using the deprecated
initialize(application, reactHost, ...)in an Expo hostForwarding only
didFinishLaunchingWithOptionsand then wondering why deep links do not reach RNReaching for
postMessagewhere a typed navigation call or a Brownie store belongsBuilding a second navigation stack in RN instead of calling
popToNativeback into the host'spreferEmbeddedBundleInDebugdoes not protect against a reachable-but-wrong Metro server. It only applies when no Metro URL resolves at all. Any Metro holding the configured port (default8081) — even one started for an unrelated project — is fetched by a Debug-configured framework, which then crashes with anAppRegistry"has not been registered" error. Checklsof -i :8081before suspecting the integration; to force the embedded bundle, package the framework asRelease. The#if DEBUGhere comes fromios.configurationin the brownfield config, not the host app's Xcode configuration.A brownfield view controller pushed by mutating
UINavigationController.viewControllerscan silently fail to attach to the window when that navigation controller is hosted inside a SwiftUIUIViewControllerRepresentable: the RN view mounts with live content butview.window == nil. Preferpresent(rnViewController, animated: true)(withmodalPresentationStyle = .fullScreento replace rather than stack) oversetViewControllers(...), and checkview.window != nilbefore blaming the bundle.
Related Skills
cli-and-config.md - CLI commands, config file, artifacts
brownieskill (if installed) - Shared host <-> RN statebrownfield-navigationskill (if installed) - Typed RN -> native navigation
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Callstack
- Publisher
- Callstack (Official)
- Source
- callstackincubator/agent-skills · skills/react-native-brownfield-migration · commit 59e9d17
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Callstack.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download react-native-brownfield-migration.zip