Compatibility
The versions this is built against, what it requires you to have installed, and which platforms it runs on.
Versions
v2.5.0Released 30 August 2026What changed →@axonpack/expo-devtools | Expo SDK | React Native | React |
|---|---|---|---|
| 2.5.x | 57 | 0.86 | 19.2 |
That row is what the package is built and tested against — the versions in its own dev dependencies and in the example app that exercises every tab.
Nothing here pins you to one SDK
Every Expo package this needs is a peer dependency, so each resolves to the version your own SDK ships. The row above is what the package is built and tested against, not a range it refuses to run outside.
What you have to install
| Package | Why |
|---|---|
react-native-safe-area-context | The overlay and panel lay themselves out inside the safe area |
react-native-webview | HTML and image response previews in the Network tab |
expo-clipboard | Every Copy button, in every tab |
Both are peer dependencies, so they come from your app rather than from this package:
npx expo install @axonpack/expo-devtools react-native-safe-area-context react-native-webview expo-clipboardEvery peer range is *. That is deliberate: the point of a peer is that your SDK decides the
version, and a narrower range here would fight it. It does mean npm will not warn you when you are
outside what has been tested, so treat the table above, not the peer range, as the answer.
expo-clipboard is a peer rather than a dependency for that reason — as a dependency it would have
to name a version, and any version it named would tie the package to one SDK line. React Native does
still ship a built-in Clipboard, but it is deprecated, slated for removal, and warns through
console.warn, which this package patches — so its own deprecation notice would appear in its own
Console tab.
Platforms
| Platform | State |
|---|---|
| iOS | Full support, native module included |
| Android | Full support, native module included |
The native module is written once per platform and is loaded optionally, so the panel itself is plain JavaScript and never depends on it existing. That is what makes Expo Go work — see What needs a development build for the handful of readings that go quiet there.
Storage libraries
The Storage tab reads whatever you register, so its compatibility is really the adapters'. Versions the example app is built against:
| Library | Versions handled |
|---|---|
@react-native-async-storage/async-storage | v1, v2 and v3 — getMany and multiGet are both accepted |
react-native-mmkv | v3 and v4 — delete and remove are both accepted |
expo-secure-store | SDK 57 |
| anything else | via defineStorageAdapter, which duck-types nothing |
MMKV and SecureStore carry native code of their own, so a store that needs a development build to
exist also needs one to be inspectable. An adapter over an in-memory Map works in Expo Go.