# Rozenite puts third party debugging panels inside React Native DevTools

> Rozenite is a Callstack project that lets you install a panel into React Native DevTools as a plugin, with no extra windows, servers or browser tabs. It suits React Native developers who want network, storage and performance views next to the existing inspector, and it reaches Lynx and React Native Web only experimentally.

**callstackincubator/rozenite** — Plug-and-play panels for React Native DevTools. Install, enable, and start debugging in minutes.

- Repository: https://github.com/callstackincubator/rozenite
- Website: https://rozenite.dev
- Stars: 667 · Forks: 53
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/callstackincubator-rozenite

## Panels live in the DevTools window instead of a second tool

The design decision everything else follows from is that a Rozenite panel renders inside React Native DevTools. The README describes the project as plug-and-play panels for React Native and Lynx, and the feature list is explicit that panels live inside DevTools by default, with no extra windows, servers or browser tabs. That framing matters because the usual alternative for inspecting a React Native app is a separate desktop tool, a separate web page or a proxy that sits between the app and the network. Each of those adds a moving part to the debugging loop. Installing a plugin and enabling it is the whole workflow, and the project states the goal plainly: start debugging in minutes. The people this serves are React Native developers who already live in the DevTools inspector, mainly on Expo or bare projects, and who want network requests, storage and performance updates in the same place as the component tree, with live updates as they use the app.

## Real-time panels cover network, storage and performance

The feature list names three areas of live inspection: network requests, storage and performance, with updates as you use the app rather than after a reload. Live updates are what make a panel worth keeping open, since a panel that needs a manual refresh is a log file with extra steps. The panel concept is also how Rozenite extends beyond what DevTools ships with, since the project describes itself as adding panels rather than replacing the inspector. A plugin is a self-contained unit that registers a panel, which is why the feature list says installed plugins appear automatically. That is also the boundary of the model. Rozenite does not attempt to become a different inspector, it attaches to one, so a workflow that needs a completely different view of the app still needs a different tool.

## A plugin is disabled automatically in production builds

This is the feature that decides the risk question, and it is stated as a rule rather than a recommendation: plugins are automatically disabled in production builds, so no plugin code ships to your users. For a mobile app, that is the failure mode every other debugging tool has to warn about, because a panel left enabled in a release build adds code to the shipped binary and can expose internal state to whoever has the app. Rozenite removes that decision from the developer by making the behaviour the default. The project also says it is free to use and will remain so, which is a reasonable expectation for a debugging tool that sits in a development dependency tree. The licensing position matches: the repository carries an MIT licence and the package metadata declares MIT as well, so a plugin you write yourself can be released under whatever terms you prefer.

## Version floors are explicit, and Expo SDK 52 is the anchor

The compatibility table is the practical gate for adoption, and it is short enough to reason about. Rozenite 1.13.0 and anything from 2.0.0 upwards needs Expo SDK 52 or later, React Native 0.76 or later, and Re.Pack 5.2 or later. Bare React Native projects are supported as well, with the instruction to match your React Native version to the one shipped by the minimum supported Expo SDK listed above, which is a slightly indirect way of saying the React Native floor is the same 0.76. The docs site holds the full compatibility details. The reason to care about the floors is that Rozenite is a plugin system, so it needs a way to inject itself into the app's development bundle, and the way it does that is tied to the versions of the bundler and the runtime. A project still on an older React Native will find the plugin simply does not load, with no partial support in between.

## Lynx and React Native Web arrive through different transports

The reach beyond React Native is the interesting part of the design, because the same panels, plugins and CLI are reused rather than reimplemented. Lynx apps are reached through rspeedy, and the README notes that this support requires Rozenite 2.4.0 or later, rspeedy 0.16 or later and @lynx-js/react 0.125 or later. React Native Web apps are reached through a browser extension, which is a different mechanism entirely, since there is no native bundle to instrument in a web build. Both paths are labelled experimental in the README, and that label should be read literally. A React Native Web team that wants to standardize on one panel set across native and web will find the promise appealing and the maturity uncertain. The separate documentation pages for Rozenite for Lynx and for plugin development are the right place to judge how far each path has been taken.

## Running the CLI from a pnpm workspace with turbo and changesets

The repository is a pnpm monorepo, and the root package.json shows how the pieces are driven. The rozenite script points at the CLI entry point, the playground can be started for the web, for Android or for iOS through separate scripts, and Storybook is available for the UI packages. Everything else goes through turbo, which means build, typecheck, lint, test and format tasks are declared per package and can be run across the whole set or only on what changed. Releases are handled with changesets, with a release:plan step, a release:check that runs typecheck, build, lint and test, and a release:publish step. That setup is worth noting for anyone planning to write their own panel, because it is the same machinery the project uses for its own releases, and the repository also carries a plugin-directory.json, a lefthook configuration and an oxfmt formatter configuration.

```json
    "rozenite": "node packages/cli/bin.js",
```

The documentation site lists a Quick Start page, a Plugin Directory, a Rozenite for Lynx page and a Plugin Development overview, and the README states that a custom panel is built with type-safe, isomorphic APIs.

## Where Rozenite is the wrong choice

The first limit is that the value proposition is entirely inside DevTools. If your debugging needs are not panel-shaped, if you need to record a session, compare two runs, or inspect a crash from a device you cannot attach to, a panel inside an inspector is the wrong container, and a purpose-built tool that owns its own window and storage will serve better. The second limit is the experimental boundary. Lynx and React Native Web are supported in the box but marked experimental, so a team shipping a Lynx app in production is betting on a path the project itself has not labelled stable. The third limit is the version floor, which is the price of the injection mechanism: Rozenite 2.x with React Native 0.76 and Expo SDK 52 is a recent stack, and a legacy app that cannot move cannot use it. The fourth limit is the plugin ecosystem itself, since the value of the model is what exists in the plugin directory, and the documentation points there rather than promising a catalogue.

## Conclusion

React Native developers who want network, storage and performance inspection inside the DevTools window they already have, rather than in a second tool, are the people Rozenite suits, and the production-safety rule is the strongest argument for it since plugins are disabled automatically in production builds. It is the wrong choice for a team that has to support Lynx or React Native Web in production today, because both paths are marked experimental, and it is the wrong choice if you need panels that work outside DevTools, since the whole design is that panels live inside DevTools by default. Before you commit, check three things: that your Expo SDK or React Native version is inside the compatibility table, that your bundler is Metro or Re.Pack at the listed versions, and whether the panel you actually need exists in the plugin directory rather than being one you have to write. The project is MIT licensed, developed at Callstack, the last push was on 2026-10-20, and the newest release is v2.5.0 from 2026-10-12.

## FAQ

### What is Rozenite and what does it add to React Native DevTools?

Rozenite is a plugin system that adds installable panels to React Native DevTools, covering network requests, storage and performance with live updates. Panels live inside DevTools by default, with no extra windows, servers or browser tabs.

### Which React Native versions does Rozenite support?

Rozenite 1.13.0 and 2.0.0 or above require Expo SDK 52+, React Native 0.76+ and Re.Pack 5.2+. Bare React Native projects are supported by matching the React Native version shipped with that minimum Expo SDK.

### Do Rozenite plugins run in production builds?

No. Plugins are automatically disabled in production builds, so no plugin code ships to your users. The project is MIT licensed and free to use.

### Does Rozenite work with Lynx and React Native Web?

Both are supported, and both are marked experimental. Lynx apps are reached through rspeedy, needing Rozenite 2.4.0+, rspeedy 0.16+ and @lynx-js/react 0.125+, while React Native Web apps use a browser extension.

### How do I build a custom panel for Rozenite?

The README points to a Plugin Development overview in the documentation, and says custom panels are built with type-safe, isomorphic APIs. The monorepo also ships a plugin-directory.json and a plugin directory page listing what already exists.

## Sources

- [callstackincubator/rozenite on GitHub](https://github.com/callstackincubator/rozenite)
- [License: MIT](https://github.com/callstackincubator/rozenite/blob/main/LICENSE)
- [Project website](https://rozenite.dev)
- [README](https://github.com/callstackincubator/rozenite/blob/main/README.md)
- [Releases](https://github.com/callstackincubator/rozenite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/callstackincubator-rozenite