Rozenite is an MIT-licensed, TypeScript-based open-source project that adds plug-and-play debugging panels to React Native DevTools, built for React Native and Expo developers who want to inspect network requests, storage and performance without leaving the DevTools window they already have open.

What it is

Rozenite is a developer tool from Callstack that brings plug-and-play panels to React Native DevTools. It lives in the React Native tooling ecosystem and works with both Expo and bare React Native projects across Metro and Re.Pack bundling workflows, with React Native Web and Lynx support included in the box. Its public surface is a set of installable plugins, a plugin directory and a CLI, backed by documentation at rozenite.dev and a published npm runtime package.

The concrete problem it solves is fragmentation in the debugging workflow. Inspecting network requests, storage and performance in a React Native app has typically meant moving out of DevTools into extra windows, dedicated servers, or additional browser tabs, each with its own setup. Rozenite replaces that scattered arrangement with panels that live inside DevTools by default: a plugin is installed, it auto-appears, and debugging starts in minutes. Real-time updates for network requests, storage and performance arrive as the app is used, so the picture stays current rather than being a snapshot pulled from a separate process.

Key capabilities

• Plug-and-play panels: installing a plugin makes it appear automatically in React Native DevTools, with no manual panel registration.
• Unified DevTools experience: panels live inside DevTools by default, with no extra windows, servers, or browser tabs.
• Real-time debugging: live updates for network requests, storage and performance while the app is running.
• Broad setup coverage: compatibility with Expo SDK 52+ and bare React Native 0.76+ projects, across Metro and Re.Pack 5.2+ workflows, on Rozenite 1.13.0 and >= 2.0.0.
• Beyond React Native, experimentally: the same panels, plugins and CLI reach Lynx apps through rspeedy 0.16+ and React Native Web apps through the browser extension.
• Production-safe controls: plugins are automatically disabled in production builds, so no plugin code ships to users.
• Custom panel authoring: teams can build their own panels against type-safe, isomorphic APIs, documented in the Plugin Development section of the docs.

Who uses it and how

• Expo teams on SDK 52 or later add plugins to existing projects and debug inside the DevTools instance already in their workflow, without standing up a separate server.
• Bare React Native projects on 0.76 or later use it by matching their React Native version to the one shipped by the minimum supported Expo SDK.
• Teams bundling with Re.Pack 5.2+ or with Metro use the same panels across either workflow, so mixed toolchains do not require a second debugging tool.
• Plugin authors build custom panels with the type-safe, isomorphic APIs and distribute them through the plugin directory.
• Teams working with Lynx via rspeedy 0.16+ or with React Native Web via the browser extension adopt it on an explicitly experimental basis.

Getting started

Setup is covered by the Quick Start guide at rozenite.dev/docs/getting-started, with the runtime published on npm as @rozenite/runtime. After that, plugins are installed, enabled, and used directly inside React Native DevTools.

How it compares

The facts provided for this listing name no comparable tool, so Rozenite stands alone in this registry rather than being measured against alternatives. It also complements rather than replaces React Native DevTools itself: it plugs panels into that host instead of asking developers to adopt a separate debugging application.

When to use it — and when not

It suits teams already inside the supported version floors, namely Expo SDK 52+, React Native 0.76+ with Rozenite 1.13.0 or >= 2.0.0, and Re.Pack 5.2+ if that bundler is in use, and it is a poor fit for anyone below those floors or who needs instrumentation inside a shipped production build, since plugins are disabled there by design. The Lynx and React Native Web targets are labelled experimental, so teams requiring guaranteed support on those platforms should plan accordingly rather than assume parity with the React Native path.