Hermes Compatibility Gaps for Native Modules in React Native 0.71+
0 reputation · 30 Sept 2020, 08:21 UTC
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?
