React Native

Peach runs the JavaScript bundle your dev server already builds. You start Expo, Metro or One the way you always do, point Peach at the port, and your app boots on a simulated iPhone or Android device in a browser tab. There is no native build, no Xcode and no Android Studio in the loop, and you change no app code to get there.

This section covers React Native apps: how to connect them, how the runtime runs them, and how to tell which of your libraries work. If you are running a standalone Swift or Kotlin project, start at iOS or Android instead.

#What runs, and what Peach supplies

Your bundle runs as-is. Your components, your navigation, your state and the JavaScript of every library you installed all run from the code Metro or One serves, exactly as on a device.

What Peach supplies is everything a device would supply underneath that JavaScript:

• +
  React Native itself. Peach provides its own implementation of react-native, written to match what the real framework does on iOS and Android: its components, layout, text, scrolling, Animated, Linking, AppState and the rest. Your bundle’s react-native import resolves to it.
• +
  React. Every app runs on the runtime’s React. An app that declares React 18 still runs on React 19, so function component defaultProps, string refs and legacy context are gone. peach doctor tells you when your app declares an older major.
• +
  The native side of your libraries. Wherever a library’s JavaScript calls into native code (a TurboModule, a legacy NativeModules entry, an Expo module or a native view), Peach answers with an implementation of what that native code does on device. How much of each library is implemented is measured and published; see Library compatibility.
• +
  The device. Status bar, safe areas, keyboard, alerts, permissions, appearance, Dynamic Type and the home screen behave as iOS or Android does.

Native code Peach has never seen, such as your app’s own Swift or Kotlin module, has no implementation until you give it one. Until then a module is an inert stand-in and a view renders empty. Custom stubs show how to answer it in a few lines.

#The New Architecture path

Peach presents itself to your bundle as React Native’s New Architecture: Fabric, TurboModules and bridgeless mode. Before any of your modules evaluate, the runtime installs the globals that tell React Native and its libraries they are running bridgeless on Fabric. Modern libraries check for exactly these, so they take their New Architecture code path in Peach, the same one they take in a current release build.

If your app’s native build still turns the New Architecture off, you can ask Peach to present the legacy renderer instead with nativeRenderer: 'paper' in peach.config.ts.

#What running in the browser means for your app

• +
  Your JavaScript runs off the page’s main thread. Peach runs your bundle in its own worker and keeps scrolling, native-driver animations, gestures and painting in separate workers. When your JavaScript blocks, the screen keeps moving, as it does on a phone. The runtime explains which work happens where.
• +
  Network and storage are real. fetch goes to the network from your machine, and storage persists per simulator profile.
• +
  Platform selectors see a device. Platform.OS is ios or android, never web, so your platform-specific code takes its native branch.
• +
  Some native capability is inert by nature. Over-the-air update delivery, dev-client launching and build tooling reached at runtime have nothing to do in a simulator. Libraries that use them import cleanly and return the unavailable or no-op result their API documents.

#Where to go next

• +
  Setup: connect an Expo, Metro or One app and learn the basics of peach.config.ts.
• +
  Run your Expo app: one complete path from an existing Expo app to a tested, shared preview.
• +
  Diagnosing your project: check what of your app Peach runs before you open it.
• +
  The runtime: the JS thread and UI thread split, and what useNativeDriver, Reanimated worklets and gestures mean here.
• +
  Library compatibility: how support is measured, and what to do when a library is missing.
• +
  How Peach works: the full engine design.