React Native 0.64 with Hermes for iOS

Shun describes Hermes as a JavaScript engine designed for React Native, with a focus on time to interactive, app size, and memory use. Facebook measurements cited in the episode show startup time and APK size roughly halved, with memory use reduced by about one-third to one-quarter.

Hermes compiles JavaScript into optimized bytecode during the app build, so the device can load it without parsing and compiling the source at startup. Shun explains that AOT describes when compilation happens, not whether the output is native machine code. He says React Native’s bundled code and interaction-driven workload make this approach useful: many functions run only once or not at all during startup.

Shun says Hermes is still adding JavaScript features and improving garbage collection, memory use, and tooling. He describes work on shorter GC pauses, 32-bit values with pointer compression, and inline storage for small arrays. The guests also discuss community blockers: proxy support became the default in React Native 0.64, while Android internationalization support was planned for 0.65.

Alloy explains that Microsoft wanted a shared, adaptable engine for React Native across platforms, with consistent debugging and tooling. He says Hermes lets Microsoft address React Native-specific needs, including debugging around synchronous native calls. The discussion also notes that Hermes may improve startup and memory behavior on iOS, while JavaScriptCore can remain a better fit for apps prioritizing current app size.

Alloy argues that Hermes avoids the JIT behavior Apple has restricted: compiling code to native machine code in memory and marking it executable. The episode presents Hermes support for iOS and macOS as available work, while treating future default adoption across platforms as uncertain. Mike points listeners to an accompanying article for implementation details and setup.