Mobile Module Federation with Re.Pack: When Runtime Delivery Is Worth the Complexity

Large React Native apps often hit the same wall: the product keeps growing, team ownership gets more specialized, but releases still move through one mobile pipeline.

One app may contain onboarding, payments, loyalty, search, support, account management, and marketplace flows. Each area has its own roadmap. Each team wants to ship at its own pace. The binary still creates a shared release boundary.

That boundary gets expensive when JavaScript-only changes wait for a full app release, platform teams coordinate every feature handoff, and product teams block each other because everything lands in the same application unit. Those changes still need to fit within store policies and the functionality already represented by the reviewed app.

The harder question is how to give teams runtime ownership over the product areas they already own without breaking the native app model.

What Module Federation means in React Native

Module Federation is an architecture for loading code from separately built JavaScript applications at runtime.

In React Native, the host is the mobile app that ships through the App Store or Google Play. It owns the native shell, app startup, navigation frame, authentication state, shared providers, analytics, crash reporting, native dependencies, and runtime contracts.

A remote is a separately built JavaScript module that exposes a feature, screen, navigator, or product area. The host loads that remote when the user enters that part of the app.

For example, a large mobile app could use:

• A host app for startup, login, navigation, shared design primitives, analytics, crash reporting, and native capabilities.
• A checkout remote owned by the commerce team.
• A rewards remote owned by the loyalty team.
• A support remote owned by the customer operations team.
• An account remote owned by the identity team.

Each remote can have its own build pipeline and JavaScript release process. The user still opens one app. The organization gets smaller delivery units inside that app.

The host and remote distinction is especially important in mobile Module Federation. The host binary can include native code and statically compiled code during the normal store release process. After install, a remote can only rely on JavaScript or Hermes bytecode, plus native capabilities that already exist in the host binary. Web federation does not have the same native-binary boundary.

With Re.Pack, Module Federation 2 brings familiar federation concepts into React Native, but the mobile rules still apply:

• React, React Native, and native dependency versions must stay aligned across host and remotes.
• Native modules used by remotes must already exist in the host app released through the stores.
• Remotes can dynamically load JavaScript, but they cannot dynamically add native code to an installed app.

Mobile Module Federation gives teams dynamic JavaScript delivery within native release rules.

Package sharing, code splitting, and Module Federation

Teams should draw a hard line between three different tools: packages, code splitting, and Module Federation.

Workspaces, monorepos, and internal NPM packages are build-time sharing mechanisms. They are the right fit when teams need reusable code but do not need runtime ownership.

Use packages for:

• Design-system components
• Design tokens
• API clients
• Analytics wrappers
• Utility functions
• Form validation
• Feature flag helpers
• Shared TypeScript types
• Business logic that can ship with the app

That model has a predictable release path:

1. A team updates the package.
2. The consuming app installs the new version.
3. The consuming app rebuilds, tests, and ships with that version.

Code splitting solves another problem. In web apps, it usually means decomposing one bundle into smaller chunks that can be fetched on demand. In React Native, dynamic imports are usually closer to lazy evaluation because Metro release builds still produce one JavaScript bundle. With Re.Pack, true code splitting is supported, but that alone does not create independent ownership or release boundaries.

Module Federation enters when package sharing and code splitting no longer match the release problem.

Federated delivery follows a different path:

1. A remote module is built separately.
2. The host app resolves and loads that module at runtime.
3. The remote team can publish JavaScript changes independently, within the constraints of the shipped host app.

Use shared packages for code reuse. Use code splitting to reduce startup work inside one app. Use Module Federation when independently owned product areas need runtime delivery inside the same React Native app.

That distinction prevents overengineering. A shared package gives teams reuse. Module Federation gives teams runtime independence.

How Re.Pack brings Module Federation to mobile

Re.Pack brings Rspack and the webpack ecosystem to React Native. It also supports Module Federation for React Native apps, including Module Federation 2 through ModuleFederationPluginV2.

Re.Pack handles mobile-specific federation requirements, including React Native runtime plugins, React Native module resolution, and shared React and React Native dependencies.

In a federated Re.Pack architecture, the host declares the remotes it can load. A remote exposes specific modules, such as a navigator, screen, or feature entry point. The host imports that exposed module dynamically and renders it inside the app experience.

At a simplified level, the flow looks like this:

1. The user opens a product area in the mobile app.
2. The host resolves the remote JavaScript bundle.
3. The host loads the exposed module.
4. The remote runs inside the host app’s React Native runtime.
5. The user sees one connected app experience.

If a remote needs a new native module, the host app must include that native module first. That means a normal app-store release still happens before the remote can use the new native capability.

The ownership boundary matters more than the configuration. One team can own a product area as a runtime-loaded JavaScript module, while the platform team governs the host app, native dependencies, shared runtime assumptions, observability, and release safety.

What teams gain

The strongest reason to adopt Module Federation is independent JavaScript delivery.

When product areas have clear boundaries, each team can own its module, release process, monitoring, and rollback path. The platform team can focus on the host, shared contracts, native dependency policy, observability, and release governance.

The benefits are:

• Teams can ship JavaScript changes without waiting for every product area to be ready for a full app release.
• Platform teams can reduce coordination work around feature-level changes.
• Product domains can move into smaller, clearer runtime units.
• Large React Native apps can evolve without forcing every team through the same delivery cadence.
• Super app architectures can keep one installed app while giving business units more control over their surfaces.
• Some modules can load only when the user needs them, provided the team measures load time, caching behavior, memory impact, and failure states.

Module Federation can also make modernization easier. A team can move one product area into a remote, define the host contract around it, and migrate the rest of the app gradually. That matters most when a mobile platform already has years of product logic inside one release unit. Our work with Teamworks is one example: Re.Pack and Module Federation helped rework mobile delivery around seven mini-apps and cut change lead time from 1-2 days to about 10 minutes.

What teams take on

Module Federation adds runtime failure modes.

A remote can be unavailable, slow, incompatible, or broken. A user may be offline, on a weak network, or running an older host app version. Runtime delivery has to handle those conditions as product behavior, not as edge cases.

Teams need to own:

• Fallback UI when a remote cannot load
• Error reporting when initialization fails
• Retry behavior and cache policy
• Compatibility checks between host and remotes
• Rollback paths for bad remote releases
• Monitoring for load time, crashes, and user-facing errors
• Release gates for remote publication

Dependency governance becomes stricter. Host and remotes need compatible versions of React, React Native, shared libraries, navigation assumptions, design tokens, API clients, and native modules.

Native dependency policy matters even more. A remote can reference only native capabilities that already exist in the host binary. If teams ignore that boundary, they create releases that work in development and fail for users on installed app versions.

Testing also expands. Teams need to test remotes in isolation and inside supported host versions. Unit tests and local previews are not enough for a federated mobile system. Contract tests, integration tests, version matrix checks, and production observability become part of the architecture.

Debugging crosses team and deployment boundaries. Logs, source maps, version metadata, ownership signals, and incident response paths need to be part of the system from the beginning.

Module Federation does not create clean boundaries by itself. It rewards teams that already understand their product domains and punishes teams that use runtime loading to hide unclear ownership.

When Module Federation is a good fit

Module Federation is worth evaluating when the mobile app has become a platform for multiple product domains and release coordination is a business bottleneck.

Strong signals include:

• Multiple teams own distinct product areas inside one React Native app.
• Those product areas need separate JavaScript release cadences.
• Full app releases delay JavaScript-only changes.
• Product domains can be expressed as stable module boundaries.
• The platform team can own host architecture, shared contracts, and native dependency policy.
• Remote teams can own testing, monitoring, incident response, and rollback.
• The organization is ready to treat runtime delivery as production infrastructure.

This pattern fits super apps, enterprise mobile platforms, marketplaces, financial apps, loyalty ecosystems, and internal apps where one installed application hosts several business capabilities.

It also fits teams that need a transition path out of a large monolithic React Native app, provided they start with one bounded module and prove the operating model before scaling.

The most important test is whether runtime independence creates real value. If the business does not need independently released product areas, Module Federation is probably solving the wrong problem.

When packages are the better choice

Choose workspaces or internal NPM packages when the main goal is code reuse, and the consuming app can still pick up changes through its normal release process.

Choose code splitting when the main goal is deferring non-critical JavaScript inside one app. With Metro, dynamic imports do not affect release builds. With Re.Pack, code splitting can create real on-demand chunks.

Choose Module Federation when the main goal is runtime composition across independently owned mobile modules.

When to avoid Module Federation

Avoid Module Federation when:

• Codebase size is the main complaint. Better ownership, package boundaries, CI, testing, or release discipline may solve that first.
• The team is small and already ships comfortably.
• Product boundaries are unclear.
• Feature teams cannot own remote quality in production.
• The platform team cannot govern shared dependencies and native module policy.
• The organization lacks monitoring, rollback, and incident response for runtime-loaded code.
• The goal is to work around app-store review. New native capabilities still require a host app release.

Do not assume web and mobile federated containers are interchangeable. Re.Pack brings Module Federation concepts to React Native, but mobile remotes need to be designed for the React Native runtime and the native capabilities available in the host app.

Runtime delivery has a cost. If the organization does not need independent releases, that cost will show up as complexity without enough return.

In practice, many teams looking at Module Federation need something simpler

What to validate first

Start with one remote. Pick a product area with clear ownership, limited native dependency needs, and low blast radius. Define the host contract before building too much around it.

The first validation should cover:

• Navigation contract between host and remote
• Authentication and user context
• Analytics and crash reporting
• Shared design system and theme behavior
• Supported host versions
• Native dependency requirements
• Remote loading, caching, and retry behavior
• Fallback UI for unavailable remotes
• Rollback process for failed remote releases

Then measure the system under real conditions:

• App startup time
• Remote load time
• Memory impact
• Crash rate
• Error rate
• Offline behavior
• Old-host compatibility

Treat those results as rollout criteria. If one remote cannot be operated safely, adding more remotes will multiply the problem.

Key takeaway

Mobile Module Federation with Re.Pack gives React Native teams a way to split one large mobile release unit into independently owned runtime modules.

That can reduce release coordination, clarify product ownership, and make super app architecture more practical. It also introduces runtime failure handling, dependency governance, host and remote compatibility, testing overhead, and production operations work. The signal to look for is release pressure: some teams are ready to ship JavaScript-only changes, but the shared mobile release process keeps them waiting for unrelated product areas.

If your team is evaluating Re.Pack Module Federation or a modular super app architecture, we can help you validate the host boundaries, dependency model, and rollout plan before runtime complexity turns into delivery risk.