JailMonkey: root, jailbreak and mock location checks for React Native

The question the module is built around

JailMonkey is a React Native library for identifying whether a phone is rooted or for mocking locations, and the framing in the documentation is worth keeping. The heading asks whether you can ever really trust a phone, and the opening scenario is users claiming to be crossing the globe in seconds while collecting all the Pokeballs. Some apps need to protect themselves in order to protect data integrity.

From that, three concrete capabilities follow. The module can identify if a phone has been jail-broken or rooted on iOS and Android. It can detect mocked locations for phones set in developer mode. And, on Android only, it can detect if the application is running on external storage such as an SD card.

Those three checks are what a consumer or financial app usually needs on the device. The module is not a full device attestation system and does not claim to be one, which is a point in its favour: you can read the whole surface area in a minute and decide whether it earns its place in your app.

The package is MIT licensed, the author is listed as Gant Laborde, and the main entry point is index.tsx with a separate jailmonkey.d.ts typings file.

The four cross-platform calls and their return types

The API is small enough to reproduce in full. The cross-platform methods are:

- isJailBroken, returning a boolean, asking whether this device is jail-broken or rooted. - canMockLocation, returning a boolean, asking whether this device can fake its GPS location. - trustFall, returning a boolean, which checks whether the device violates either isJailBroken or canMockLocation. - isDebuggedMode, returning a Promise of boolean, which reports whether the application is running in debug mode.

The mixed return types are the detail that catches people out. isDebuggedMode is asynchronous because reading the debug flag needs a native call, and the same pattern shows up again on Android with isDevelopmentSettingsMode. Every other method is synchronous, which means you cannot call them inside an async chain expecting to await them.

The intended usage is a single check at the point of interest:

import JailMonkey from 'jail-monkey'

if (JailMonkey.isJailBroken()) {
  // Alternative behaviour for jail-broken/rooted devices.
}

On iOS there is one extra method, jailBrokenMessage, which returns the reason for the jailbroken detection as a string, and which returns an empty string on Android.

Android-only checks and the granular rooted detection object

Android gets a larger surface: hookDetected, which reports whether there is any suspicious installed application, isOnExternalStorage, which reports whether the app runs on external storage such as an SD card, AdbEnabled, which reports whether Android Debug Bridge is enabled, and isDevelopmentSettingsMode, a promise returning boolean telling you whether the user has enabled development settings.

The most interesting one is androidRootedDetectionMethods. Instead of a single boolean it returns a RootedDetectionMethods object with the results of all the Android rooted detection methods, so you can see which individual check fired. The documentation says this is helpful if some devices are giving false positives, and that is exactly the use case, since a single isJailBroken boolean tells you nothing about which signal triggered.

The shape of the object is documented as a type:

type RootedDetectionMethods = {
  rootBeer: {
    detectRootManagementApps: boolean;
    detectPotentiallyDangerousApps: boolean;
    checkForSuBinary: boolean;
    checkForDangerousProps: boolean;
    checkForRWPaths: boolean;
    detectTestKeys: boolean;
    checkSuExists: boolean;
    checkForRootNative: boolean;
    checkForMagiskBinary: boolean;
  },
  jailMonkey: boolean;
}

Nine RootBeer checks plus the module's own jailMonkey flag. On iOS all of the Android-only methods return false, or Promise of false where appropriate, so a cross-platform codebase can call them without guarding.

Installing the package and the two architecture lines

Installation is a normal npm package add, and the linking step is only needed for older React Native:

npm i jail-monkey --save
react-native link # Not required as of React Native 0.60.0

On iOS the pods are installed from the ios directory:

cd ios && pod install

The version situation is the part to get right. New Architecture support was added in v3.0.0 with backward compatibility, and the documentation instructs you to install it with npm install jail-monkey@latest. For the Old Architecture, the Bridge, the latest version is 2.8.5. The release history matches that split, with v3.0.0 published on 2026-04-28, a v3.0.0-1 on 2026-04-27 and a 3.0.0-0 prerelease on 2026-02-21.

The package carries a codegenConfig with the name NativeJailMonkey and the type modules, which is the New Architecture codegen, and the repository holds a JailMonkey.xcodeproj, a jail-monkey.podspec, an android/ directory, the JailMonkey/ native source, a specs/ directory and two example apps, ExampleProject/ and ExampleExpo/.

There is one historical warning. If you use rnpm, you may have trouble, as rnpm does not link Android properly after 0.29.0.

Emulators make these checks fire during development

The documentation raises this directly: since emulators are usually rooted, you might want to bypass these checks during development, unless you are keen on constant false alarms.

That is a real operational cost rather than a footnote. A CI pipeline that runs on an emulator image, or a developer's local Android Studio emulator, will trip isJailBroken and possibly isOnExternalStorage, so the check has to be disabled in debug builds or the team will learn to ignore it.

The second operational point is about mock locations. On Android you should include location.isFromMockProvider() from your location provider to complement JailMonkey.canMockLocation(). The documentation notes that most React Native location libraries already have this check built in, which means the two signals overlap and canMockLocation is not a substitute for the provider level check.

On the reasons for the module existing at all, the project states that it has been made public to help keep it up to date, and that as detection measures get better or out-dated, users should send updates to this project so it can be the best method of detection. That framing is honest about the nature of the work, and it also means the checks degrade as the attacker adapts.

What the module cannot tell you

The limitations are structural rather than bugs, and it is better to state them than to discover them.

Every check here is a heuristic. A rooted detection method that looks for a su binary, for test keys in the build properties, for read-write system paths, for a Magisk binary or for dangerous root management apps can all be evaded by a user who knows what is being checked. The module cannot tell you whether a device is genuinely trustworthy, only whether it matches a set of known signals, and the signals are public in this repository.

The Android detection detail makes the trade-off visible. The nine RootBeer checks are individually named in the type definition, so a user reading the published API knows exactly which indicators are consulted. That is good for transparency and it is also a specification for evasion. Anyone using this module for real protection should treat the result as one signal among several, including server-side checks, and should not let a passing check authorise an action that carries real value.

The location side has the same character. canMockLocation tells you the device can fake its GPS position, and detect mocked locations for phones set in developer mode, but a device that cannot mock location through the standard developer setting is not thereby a device that is telling the truth.

Licence, project structure and the maintenance picture

The package is MIT licensed, with the licence file at the root of the repository, and the description in the manifest is a React Native module for identifying jail-broken, rooted, or mock locations on iOS and Android.

Two details in the manifest tell you about the state of the project. The test script is echo Not yet, so the package ships without an automated test suite of its own, which is worth knowing if you are relying on it as a security control and want to pin a version. There is a ts-check script that runs the TypeScript declaration file through the compiler with noEmit, so the typings are at least type-checked, and the shipit script publishes through np.

The last push to the repository was on 2026-04-28, and the repository is not archived. That is more than six months before today, so treat the module as settled rather than as something receiving regular work, and read the release notes for 3.0.0 before you rely on the New Architecture path, since the architecture migration is the most recent substantive change and the kind of change that carries behavioural differences between the 2.8.5 line and 3.0.0.

Editorial conclusion

Adopt JailMonkey if you run a React Native app on both iOS and Android and need a device integrity signal, especially if you want to know which specific Android detection method fired instead of a single boolean. Do not adopt it as your only defence, since the checks are heuristics that a determined user can bypass, and remember that emulators are usually rooted, so you will need a development bypass. Before shipping, check that you are on version 3.0.0 or later for New Architecture support, since the latest release for the Old Architecture Bridge is 2.8.5, and pair canMockLocation with the isFromMockProvider check from your own location provider, which most React Native location libraries already include.

Frequently asked questions

Official sources

1. GantMan/jail-monkey on GitHub
2. Issues
3. License: MIT
4. README
5. Releases