Designing React Native architecture for more than one app

React Native architecture gets harder when the team needs to ship more than one product surface. Shared navigation, account state, analytics, API clients, and design primitives can help, but only when each layer has a clear reason to exist.

The goal is not to create a platform before there is a product. The goal is to make the next app cheaper to reason about than the first one.

Start from product boundaries

I prefer to identify the flows that product, design, backend, and QA already discuss every week. Those names usually become better module boundaries than technical categories such as utils or services.

For a commerce app, that might mean account, catalog, checkout, orders, and loyalty. For field work, that might mean map, collection, sync, and review.

Keep shared code boring

Shared code should be predictable. It should expose typed contracts, own its tests, and avoid hidden app-specific assumptions. The more magical the abstraction feels, the faster teams stop trusting it.

Make release risk visible

Architecture also needs to support release work. A mobile codebase should make it clear which features touch native APIs, which paths depend on backend state, and which changes can be safely shipped through a JavaScript update.