Skip to main content

Tools and Platform Stack

React Native development is easier when the team is explicit about the approved toolchain. A "whatever works" stack usually turns into inconsistent builds, fragmented debugging, and upgrade pain.

Core development tools​

Node and package management​

Standardize:

  • one Node runtime policy
  • one package manager
  • lockfile ownership
  • install command conventions

TypeScript​

Treat TypeScript as mandatory for production teams. It improves refactoring safety, route typing, service boundaries, and native integration wrappers.

Metro​

Metro is the JavaScript bundler that ships with React Native. Teams should document how local development, cache clearing, asset handling, and monorepo compatibility work in their setup.

Hermes​

React Native’s official docs state that Hermes is used by default and is optimized for React Native workloads. Teams should assume Hermes is part of the standard runtime unless they have a specific reason not to.

Framework and delivery tools​

Expo and EAS​

Expo’s current documentation makes a clear distinction between Expo Go and development builds, noting that development builds are the production-grade path when native configuration, custom libraries, push notification parity, app links, and native assets matter.

This makes Expo and EAS particularly strong for:

  • rapid project setup
  • build automation
  • development clients
  • managed update workflows

React Native CLI and native toolchains​

Use a lower-level stack when:

  • native customization is extensive
  • SDK integration requirements are unusual
  • the organization already runs custom mobile build infrastructure

React Navigation remains a common default. Its documentation emphasizes that the fundamentals cover the core concepts needed for typical mobile apps and also provides a starter template for Expo projects.

Testing and quality tools​

Common team stack:

  • unit and component testing framework
  • end-to-end automation for critical journeys
  • linting and formatting
  • bundle and performance inspection
  • crash and error reporting

CI/CD and release platform​

Document which system owns:

  • build generation
  • signing
  • release promotion
  • artifact storage
  • rollout approvals

Selection criteria​

Choose tools based on:

  • maintenance quality
  • new architecture readiness
  • compatibility with your workflow
  • observability and debugging support
  • long-term ownership cost

Team rule​

A tool is part of the platform only when it is documented, versioned, and owned. Otherwise it is just a local preference.