Verify the engine and bundle path
The Hermes documentation describes React Native's bundled engine and default use. It also warns that a custom bundle-loading path can use the engine without taking advantage of the intended precompiled bytecode.
Inspect release build configuration and actual packaged assets, not only a runtime engine flag.
Separate package layers
| Layer | What inspection can reveal |
|---|---|
| Android manifest | Components, permissions and package metadata |
| Native libraries | Engine and native-module architecture payloads |
| Hermes bundle | Bytecode-level application material |
| Assets | Images and other packaged resources |
These layers do not restore the original project structure or development build configuration.
Preserve source maps for your releases
Keep the appropriate source maps and Android/native diagnostic artifacts associated with the exact build. JavaScript stack interpretation and native crash symbolization require different evidence.
Do not publish private source maps by default merely to make a crash report easier to read publicly.
Analyze only authorized artifacts
Use reverse engineering for your own app, a permitted audit or lawful interoperability work. Do not remove licensing checks or redistribute extracted proprietary assets.
A lost source repository is better recovered from backups, CI and source control than from compiled bytecode.
Use APKLint for inventory
The React Native APK Analyzer can help identify likely engine/bundle characteristics. The release guide remains the reference for producing a standalone artifact. APKLint cannot guarantee original-source recovery or prove runtime behavior from the bundle signature alone; validate conclusions against the build configuration and a controlled device test.
Distinguish the engine from the bundled application
For an authorized release review, inventory the Android manifest, ABI-specific native libraries, application bundle and packaged assets separately. The presence of a Hermes library indicates an engine component, but does not by itself establish that a custom loader executes the expected precompiled application bundle. Compare artifact evidence with the project's release configuration and a controlled runtime observation.
The Hermes integration guide explains the bundled-engine relationship and the custom-loading caveat. Keep engine and React Native compatibility aligned through the supported build. Renaming another version's bytecode or replacing a library in the final APK is not a valid compatibility strategy.
Match a JavaScript failure to its release source map
Suppose an optimized release reports an unreadable JavaScript stack. Locate the source map associated with that exact bundle and release, retaining any map composition required by the build pipeline. A map from the development server or another candidate can resolve positions incorrectly even when the visible application version is unchanged. Preserve the map-generation configuration with those artifacts to make the diagnostic procedure repeatable.
Use a controlled test exception at a known application method to verify the diagnostic workflow before relying on it during an incident. Keep native engine crashes, Android exceptions and JavaScript failures separate until their evidence connects them. Native addresses require the corresponding native symbols, while Android-renamed classes need their own mapping. If an over-the-air update system is used, retain the delivered bundle's update identity as well as the native application's version. Two users on the same native release can execute different compatible bundles, making the native version alone insufficient to choose the correct JavaScript diagnostic map.
For a lost-source investigation, report the recovered layer honestly. Extracted assets and bytecode analysis do not restore comments, original module structure, repository history or every original identifier. Prioritize authorized source-control backups and CI records, and preserve an untouched APK with its digest. Do not describe an engine signature as proof that a complete editable React Native project can be generated. The practical result of this review is a trustworthy package inventory and a tested diagnostic association for an owned release, with explicit limits on what static bytecode inspection can establish about original source or runtime behavior.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
