Skip to main content

Monorepos and Platform Teams

When React Native adoption grows beyond one squad and one app, the organization needs an explicit platform model. A monorepo can help, but only if ownership, dependency boundaries, and release rules are clear.

Why teams move to a monorepo​

Common drivers:

  • shared design system packages
  • shared authentication and analytics contracts
  • multiple mobile apps with overlapping platform logic
  • consistent CI/CD and release tooling
  • stronger code ownership and reuse patterns

A practical monorepo shape​

apps/
  consumer-mobile/
  internal-mobile/
packages/
  mobile-ui/
  mobile-navigation/
  mobile-analytics/
  mobile-auth/
  api-clients/
tooling/
  ci/
  scripts/
docs/

The goal is not maximal sharing. The goal is stable, intentional sharing.

Platform team responsibilities​

A mobile platform team usually owns:

  • repo-wide tooling and build defaults
  • shared design tokens and UI primitives
  • navigation conventions
  • observability contracts
  • native SDK wrappers
  • upgrade planning and dependency governance

Product squads should consume the platform, not rebuild it feature by feature.

Package design rules​

  • Shared packages should have stable public contracts.
  • Product-specific code should remain in app space.
  • Internal packages should publish ownership and breaking-change rules.
  • Native integrations should be wrapped once and reused.

Failure modes​

  • "Shared" packages that mirror unstable screen logic.
  • Every team modifying the platform layer directly without review boundaries.
  • Too many cross-package dependencies and circular imports.
  • Monorepo adoption without a real platform owner.

Decision rule​

Use a monorepo when multiple apps or teams genuinely share stable mobile foundations. Do not adopt it just because it sounds more scalable.