A brownfield architecture that kept feature delivery moving across financial apps used by millions

The client’s native iOS and Android products had been evolving for nearly a decade. They serve millions of people and continue to receive new features, so modernization had to fit around active delivery. A destabilizing release could disrupt trading and other revenue-critical flows, which ruled out a single cutover and made screen-by-screen migration the safest path.

When we started the engagement, the React Native, iOS, and Android codebases lived in separate repositories connected through Git submodules. Configuration and API dependencies crossed those boundaries, leaving native teams responsible for parts of the React Native toolchain and increasing the cognitive load of routine product development.

With more than 200 developers contributing across the ecosystem, the architecture could no longer meet the organization’s needs. React Native had to be encapsulated so iOS and Android engineers could integrate new screens without learning or maintaining its toolchain.

The first challenge sat at the boundary between React Native and the native apps: the Git submodule setup spread configuration and API dependencies across repositories, increased maintenance, and left native teams responsible for parts of the React Native toolchain.

We redrew that boundary by packaging React Native code as AARs for Android and XCFrameworks for iOS. Native teams could consume React Native screens through familiar artifacts, while Node and React Native configuration stayed outside the native applications. This made ownership clearer and brought the integration closer to the release practices those teams already used.

Shared code moved toward a monorepo, supported by an external design system package, refactored navigation, and CDN-based image delivery. Together, these changes provided a steadier foundation for moving one screen at a time while established native flows remained in production.

Our team worked directly with product teams whenever React Native-specific issues surfaced, then turned those fixes into workshops, short technical videos, worked examples, and written guidance. Developers across the organization could reuse the resulting patterns instead of solving the same problems independently.

Owning the full over-the-air update lifecycle

To fix bugs without relying on App Store review, we were tasked with introducing the over-the-air (OTA) updates. The OTA layer needed to be self-hosted and fit the brownfield architecture. It also had to avoid Expo-specific assumptions while remaining compatible with Re.Pack and planned Module Federation use. hot-updater met those requirements and offered a more focused codebase than the older CodePush forks we assessed.

We needed to ensure native-to-JS compatibility at the build level to avoid OTA version skew targeting the wrong native release, which could result in a crash. We created tooling that generated a fingerprint for every native build and embedded it in Info.plist and AndroidManifest.xml, allowing each OTA bundle to reach builds with a matching native layer. Release teams gained finer control over update eligibility than app-version matching could provide. During the implementation, we also contributed two fixes to hot-updater to improve its fingerprinting logic.

Giving coding agents project context

AI-assisted workflows had to follow the same engineering standards as the product teams. We created custom skills containing guidance for React Native development, testing, framework upgrades, and React.

agent-device gave coding agents access to simulators and physical devices, while agent-react-devtools supplied React DevTools context for profiling components and finding excessive rerenders. MSW and Maestro added reusable testing and automation patterns.

The new brownfield architecture gave the client a repeatable way to expand React Native while feature work continued. Native artifacts kept React Native configuration outside the native applications, while the monorepo gave teams a common foundation for future migrations.

Over six months, React Native adoption rose from under 10 percent to about 30 percent across the tracked page set, as the number of React Native pages nearly quadrupled and new feature development continued.

Self-hosted OTA became production-ready for applications serving millions of monthly active users. Because update eligibility was based on native fingerprints, an update could reach every compatible build whose native layer remained unchanged, without depending on coarse app-version matching.

Testing and performance practices matured alongside the migration. Teams gained reusable integration and e2e tests examples, reinforced through workshops and written guidance, while a DMAIC-based performance practice introduced a consistent way to measure and improve application performance. CI regression checks tracked bundle size and related metrics.

The results were measurable: tracked reporting showed an approximately one-third reduction in JavaScript bundle size. More broadly, the client gained a lower-risk path for modernizing mature applications while continuing to deliver features, and established user flows could remain stable as more of the products moved to React Native.