Hermes vs JSC in React Native: stop arguing, here's when each wins
Hermes has been the default JavaScript engine in React Native since 0.70 (Android) and 0.71 (iOS). It compiles JS to bytecode ahead of time, starts faster, uses less memory, and produces smaller binaries.
JSC still ships as an option. The reasons people kept it — Intl support, debugging tooling, steady-state perf — have mostly been addressed in current Hermes.
If you're starting a new app, use Hermes. If you're on JSC for legacy reasons, switching is usually a one-line config change. Test, ship, move on.
The Hermes vs JSC question used to be interesting. In 2026 it mostly isn't. Hermes won. The remaining edge cases are real but narrow.
This post is what each engine actually is, what the benchmarks actually say, and the short list of situations where JSC still makes sense.
What Hermes and JSC actually are
JSC is JavaScriptCore — Apple's JavaScript engine, the one that powers Safari. It's been the React Native default on iOS forever, and on Android it shipped as a port of the same engine. It's a mature, general-purpose engine. It has a JIT compiler. It's optimized for the kind of workloads web browsers see.
Hermes is a different animal. Meta built it specifically for React Native. It doesn't JIT. Instead, it compiles JavaScript to bytecode during the build, ships the bytecode in the app bundle, and runs that bytecode directly at startup. No parse step, no compile step, no warmup.
The architectural difference matters. JSC was designed for "load a page, run JS, throw it away." Hermes was designed for "ship an app, run the same JS on cold start a thousand times, every millisecond counts."
The default has changed
Hermes flipped to default-on for Android in React Native 0.70 (September 2022). It flipped to default-on for iOS in 0.71 (January 2023). Anyone starting a project after early 2023 has been on Hermes from day one unless they explicitly turned it off.
Apps that predate those versions and have never been actively migrated are usually still on JSC. The flag was opt-in then; nobody flipped it.
If you're not sure which engine your app uses, check:
- Android:
hermesEnabledinandroid/gradle.properties - iOS:
:hermes_enabled => truein theuse_react_native!block ofios/Podfile - Or open Flipper / React Native DevTools and check the "JS Engine" field
What Hermes wins on
Five categories where Hermes is the better choice.
Cold start
This is the headline. Bytecode loads faster than parsing JavaScript. On Android, Meta reported a roughly 50% reduction in time-to-interactive when they shipped Hermes; real-world numbers vary, but a 30–50% cold-start improvement on Android is consistent across teams that switch.
On iOS the gap is smaller — JSC on iOS gets to use Apple's tightly optimized engine — but Hermes still wins by 10–25% in typical apps.
Binary size
Hermes bytecode is more compact than text JavaScript. The Hermes runtime is also smaller than JSC on Android, where the JSC port adds a meaningful amount of native code.
Typical wins: 20–40% smaller release APK, 10–20% smaller iOS app. The exact number depends on bundle size and how much of your code path the engine touches.
Memory
Hermes uses less RAM than JSC, particularly during cold start. The bytecode is memory-mapped from disk instead of parsed into a JIT cache. Steady-state memory is also lower in most cases.
On low-end Android devices, this is the difference between an app that runs and an app that gets killed by the OS. If your audience includes phones with 3GB of RAM, this matters.
Debugging
The React Native debugger and DevTools integration with Hermes is first-class. You get inspector, breakpoints, profiler, and heap snapshots without configuring anything.
JSC debugging in React Native exists but is more fragile. Tooling has consistently improved for Hermes and stagnated for JSC.
It's the supported path
New Architecture, Bridgeless, React Native DevTools — every new piece of the framework is developed and tested with Hermes first. JSC works, but it's a second-class path. Bug reports filed against "JSC + new feature X" get fewer eyeballs.
What JSC still wins on (and what it doesn't anymore)
The historical reasons people kept JSC:
| Concern | JSC's edge then | Status in 2026 |
|---|---|---|
| Intl API | Hermes didn't ship Intl | Hermes has Intl. Has since RN 0.71 on Android, 0.73 on iOS. |
| Long-running JS perf | JIT-compiled JSC outperformed Hermes on tight CPU loops | Still true on synthetic benchmarks. Rarely true on real apps. |
| Library compatibility | A handful of libraries used JSC-only features | Almost all popular libraries now support Hermes. |
| Debugger tooling | Some legacy tooling required JSC | Reversed. Hermes tooling is now better. |
| BigInt, certain regex flags | Hermes lagged on language features | Hermes ships current ES features. Check the docs for your version. |
The one genuine remaining win for JSC: tight, long-running CPU loops in JavaScript. If your app runs a parser, a custom interpreter, a chess engine, a video filter implemented in JS — anything that spends seconds at a time hot in the JS thread — JSC's JIT can still beat Hermes by a meaningful margin.
Most React Native apps don't have that workload. They have UI code that calls into native and waits. The bottleneck is the native call, not the JS execution. Hermes is fine.
If you think your app might benefit from JSC, measure on your actual workload before switching. The number of teams that have switched back to JSC based on real data is small. The number that switched based on a benchmark someone wrote in 2021 is larger.
How to switch
The change is a build flag. The work is testing afterward.
Android:
iOS:
Then:
What to test after:
- Cold start time. Cold-launch the app on a real device, time it. Should be faster on Hermes; if it's slower, something else is going on.
- Any library that does locale-sensitive formatting (Intl). Confirm it still works correctly.
- Any library that uses workers, eval, or dynamic code generation. These are the historical break points.
- Crashlytics or Sentry for the first week. Hermes-specific crashes look different from JSC-specific ones; learn what the new noise floor is.
Measuring before you decide
If your app is large enough that the engine choice might matter, measure rather than argue.
The metrics that matter:
- Time to interactive (TTI). Cold launch to the screen the user can use. Hermes usually wins.
- Peak memory. RAM consumed during heaviest screen. Hermes usually wins.
- Steady-state CPU. Time spent in JS execution during a representative user session. JSC sometimes wins.
- Crash-free sessions. Stability under real load. Should be roughly equivalent; differences are usually library bugs, not engine bugs.
- Binary size. Release APK and IPA size. Hermes usually wins.
Run the test on a representative low-end device. The high-end Pixel and the latest iPhone will hide differences that real users will feel.
Upgrading and unsure about engines?
Engine choice usually rides on a React Native upgrade — the version you target dictates which Hermes features are available, and what your dependencies expect. Run the free scanner against your lockfile to see how the dependency graph lines up before you flip the flag.
Frequently Asked Questions
What is Hermes in React Native?
Hermes is a JavaScript engine built by Meta specifically for React Native. It compiles JavaScript to bytecode ahead of time, which means apps don't have to parse and compile JS on every cold start. It uses less memory than JavaScriptCore (JSC), produces smaller APKs on Android, and integrates with the React Native debugger out of the box. It's been the default engine since React Native 0.70 on Android and 0.71 on iOS.
Is Hermes faster than JSC?
For cold start, yes — typically 30–50% faster on Android, less dramatic on iOS. For steady-state JavaScript execution, the picture is more mixed. JSC has a more mature optimizing compiler and can outperform Hermes on long-running, CPU-heavy JavaScript. But most React Native apps aren't CPU-bound in JS — they're bound by native UI work, network calls, or rendering. The cold-start win matters more in practice than the steady-state gap.
When should I use JSC instead of Hermes?
Almost never in 2026. The cases that used to favor JSC — Intl API support, certain regex features, debugging tooling — have largely been addressed in current Hermes versions. The remaining edge cases are apps with a specific library that depends on a JSC-only behavior (rare), or teams that have validated a measurable steady-state performance advantage on their workload. For everyone else, Hermes is the default and should stay the default.
Does Hermes support the Intl API?
Yes, in current versions. Earlier Hermes didn't ship Intl, which broke libraries that used Intl.NumberFormat, Intl.DateTimeFormat, and similar APIs. Hermes added Intl support and it's been stable since React Native 0.71 on Android and 0.73 on iOS. If you saw an Intl-shaped error on an old project, the fix is usually upgrading React Native, not switching to JSC.
How do I switch between Hermes and JSC in React Native?
Android: set hermesEnabled=true (or false) in android/gradle.properties. iOS: set :hermes_enabled => true (or false) in the use_react_native! block in ios/Podfile, then run pod install. Clear builds, reinstall, and test. The switch is a build-time flag, not a runtime decision — every install of your app uses one or the other, not both.
Does the New Architecture require Hermes?
Technically no — the New Architecture works with JSC. Practically, you should use Hermes. The combination of New Architecture plus JSC is the least-tested path in the React Native ecosystem. Bug reports against that combination get less attention. If you're on the New Architecture, run Hermes; that's the supported configuration.