CONCEPT Cited by 1 source
Brownfield RN integration¶
Brownfield RN integration is the problem of embedding React Native into a large, mature, already-shipping native iOS/Android codebase — as opposed to greenfield RN, where the app is built on RN from day one. The term brownfield is borrowed from the greenfield/brownfield software terminology.
Why it's hard¶
Zalando's 2025-10 post names the three failure modes explicitly:
- Native-dependency conflicts — RN's own native modules, and community RN packages, carry native dependencies. A legacy native app usually already depends on some of those same deps at different versions. Without a clean separation, version conflicts cascade into build failures.
- No clear separation between RN and legacy code. Naïve integration approaches (e.g. git submodules) don't enforce the RN / legacy-code boundary. "We asked ourselves where to put the React Native code and how to embed it properly in our apps' codebases? Git submodules were one option but come with a lot of other issues and they don't enforce strict separation."
- Bad developer experience.
- Building a large native app is slow even with caches.
- Every RN contributor must set up Xcode and Android Studio, which is a friction barrier for web engineers — the contributor pool most naturally equipped to write RN code.
- Every RN iteration requires rebuilding some portion of the native app stack.
Each of these gets worse the larger the legacy codebase is. At Zalando's scale (90+ screens across two native apps) they compound into a productivity tax that made Zalando rearchitect the integration.
The resolution pattern: RN as a package¶
concepts/react-native-as-a-package — package the RN root + init logic as an npm package, consumed by both a standalone developer app (greenfield RN, fast iteration) and a native framework SDK (wraps RN behind a native-API surface that the legacy app links against). Callstack's open-source package generalises the pattern.
Contrast with greenfield RN¶
A greenfield RN migration (Shopify's canonical five-year case in sources/2025-01-13-shopify-five-years-of-react-native-at-shopify) can iterate team-by-team, with the RN framework as the default substrate and native as the escape hatch. A brownfield RN migration (Zalando's 2025-10 case) starts with native as the substrate and adds RN screen-by-screen through an integration layer.
The cost structures differ:
- Greenfield: learning curve on RN patterns across all teams; shared mobile foundations need building. Shopify's first ~3 years were per-app autonomy (see concepts/shared-mobile-foundations).
- Brownfield: integration-layer engineering cost up front (Entry Point + Framework SDK + Developer App + Turbo Module DI contracts), then progressive per-screen migration on the legacy app's release cadence.
Seen in¶
- sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native — canonical wiki first source for the brownfield RN problem framing. Zalando describes all three failure modes and walks through their resolution architecture.