Back to blog Start with part 1
Series · 19 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.
5 of 19 published Next part · 20 July 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 The host can't see what a remote exposes. A contract package, published and installed by version, gives both sides one definition and lets semver govern drift.
- One shared RTK Query store + real PokeAPI (server state)
- Cross-module state: slice injection and dispatch (client state)
- State stacks compared under federation
- Two backends, one client? RTK Query vs Apollo
- The design system as a federated singleton
- Accessibility testing across federated remotes
- shell.navigateTo: RN ↔ native handoff
- The production build and the three modes
- Loading remotes from a CDN + version resolution
- The live two-version flip
- Offline fallback baked into the binary
- In-session fallback when a remote fails
- Signing the version-map + replay/rollback guard
- Health-based cross-launch auto-rollback