Series · 17 parts · In progress
React Native Module Federation
Build a federated React Native app from scratch with Module Federation and Re.Pack: runtime remotes, the shared-singleton contract, and a host shell that owns navigation.
16 of 17 published Next part · 12 October 2026
- Why Module Federation in React Native What runtime micro-apps buy a React Native app, what they cost, and when the trade is worth it. Intro to a series that builds a federated setup from scratch.
- Your first federated remote in React Native Two React Native apps, one loading the other's screen at runtime over Module Federation 2.0 with Re.Pack. Every step copy-paste, ending in a running app.
- The shared-singleton contract in React Native Module Federation Share react, react-native and a native library across a host and its remote the right way; getting it wrong crashes the app on launch, not quietly.
- The host shell: federated remotes as tabs in React Native Turn the host from a single screen into a real app shell: it owns the tab bar and navigation, and each tab is a remote built, shipped and loaded on its own.
- The contract package: a versioned seam between federated remotes in React Native No app can see what the others ship. Two packages, published and installed by version (a typed contract and the shared detail screen), give every side one definition and let semver govern drift.
- One shared store: server state across federated remotes in React Native A remote and an installed package inject their endpoints into one host store and share one cache; get the sharing wrong and the screen hangs on a spinner that never resolves.
- Who owns what: boundaries, teams and coupling in a federated React Native app Who owns a boundary, a component, a data definition? Five tests for cutting a federated React Native app along team lines, and what moves each answer.
- Client state across the seam: remotes that bring their own slices in React Native A remote injects the slice it alone owns into the shared store, the contract carries the one action that crosses, and a write arrives as a prop; dispatch before the slice exists and the add vanishes in silence.
- State stacks under federation: the same React Native app built twice TanStack Query and Zustand rebuild the app Redux Toolkit and RTK Query just built; both work, and what separates them is what happens when independent teams stop coordinating.
- Two backends, one client? RTK Query vs Apollo in React Native The same PokéAPI data arrives over REST and GraphQL through one RTK Query slice, one tag invalidates across both, and the honest question is when Apollo's normalised cache is worth two caches during the transition.
- The design system as a federated singleton in React Native Three federated apps carry three copies of the same greys until a design-system package moves to the seam: gluestack-ui components and NativeWind under Re.Pack, one shared singleton, and one theme toggle that re-themes every remote at once.
- Accessibility testing across federated remotes in React Native A shared testing package gives every remote the same WCAG bar: contrast, touch targets and status semantics checked in the packages that own them, each team's own screens checked in its own suite, and a failing test that found a button nobody could measure.
- shell.navigateTo: native screens from a federated remote in React Native A remote ships JavaScript only, so the host lends it a native screen through one promise: a routing table, a TurboModule, and a Quick Battle in SwiftUI and Compose built so every exit settles the promise.
- The production build and the three modes of a federated React Native app The remotes leave the dev server: built for production, signed at build time and served from a CDN that is a directory and a port. The registry sits in the middle, and one table says which changes still cost an app-store release.
- CDN delivery: the version map, the resolver, and the live flip Every launch, the app asks the CDN which remote versions it may run. Then an operator ships a new one to an installed app with one directory and one line of JSON, and rolls it back the same way. Plus what Apple and Google permit, quoted from the current texts.
- Fallback for federated remotes: the copy in the binary and the net in the session The CDN goes down and the app still starts, from a copy of each remote built into the binary. In a CDN launch, a remote that fails to load drops to its own copy while the other stays on the CDN, and Try again finally retries.
- The signed map and the app that rolls itself back