Technical comparison

NativeScope and Rozenite,
compared by trade-offs.

This page is not a verdict. Both tools can help React Native teams debug storage. The useful question is which attachment model, product scope and day-to-day workflow you want.
Comparison point
Product model

A local React Native debugging environment. Storage is the first module.

A DevTools plugin platform with official plugins across several debugging areas.

Attachment style

Starts Metro with a resolver attached, then discovers storage that the app already uses.

Mounts plugin hooks and adapters that the app registers explicitly.

Storage coverage

AsyncStorage, MMKV and expo-sqlite in one package today.

Storage plugin covers key-value stores; SQLite uses its own plugin.

Configuration philosophy

Default path is install, run, open the app. Config is reserved for behavior NativeScope cannot infer.

Explicit registration makes the supported surface visible in your app code.

Experience focus

Large payload browsing, visual JSON editing, SQLite table work, snapshots, diff and restore.

Composable DevTools panels that fit a wider plugin ecosystem.

Best fit

Teams that want storage debugging to feel automatic, local, and low-friction.

Teams that prefer assembling a broader DevTools room from explicit plugins.

Using the tool

The biggest difference is the storage workspace itself.

NativeScope's first module is shaped around the moments where storage debugging usually gets slow: finding the key, opening nested JSON, changing one field, comparing what changed and restoring safely.

Find the right value

Search across keys, values, SQLite tables and nested JSON fields from one local Studio.

Edit visually

Open large JSON arrays as tables, edit cells inline, add rows through drawers and keep types visible.

Work with real tables

SQLite gets tabs, selectable rows, sortable columns, resizable cells and direct SQL when needed.

Diff and restore

Capture a baseline, act in the app, inspect changed fields and restore the exact value.

Setup shape

Commands and app code are different concerns.

The install command tells you what enters the project. The code block tells you what the app has to know about the tool.
Command
pnpm add -D react-native-nativescope
pnpm nativescope
Optional app behavior
// nativescope.config.ts
import { defineNativeScopeConfig } from "react-native-nativescope/app"

export default defineNativeScopeConfig({
  modules: {
    storage: {
      reactQuery: true,
      indicator: true,
    },
  },
})
NativeScope discovers storage without a provider, hook, adapter or instance registry. The root config is only for behavior such as React Query invalidation or the in-app indicator.
Command
pnpm add -D @rozenite/storage-plugin @rozenite/sqlite-plugin
App registration
const storages = [
  createMMKVStorageAdapter({ storages }),
  createAsyncStorageAdapter({ storage }),
]

const adapters = [
  createExpoSqliteAdapter({ databases }),
]

useRozeniteStoragePlugin({ storages })
useRozeniteSqlitePlugin({ adapters })
Explicit registration gives the app direct control over the plugin surface.

Choose NativeScope when

You want storage debugging to disappear into one command.

You want a local Studio that discovers what it can, stays out of release builds and makes large storage payloads editable. Storage ships first; the longer-term NativeScope goal is a modular React Native debugging environment with the same low-friction setup.

Choose Rozenite when

You want an explicit plugin platform.

You prefer a broader DevTools ecosystem where each capability is registered in app code. That model can be a better fit when your team values explicit composition across many debugging surfaces.