Hermes Compatibility Gaps for Native Modules in React Native 0.71+

Question

React Native 0.71+ made Hermes the default JavaScript engine, compiling JS to bytecode ahead-of-time for smaller bundles and faster startup.

For a low-traffic mobile workload, the goal is to keep Hermes enabled to benefit from reduced CPU, memory, and startup overhead, while still relying on third-party native modules that were originally written against JavaScriptCore.

The uncertainty is that some modules depend on JSC-specific globals or behaviors, such as certain WebSocket implementations or cryptographic utilities, and may fail or behave differently under Hermes. No comprehensive official compatibility matrix for community packages has been published, so the risk per module is unclear.

Given this boundary, a maintainer must choose between keeping Hermes fully enabled, disabling it, or gating it per platform or per module.

Which categories of native modules are known to break under Hermes, and is there an authoritative compatibility list? Is conditional per-platform Hermes enablement a supported configuration? What is the recommended way to detect JSC-dependent modules before migrating?

Siddharth · Answer

ResolutionThere is no official, centralized compatibility matrix for Hermes with community native modules. Modules that typically break are those that depend on JavaScriptCore‑specific internals or non‑standard JavaScript behaviors.Likely failure categoriesModules that call JavaScriptCore C++ APIs directly (bypassing JSI).Modules that rely on the full Intl API when Hermes is built without ICU data.Modules using complex or edge‑case regular expressions that differ between Hermes and JSC regex engines.Modules that depend on subtle JSC semantics such as Function.prototype.toString output, floating‑point rounding, or garbage‑collection timing.Per‑platform enablementHermes is a build‑time flag; you can set it differently for Android and iOS but not per module.Android: edit android/gradle.properties and set hermesEnabled=true or false.iOS: edit the Podfile and set :hermes_enabled => true (or false) then run pod install.Detection workflowFlag dependencies that perform cryptography, networking (WebSocket polyfills), or heavy string/date/intl work.Confirm the active engine at runtime:const isHermes = () => !!global.HermesInternal;
console.log('Hermes active:', isHermes());
Run your integration test suite on a staging build with Hermes enabled. Prioritize manual verification of the flagged modules.Search each library’s issue tracker for the term \"Hermes\" to see reported gaps.If a module fails, the only supported workaround is to disable Hermes for the entire platform (or fork/patch the module). Per‑module gating is not possible.

Hermes Compatibility Gaps for Native Modules in React Native 0.71+

React Native 0.71+ made Hermes the default JavaScript engine, compiling JS to bytecode ahead-of-time for smaller bundles and faster startup.

1 answer

Resolution

Likely failure categories

Per‑platform enablement

Detection workflow

Your perspective belongs here.

0 question comments