Our goal

One debugging environment.
None of the usual friction.

NativeScope is becoming an all-in-one React Native debugging environment: fully local, account-free and simple enough to adopt in the middle of a difficult debugging session.

0logins

0cloud dependencies

1optional config file

Nmodules, only when needed

The honest premise

New is not automatically better.

Most debugging categories already exist. We are not interested in pretending otherwise. We begin with workflows the community already understands, identify where they become slow, fragmented or difficult to adopt, and improve those points in ways we can prove.

That means naming the tools that inspired us, explaining the pain we felt while using them and being transparent about trade-offs. The user should leave with enough evidence to choose, even when that choice is not NativeScope.

Borrow openly. Improve measurably. Prove everything.

The first proof

Storage is module one, not the finish line.

We started with storage because its problems are concrete: hidden app state, fragmented providers, stale UI after edits and inspectors that collapse under real datasets. The finished module is our evidence that calm UX can sit on serious engineering.

01
Performance

A window, not a copy

The budgets, cursor pagination, streams and virtualization behind fluid inspection at gigabyte scale.

02
Architecture

Zero config, for real

How Metro interception and release guards make plug-and-play an engineering property instead of a slogan.

03
Choice

A factual comparison

The integration trade-offs beside another capable ecosystem, with sources and without declaring a winner.

The environment

One Studio for the questions that interrupt your work.

Storage is live today. Future modules will follow real community needs: network traffic, structured logs, performance, state, navigation, files and device events. Familiar Reactotron-style capabilities can live beside deeper purpose-built tools without turning installation into a platform migration.

ONE LOCAL CORE · MODULES ONLY WHEN NEEDEDlocal coreStorageavailable nowNetworkrequests · replayLogsstructured timelineStatequeries · storesPerformanceframes · memoryNavigationroutes · deep linksFilesimages · cacheNotificationspayloads · events
The shape is modular on purpose. The Studio gains a surface only when its module is present; removing a module removes that surface without changing the rest.

The non-negotiable

Capability may grow. Integration may not.

The React Native community includes people shipping their first app and engineers maintaining products used by millions. Neither group should have to restructure an app, understand our internals or maintain a second inventory just to inspect it.

Automatic discovery remains the default wherever it is safe. When explicit behavior is necessary, it belongs in the single root config file. Adding a module should mean adding a line, not adopting a new architecture.

  • One guided integration surface
  • Advanced control without an advanced entry price
  • Modules disappear cleanly when removed
nativescope.config.tsone optional file
import { defineNativeScopeConfig } from
  "react-native-nativescope/app"

export default defineNativeScopeConfig({
  modules: {
    storage: {
      indicator: true,
      reactQuery: true,
    },

    // Product direction: one config block per module
    // network: {
    //   enabled: true,
    // },
    // performance: {
    //   enabled: true,
    // },
    // navigation: {
    //   enabled: true,
    // },
  },
})

Storagediscovered automatically

+ Networkone future config block

+ Performanceone future config block

+ Navigationone future config block

Your app remains yours.NativeScope absorbs the integration work.
Storage needs no inventory in this file today. Unreleased module blocks are shown as comments to document the product direction without pretending that future APIs already exist.

Our contract

The rules every module has to keep.

Local first

Your debugging data stays on your machine.

No account

A useful local tool should not begin with a signup form.

Simple by default

A beginner gets the same safe path as an experienced engineer.

Dev-only

Instrumentation belongs in development and is checked out of release bundles.

Modular

Install the capability you need. The Studio reflects what is present.

Evidence over claims

We publish mechanisms, constraints and trade-offs.

Built in the open

The first module is already the proof.

Inspect how it works, challenge the decisions and use the evidence to decide whether it belongs in your workflow.

Get startedRead the engineering