Beyond the Monolith: Mastering Universal Micro-Frontends with Module Federation and Expo

I’ve spent a significant portion of my career wrestling with frontend monoliths. We’ve all been there: a repository so large that a single dependency update feels like a game of Jenga, and CI/CD pipelines that take long enough for a coffee break—and a lunch break.

For a long time, the promise of Micro-Frontends (MFEs) was largely confined to the web. We had Webpack Module Federation for our React apps, but our React Native mobile apps remained stubbornly monolithic. That changed for me when I started pushing the boundaries of Expo and Re.Pack.

Today, I want to share how I’ve been architecting 'Universal' Micro-Frontends that allow teams to ship code independently across both Web and Mobile platforms.

The Core Problem: The Context Switch

In many organizations, the web team and the mobile team operate in silos. Even if they both use React, the deployment cadences are different. Web can deploy twenty times a day; mobile is at the mercy of the App Store review process.

Module Federation solves this by allowing a 'Host' application to dynamically load 'Remote' bundles at runtime. The breakthrough happens when you realize you can apply this same mental model to Expo-based mobile apps.

The Architecture: Host and Remotes

In my recent projects, I’ve moved toward a hub-and-spoke model.

1. The Shell (Host): This is the main Expo entry point. It handles authentication, navigation routing, and the global theme.
2. The Fragments (Remotes): These are independent packages—like a Checkout flow or a User Profile—that are built and hosted independently.

For the web side, this is standard Module Federation. For mobile, we use Re.Pack, a Webpack-based bundler for React Native that acts as a drop-in replacement for Metro when you need advanced features like code-splitting and federation.

Implementation: The Module Federation Plugin

Here’s a glimpse of how I configure a remote container. In your webpack.config.js (or your Re.Pack config), you define what you're exposing:

// remote/webpack.config.js
const { ModuleFederationPlugin } = require('@callstack/re-pack');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'checkout',
      filename: 'checkout.bundle',
      exposes: {
        './PaymentFlow': './src/screens/PaymentFlow',
      },
      shared: {
        react: { singleton: true, eager: true },
        'react-native': { singleton: true, eager: true },
        'expo-router': { singleton: true, eager: true },
      },
    }),
  ],
};

On the Host side, you consume it dynamically:

import { Federated } from '@callstack/re-pack';

const PaymentFlow = React.lazy(() => 
  Federated.importModule('checkout', './PaymentFlow')
);

export default function App() {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <PaymentFlow />
    </Suspense>
  );
}

Why Expo is the Secret Sauce

Many developers think Expo is just for beginners. In reality, its Config Plugins and the Expo Router make it the perfect foundation for MFEs.

With Expo Router, I can define a file-based routing system that stays consistent across platforms. When the Host app loads a remote fragment, the fragment can hook into the existing navigation stack as if it were part of the local codebase. This 'Universal' capability is what allows us to share logic (Hooks, API clients, State Management) without the nightmare of constant npm install and version conflicts.

The Breakthrough: Runtime Updates vs. App Store Reviews

One of the biggest wins I’ve experienced with this stack is the ability to update specific features on mobile without a full binary submission. By hosting the remote chunks on a CDN (like AWS S3 or Cloudflare), the Host app fetches the latest version of the checkout.bundle every time a user opens the app (or based on your caching strategy).

This mirrors the web development experience. We aren't just building apps anymore; we are building a distributed system of UI components.

The Lessons Learned (The Hard Way)

1. Versioning Shared Dependencies: You must be strict with your shared dependencies (React, React Native). If the Host and Remote use different major versions of a singleton library, the app will crash in production.
2. Type Safety: Use Module Federation’s @module-federation/typescript or a shared monorepo (Nx/Turborepo) to ensure that the contracts between your Host and Remotes are type-safe. Just because it's dynamic doesn't mean it should be dangerous.
3. Testing: Testing a federated app requires a mindset shift. You need integration tests that verify the 'Shell' can successfully fetch and render the 'Remote' under various network conditions.

Final Thoughts

Moving to a Micro-Frontend architecture with Expo and Module Federation isn't a silver bullet—it adds complexity to your build pipeline. But for teams scaling past 20+ engineers or managing multi-platform experiences, the trade-off is worth it.

We’ve moved from 'Write once, run anywhere' to 'Deploy once, update everywhere.' And in my experience, that’s where the real engineering magic happens.