NativeKeel

NativeKeel

Health check for React Native and Expo apps. Will your app survive the next upgrade, pass the store and stay safe? One command, no install, no account:

npx nativekeel upgrade   # go/no-go for the newest React Native / Expo, with file and line

npx nativekeel # full health check: upgrade, store rules, crashes, security, accessibility

No terminal handy? Paste your package.json at nativekeel.com/check: the same dependency checks and upgrade plan, run in your browser.

Works with GitHub Actions (a quality gate comment on every pull request), [SonarQube](https://nativekeel.com/sonarqube) (findings in your existing projects and quality gate) and AI coding agents (MCP server for Claude Code, Codex and Cursor). Several apps? npx nativekeel fleet puts them on one page.

What's new in 0.1.132: turning off expo-camera's barcode scanner (expo.camera.barcode-scanner-enabled=false) to drop Google's portrait-locked scanner activity also turns off CameraView scanning on Android, so onBarcodeScanned silently never fires. NativeKeel now reports that when the app scans barcodes, and the Android 16 note leads with the fix that is safe either way (tools:remove). Recent releases added the expo-camera orientation lock to the Android 16 note, the target SDK check for managed Expo apps, a check for UIScene setups that lose the deep link that launches the app, a list of 30 libraries that still call APIs React Native removed, npx nativekeel upgrade (a go/no-go for the newest React Native / Expo), known malware anywhere in the lockfile's dependency tree, and detection of the actively exploited Metro dev-server flaw CVE-2025-11953. Every check is tuned on 1,100+ open-source React Native and Expo projects, with recently updated ones added every week, to keep false alarms out (measured accuracy). All releases →

Summary  4 critical · 4 high · 6 medium · 6 low

Security (OWASP MASVS) crypto 1 · network 1 · code 1 · 7 finding categories; not a compliance verdict

Start here

1. Revoke the AWS access key ID in src/App.js:6 at the provider today.
2. Set targetSdkVersion = 36 and compileSdkVersion = 36 in android/build.gradle.
3. Replace @react-native-community/push-notification-ios: no New Architecture support, unmaintained.

Could someone steal data or abuse the app?

npx nativekeel security . --html security.html --fail-on high

Review secrets, credential leaks, backend access rules, unsafe code execution, transport and dependency risks in one report. New flow/configuration findings show where the input enters, where it is used, what an attacker would need, and how to verify the fix. --offline keeps the scan offline and skips online advisory checks. No source code is uploaded.

Keys added at build time. An EXPO_PUBLIC_ value set in EAS or a CI secret never appears in the repository, so no source scan can see it, yet it ships in the app. NativeKeel also opens the built app and scans the JavaScript bundle inside it, plain JavaScript or Hermes bytecode: APKs and AABs under android/app/build/outputs, eas build --local results, committed bundles, and any APK, AAB or IPA you pass with --artifact app.apk (the GitHub Action's artifact input, after your build step).

This is source analysis, not a live attack or a security certificate. Security checks and scope · Mobile flow details · Native Android details.

What it checks

Upgrade

• Is your React Native / Expo version still supported? React Native supports the latest three minors; in Expo projects React Native moves with the SDK.
• Can you upgrade at all? The legacy architecture was removed in 0.82. If the New Architecture is off (it is off by default before 0.76), you are stuck at 0.81.
• Which packages block the upgrade? Native modules without New Architecture support (cross-checked with the package's own codegen spec), unmaintained or with no release in years, with verified alternatives and renamed packages. Library versions for each step come from the libraries' own compatibility tables.
• Which packages might be unused? Installed packages with no import, native reference, requirement or patch found. Listed for review, not automatic removal: dynamic and generated usage can hide from a static scan.

Store

• Will Google Play and the App Store accept your next build? targetSdk, permissions Google Play restricts (photo/video, all files, background location, app installs, SMS), 16 KB memory pages (it also opens your built APK/AAB and checks every native library), the iOS privacy manifest and SDKs too old to have one, missing Info.plist usage descriptions, sign-up without account deletion, social login without Sign in with Apple, and release builds signed with the debug key.

Crashes

• Will it crash at runtime? packages off the versions your Expo SDK expects, release builds that still point at a development server, native libraries that need a newer React Native, Reanimated without its Babel plugin or react-native-worklets, mixed @react-native-firebase/* or @react-navigation/* majors, a second copy of React or React Native inside a dependency, Kotlin modules that cannot load through the New Architecture interop layer, AppDelegate setups that crash in Release, camera/photos/location access without the Info.plist text iOS requires, imports of APIs removed from React Native core (AsyncStorage, Picker, ViewPropTypes, …) or deprecated for removal (ImageBackground, SafeAreaView), and traps learned from real upgrades.

Security, grouped by OWASP MASVS

• Secrets in the app or the repo: AWS, Stripe, OpenAI, Anthropic, GitHub, Slack, SendGrid, Twilio, Shopify, Google OAuth and Supabase service_role keys, private keys, .env values compiled into the bundle, Expo extra/EXPO_PUBLIC_/eas.json secrets, signing keys and passwords.
• Data on the device: iOS file sharing (UIFileSharingEnabled) that exposes an unencrypted MMKV, expo-sqlite or Realm database (they live in Documents by default on iOS), passwords that flow into crash reports, analytics, databases or plain AsyncStorage (followed through variables), auth tokens in unencrypted storage, Android backups that copy them.
• Network: TLS certificate checks turned off in native code, cleartext HTTP, NSAllowsArbitraryLoads, plain-HTTP API calls, user-installed CAs in release.
• Backend rules: Firebase Realtime Database, Firestore and Storage rules open to anyone or in test mode; Supabase tables created without row level security; sign-in-only Firebase write rules and unconditional Supabase UPDATE/DELETE policies without row ownership checks. Policy findings include file/line evidence and explain deployment/grant assumptions.
• Authentication: biometric prompts (Face ID, Touch ID, fingerprint) whose success is only a yes/no in JavaScript, with no secret bound to biometrics in the keychain/keystore, in JS or native code: the prompt guards the screen, not the data.
• Cryptography: hardcoded encryption keys, MD5/SHA-1 on passwords, ECB mode, Math.random for nonces and salts.
• Platform: WebViews that read local files or load HTTP into HTTPS, Android components any app can start, unverified deep links and the template myapp:// URL scheme.
• Dependencies and reverse engineering: known vulnerabilities in the exact versions you ship (GitHub Advisory Database), source maps in the app, Hermes or R8 off.

These are static checks: they catch the common, detectable mistakes, not everything a penetration test of the running app and backend would.

Performance

• What is your release bundle actually made of? npx nativekeel bundle reads the source map a release build already wrote (Android: android/app/build/generated/sourcemaps/react/release/, Expo: npx expo export --dump-sourcemap) and measures how much of the shipped code is your app and each package, and which packages are bundled twice. --base old.map compares two builds: what was added, removed or grew. Nothing is built or run; the normal scan picks the map up too.
• Where should you investigate performance? Nested list patterns, JavaScript animation settings, source logging calls, root lodash/moment imports, referenced images over 500 KB, JSON over 300 KB imported into the JavaScript bundle (every language's translations, Lottie animations), and selector allocation patterns. Confirm the actual components, release output and runtime behavior before changing them; these checks do not measure frame rate, startup time or savings.

Accessibility

• Can everyone use it? Icon-only buttons with no accessibility label (VoiceOver and TalkBack say just "button"), buttons smaller than 44×44 with no hitSlop, text and placeholders whose color and background (both set in the code) fall below WCAG contrast, text fields with no label or placeholder, and text scaling turned off for the whole app. Text.defaultProps is flagged too: React 19 (React Native 0.78+) ignores it in JSX, so app-wide fonts and font-scaling limits silently stop applying. Only React Native's own touchables and inputs are checked; custom components, focus order and color contrast still need a test with a screen reader.

App improvement review

npx nativekeel improve /path/to/app --offline

npx nativekeel improve /path/to/app --offline --out IMPROVE.md

Existing security, stability, performance, store and dependency findings become an ordered plan with reasons, applicability conditions, actions, verification and recovery. Exposed credentials get containment instructions. Apparently unused dependencies are review candidates: direct, transitive, dynamic, native and generated consumers must be considered before removal. Performance signals are not measurements.

Use --json for structured output or MCP improve_app. Malware findings block execution-dependent actions. Unknown runtime, backend, accessibility and reliability coverage stays explicit. This adds a decision layer over existing checks, not new vulnerability detectors. See scope and next modules.

Usage

npx nativekeel [path]              # report

npx nativekeel plan --out UPGRADE.md # step-by-step upgrade plan npx nativekeel --html report.html # shareable HTML report npx nativekeel --markdown pr.md # summary for a pull request comment npx nativekeel --sarif nk.sarif #