Mobile — Mobile App Architecture

React Native Micro-Frontends: When and How

Direct answer

Micro-frontends in React Native mean independently developed and shipped feature modules composed into one app binary — and they are rarely worth it. The pattern earns its cost only when several autonomous teams need to ship into one app on separate cadences, as in super-apps or large organizations. For most teams, a well-modularized monorepo with enforced package boundaries delivers the same team autonomy without runtime module loading, version skew, and app-store complications.

Micro-frontends arrive in mobile conversations with web-scale enthusiasm and get expensive fast, because a phone app is one binary reviewed by one store, not a URL you can compose at request time. Here is the honest decision framework I give teams who ask for this, and the implementation ladder when it is genuinely justified.

Key facts, with sources

React Native's New Architecture became the default in 0.76, the legacy bridge was retired in 0.82, and Hermes V1 shipped as the default JavaScript engine in 0.84. (TO THE NEW Blog)
Microsoft retired Visual Studio App Center and CodePush on March 31, 2025, forcing every team that depended on it to migrate their over-the-air update architecture. (microsoft/react-native-code-push GitHub issue)
In the State of React Native 2024 survey, Redux drew the most negative feedback at around 18% dissatisfaction, while React's built-in state management (31% positive) and Zustand (21% positive) were the best regarded. (InfoQ)
Over 80% of State of React Native 2024 respondents work in teams of up to five developers, meaning most mobile architectures must be maintainable by very small teams. (SSOJet (State of React Native 2024 highlights))
Published production examples report Shopify at 86% unified code across its apps and Instagram sharing 85 to 99% of code between iOS and Android. (CatDoes)

What micro-frontends actually mean inside one binary

On the web, micro-frontends compose independently deployed apps at runtime. In React Native the equivalent has three flavors: separate packages in a monorepo composed at build time; separately bundled JavaScript modules loaded at runtime through module federation tooling; or multiple React Native surfaces embedded in a native shell, each owned by a different team. Only the second and third are true micro-frontends — the first is just good modularization.

That distinction matters because the benefits people actually want — clear ownership, isolated codebases, independent development — come mostly from the build-time version. What runtime composition adds is independent release cadence, and that single benefit carries almost all of the pattern's cost. Be precise about which one you need before adopting the vocabulary.

The trigger is organizational, not technical

Codebase size alone never justifies micro-frontends; a large app with one release train is served perfectly well by a modular monolith. The genuine trigger is organizational: multiple teams with separate roadmaps, separate on-call, and separate release schedules, all shipping into one app. Super-apps with semi-independent business lines, or enterprises where a shared shell hosts modules from different departments, fit this description.

If your whole mobile group ships together anyway, runtime module independence is pure overhead — you pay for release decoupling you never use. In consulting engagements I ask one question first: has a team actually been blocked from shipping by another team's release, more than once? If the answer is no, the pain is hypothetical, and the architecture should stay simpler than the org chart's ambitions.

The costs nobody puts on the slide

Runtime-composed React Native modules introduce version skew as a permanent condition: the shell and each module must agree on React, React Native, and every shared native dependency, because there is still exactly one native runtime in the binary. Native modules cannot be federated at runtime — anything requiring native code still ships with the app build, which quietly re-couples the "independent" teams whenever one needs a new native capability.

Add to that: shared dependency governance meetings, a bootstrapping and routing layer you now own, harder crash attribution across module boundaries, over-the-air update coordination so modules and shell stay compatible, and app review policies around downloaded code that constrain how dynamic you can be. None of these is fatal. Together they are a standing tax that only heavy organizational decoupling repays.

The implementation ladder I recommend

Climb this ladder only as far as the pain demands. Step one: a monorepo with feature packages, enforced import boundaries, and code ownership per team — this alone gives most teams everything they wanted from micro-frontends. Step two: separate over-the-air update channels or staged feature flags per team, which decouples feature release timing without decoupling builds.

Step three: module federation tooling on top of the bundler, giving true runtime loading of team-owned JavaScript bundles within one shared runtime — adopt this only with a platform team to own the shell, the shared dependency contract, and the CI that verifies compatibility. Step four: brownfield-style composition where a native shell hosts multiple surfaces, which is really an integration architecture for very large organizations. Most teams should stop at step one or two; I have seen far more regret above that line than below it.

If you do it: rules that keep it survivable

Treat the shell as a product with its own team: it owns navigation between modules, authentication, design-system distribution, and the shared dependency manifest. Modules declare their compatibility range against a shell version, and CI builds the real composed binary on every module change — integration bugs discovered at app review time are the expensive kind.

Define the inter-module contract narrowly: modules communicate through routes and a small event interface, never by importing each other's internals. Keep analytics and crash reporting tagged by module so ownership of a regression is unambiguous. And write down an exit strategy — because the composition layer is infrastructure you own, you want the ability to collapse a module back into the monolith when a team merges or a business line winds down, which happens more often than architectures assume.

When to hire senior help

Architecture is the cheapest place to buy senior expertise, because decisions about state management, navigation, offline strategy, and update infrastructure made in week one determine costs for years. A short engagement with a senior mobile architect before or during MVP planning routinely prevents the rewrite-at-scale scenario that hits teams around their first major growth phase. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Mobile App Architecture projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

✕Adopting Redux with sagas and heavy boilerplate for a five-screen MVP when built-in React state or Zustand would cover the actual requirements
✕Scattering business logic inside UI components instead of isolating a data layer, making later backend changes or native module swaps expensive
✕Building deployment architecture on a hosted OTA service with no exit plan, a risk the March 2025 CodePush shutdown made concrete for thousands of teams
✕Assuming permanent connectivity and bolting on caching later, instead of designing offline storage and sync conflict resolution before the data layer hardens

Frequently asked questions

Are micro-frontends possible in React Native at all?

Yes, with real constraints. Module federation tooling can load team-owned JavaScript bundles at runtime, and native shells can host multiple React Native surfaces. But all modules share one native runtime, so React and native dependency versions must stay aligned, and native capabilities still ship with the binary. It is independence for JavaScript features, not full-stack independence.

What should a small team use instead of micro-frontends?

A modular monorepo: feature packages with enforced import boundaries, clear ownership, and one release train. Add per-feature flags or staged over-the-air channels if release timing needs decoupling. This delivers the ownership and code-isolation benefits people actually seek from micro-frontends, without runtime loading, version-skew management, or a shell platform to maintain.

Do app store rules allow dynamically loaded feature modules?

Downloaded JavaScript that stays within the platform's update policies is generally acceptable, the same way over-the-air updates are — it must not change the app's fundamental purpose or bypass review-sensitive functionality. Native code always ships through the store. Any micro-frontend design should treat store policy as a hard constraint and keep dynamic behavior within the established update mechanisms.

What state management should a new mobile app use?

For most apps, React's built-in state plus a light library like Zustand is enough; in the State of React Native 2024 survey those two drew the most positive sentiment while Redux drew the most negative at about 18% dissatisfaction. Heavier tooling is justified mainly by large teams, complex shared state, or strict audit requirements.

Do we need offline support from day one?

If users operate in the field, in transit, or in markets with unreliable networks, yes, because retrofitting offline-first sync onto an online-only data layer is one of the most expensive refactors in mobile. If the app is unusable without live data anyway, graceful error and retry handling may be sufficient.

What are over-the-air updates and should our app use them?

OTA updates push JavaScript-level fixes directly to users without waiting for app store review, which is valuable for hotfixes. Microsoft's CodePush was retired on March 31, 2025, so current options are EAS Updates, a self-hosted CodePush server, or third-party services, and updates must stay within store policies that prohibit changing an app's core purpose.

Bottom line: Dhairya Senjaliya ships Mobile — Mobile App Architecture projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.