Hermes in 2026: What It Does and How to Profile with It

Most React Native developers never think about the JavaScript engine running their app, and that's mostly a compliment to Hermes. It's been the default for years, it quietly makes apps start faster and use less memory, and since React Native 0.84 its newest version, Hermes V1, is the default too.

It's still worth understanding, because Hermes is also your best tool for finding out why a screen is slow. This guide explains what Hermes does in React Native, what changed with Hermes V1, how it compares with JavaScriptCore, and how to profile CPU and memory with it.

Key takeaways

• Hermes is the JavaScript engine built for React Native. It compiles JavaScript to bytecode at build time, so devices skip parsing and compiling at startup.
• Hermes V1 has been the default since React Native 0.84 (February 2026), after being an experimental opt-in in 0.82. Apps already on Hermes get it automatically.
• Benefits: faster startup, lower memory use and smaller downloads compared with shipping plain JavaScript to a runtime compiler.
• Profile with React Native DevTools, which connects to Hermes for CPU profiles and memory snapshots.
• On Expo SDK 56, watch for a known Hermes V1 memory regression with Reanimated and Worklets, fixed in SDK 57.

What Hermes actually does

Traditional JavaScript engines receive source code at runtime, parse it, and compile hot paths while the app runs. That's flexible but costs time and memory exactly when your app is starting.

Hermes moves that work to build time:

1. Ahead-of-time compilation. Your bundle is compiled to Hermes bytecode when you build the app.
2. Fast loading. On launch, the engine maps the bytecode and starts executing, without a parse and compile phase.
3. Memory-conscious garbage collection. Hermes's garbage collector is designed for mobile devices, with shorter pauses.

The result is most noticeable on mid-range and older Android phones, where CPU time at startup is precious.

Hermes V1

React Native 0.82 introduced Hermes V1 as an experimental option, and 0.84 made it the default engine on iOS and Android. If your app already used Hermes, you get V1 automatically when you upgrade; React Native provides build flags to fall back to the older compiler if you hit a problem.

In Expo, SDK 56 made Hermes V1 the default and documented a known memory regression: importing Reanimated or Worklets could increase memory use significantly. The fix shipped in SDK 57, and SDK 56 lets you opt out with the useHermesV1 option in expo-build-properties if you need to stay on 56 for a while.

Hermes vs JavaScriptCore

Unless a library or feature specifically requires JSC, stay on Hermes. It's the engine the React Native team builds, tests and benchmarks against, so it gets fixes and improvements first.

Profiling with Hermes and React Native DevTools

React Native DevTools (open it from the dev menu or by pressing j in the Metro terminal) connects to Hermes and gives you:

• A performance profiler for recording CPU usage while you reproduce a slow interaction. Look for long JavaScript tasks and which functions dominate them.
• A memory panel for heap snapshots. Take one, use the app, take another, and compare to find objects that keep growing, such as listeners or cached data that never get released.
• The React components and profiler tabs, to see which components render, how often and how long they take.

A practical profiling loop:

1. Reproduce the slow interaction in a build that's as close to release as possible.
2. Record a CPU profile while you do it.
3. Find the longest task and the function at its heart.
4. Fix one thing, rebuild, and record again to confirm.

Remember that development builds include extra checks and dev-only warnings, so absolute timings are noticeably higher than in production, sometimes by a wide margin on low-end Android devices. Use them to find hot spots, then confirm improvements in a release build.

From the field: Hermes was one of three levers, with image optimisation and cache-first fetching, that cut load time by about 60% (3.8 seconds to 1.5) across the eight apps I migrated to the New Architecture. Once Hermes is in place, profiling is how you find where the remaining time goes.

Common Hermes questions in practice

• Intl and date formatting: Hermes includes Intl support on both platforms, so locale-aware formatting works without polyfills on current versions.
• Debugging: use React Native DevTools; the old remote debugging in a browser and Flipper are no longer the recommended path.
• Source maps: upload them to your crash reporter for each release, so production stack traces from Hermes bytecode are readable.
• Bundle size: every module you import still has to be loaded at some point, so removing unused dependencies helps Hermes as much as any engine setting.

Checking, enabling and disabling Hermes

Hermes is the default engine in React Native and Expo, so on a current project there's nothing to enable. To confirm it at runtime:

const usingHermes = Boolean((global as { HermesInternal?: unknown }).HermesInternal);

Opting out is still possible: React Native supports JavaScriptCore through a community-maintained package, following the instructions in the react-native-community/javascriptcore repository. It's rarely worth it. JavaScriptCore loses Hermes's precompiled bytecode, which is most of the startup benefit, and new React Native work assumes Hermes.

One misconception worth correcting: Hermes bytecode is not protection for your code. Open-source tools can disassemble and partly decompile .hbc files, so treat everything in the bundle as readable, exactly as you would a JavaScript file.

FAQ

What is Hermes in React Native?

Hermes is a JavaScript engine designed for React Native. It compiles your JavaScript to bytecode when you build the app, so devices don't parse and compile it at startup, which improves launch time and memory use. It's React Native's default engine.

Is Hermes V1 the default in React Native?

Yes. Hermes V1 became the default engine in React Native 0.84, released in February 2026, after an experimental opt-in in 0.82. Apps already using Hermes switch to V1 automatically when they upgrade, with build flags available to fall back if needed.

Should I use Hermes or JavaScriptCore?

Hermes, in almost every case. It starts faster, uses less memory and is the engine React Native is built and tested around. JavaScriptCore has moved to a community-maintained package and is only worth considering for specific compatibility needs.

How do I profile a React Native app with Hermes?

Open React Native DevTools from the dev menu, record a performance profile while reproducing the slow interaction, and inspect the longest tasks. Use memory snapshots to find leaks, then confirm any improvement in a release build.

Next steps

If you've got a screen that's slow and a profiler you're not sure how to read, I can profile it with you and fix the biggest bottlenecks. Get in touch, or see how I work as a React Native developer.

Sources

• Using Hermes, React Native docs
• React Native 0.84: Hermes V1 by default, React Native blog
• React Native DevTools, React Native docs
• Expo SDK 56, Expo