Offline-first React Native apps can accumulate a surprising amount of local data.
Think about apps used by field workers, delivery drivers, sales teams or retail auditors. They may stay offline for hours while storing:
- SQLite records
- Cached API responses
- Pending mutations
- Upload queues
- Draft forms
- MMKV and AsyncStorage values
Eventually, someone needs to inspect what is actually stored on the device.
The obvious implementation is to read everything, serialize it and send a copy to a dashboard.
That works with twenty keys.
It falls apart with hundreds of thousands of records.
The app spends time reading and serializing data the developer may never look at, while the dashboard parses and renders a copy it never needed.
The dataset should stay on the device
While building NativeScope, I decided to follow one core rule:
Open a window over the data. Do not create another copy of it.
Instead of transferring the entire store, NativeScope requests only the page currently being inspected.
If the developer can see thirty rows, the system should not load thirty thousand.
This changes the cost from being proportional to the entire dataset to being mostly proportional to the current page and viewport.
Four decisions that make this possible
1. Bounded previews
Large values are represented by small previews.
The complete value remains accessible, but it is loaded or streamed only when explicitly requested.
2. Keyset pagination
For large SQLite tables, NativeScope uses cursors instead of increasingly expensive OFFSET queries.
SELECT *
FROM events
WHERE id > ?
ORDER BY id
LIMIT 200;
Page 100,000 follows the same query shape as page one.
3. Cooperative reads
Storage values are processed in small batches.
Between batches, execution returns to the event loop so the React Native app can continue handling touches, animations and network callbacks.
4. Viewport virtualization
The dashboard only mounts the rows currently visible on screen.
A table may contain a million records without creating a million DOM nodes.
The debugger should not become the bottleneck
This architecture is especially useful for offline-first products, where local storage is not just a temporary cache.
It is often the heart of the application.
The goal of NativeScope is to make SQLite, MMKV and AsyncStorage inspection practical even when the dataset grows far beyond what a traditional “copy everything” debugger can comfortably handle.
NativeScope is open source, fully local and built specifically for React Native.
For the complete architecture, including bounded transport, streaming, pagination and rendering budgets, read:
How are you currently debugging large local datasets in your React Native apps?
Top comments (0)