[Due for payment 2026-04-30] [$250] Enable Hermes V1

[roryabraham]

Proposal: Enable Hermes V1

Background

Hermes V1 is the next evolution of the Hermes JS engine that powers our iOS and Android apps, providing performance improvements such as just-in-time (JIT) compilation and JS-to-native compilation (formerly referred to as "Static Hermes"). Meta tested it against several popular JS benchmarks and saw significant performance improvements across the board. They also benchmarked it in the Expensify app (in October, 2025) and found that it reduced:

• total TTI by 2.7%
• bundle time by 8.9%
• content TTI by 7.6%

(Screenshots taken from the React Conf 2025 React Native Keynote)

Problem

When users open the iOS or Android apps, if the P90 case takes >5s (current threshold for ManualAppStartup metric), then they are less likely to perceive the app as responsive, which reduces the likelihood that they will continue to use it.

Solution

Enable Hermes V1 - reduce total TTI by ~2.7%. This should reduce our P90 by ~20-30ms on iOS and ~50-60ms on Android, and generally make JS runtime performance measurably better across the board.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039094191608682813
• Upwork Job ID: 2039094191608682813
• Last Price Increase: 2026-03-31

Issue Owner

Current Issue Owner: @mananjadhav

[MelvinBot]

Proposal

What is the root cause of that problem?

The app currently runs on Hermes v0.14.0 (legacy Hermes) bundled with React Native 0.83.1. Hermes V1 is available as an experimental opt-in on RN 0.83 but is not enabled — no hermesV1Enabled or RCT_HERMES_V1_ENABLED flags are set anywhere in the codebase. The performance improvements described in this issue (TTI, bundle time, content TTI) require switching to the Hermes V1 runtime.

Important clarification: The issue description mentions "JIT compilation" and "JS-to-native compilation (formerly Static Hermes)." However, Hermes V1 in its current form does not include JIT or JS-to-native compilation — those features are still under development. The improvements in Hermes V1 come from compiler and VM enhancements alone, which still yield the benchmarked improvements cited in the issue.

What changes do you think we should make in order to solve the problem?

There are two viable paths. Option B (upgrade to RN 0.84) is recommended as the simpler and more stable approach:

Option A — Enable Hermes V1 on RN 0.83 (experimental opt-in):

1. Override hermes-compiler in package.json — Add "hermes-compiler": "250829098.0.4" to the overrides section (the V1 compiler version is already referenced in node_modules/react-native/sdks/.hermesv1version)
2. Android: Add hermesV1Enabled=true to android/gradle.properties (below the existing hermesEnabled=true on line 45)
3. Android: Enable build-from-source — Change patchedArtifacts.forceBuildFromSource=true in android/gradle.properties (line 65), OR rebuild the prebuilt artifacts pipeline to produce Hermes V1-compatible binaries. Legacy Hermes and V1 binaries are NOT interchangeable
4. iOS: Set RCT_HERMES_V1_ENABLED=1 during pod install in CI/CD pipelines. Ensure RCT_USE_PREBUILT_RNCORE is not set
5. Verify/port 6 custom Hermes patches — The app has patches modifying Hermes internals that must be checked against V1:
   • Patch 024: 150MB initial heap size increase (HermesInstance.cpp)
   • Patch 025: Force allocInOldGenBeforeTTI=true to skip young-gen GC before TTI (HermesInstance.cpp)
   • Patch 026: Strip ~13.4MB debug metadata from production iOS bytecode (react-native-xcode.sh)
   • Patches 031/032: Sampling profiler crash fixes (may already be fixed upstream in V1)

Option B — Upgrade to RN 0.84 (recommended):

React Native 0.84 (released February 2026) makes Hermes V1 the default engine with no opt-in flags needed. The same 6 Hermes patches would need verification, but the RN 0.83→0.84 upgrade is described as having no user-facing breaking changes beyond requiring Node.js 22.11+. All 32+ react-native patches would need to be ported/verified regardless.

What alternative solutions did you explore? (Optional)

• Staying on legacy Hermes and tuning GC patches instead: The app already has aggressive GC tuning (patches 024/025), so further gains from GC alone are limited. Hermes V1's improvements come from the compiler and VM level, which these patches don't touch.
• Waiting for Static Hermes / JIT: These features are still in development with no firm release date. The current Hermes V1 improvements are worthwhile on their own.

Key Risks

• The prebuilt artifacts pipeline (patchedArtifacts system in PatchedArtifactsSettings.gradle and settings.gradle) would need to be updated to produce V1-compatible binaries, or all Android builds must switch to building from source (significantly slower CI)
• The Mobile-Expensify (HybridApp) build pipeline would also need corresponding changes
• Source maps and Sentry debugging workflow may be affected since Hermes V1 uses a different bytecode format

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022039094191608682813

[trasnake87]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The app's startup time (TTI) on mobile is too slow at the P90 level, hurting user perception of responsiveness. Hermes V1, which ships improved compiler and VM internals, can reduce TTI by ~2.7% but is not currently enabled.

What is the root cause of that problem?

On the iOS side, the ios/Podfile does not set ENV['RCT_HERMES_V1_ENABLED'] before calling use_react_native!. This means setup_hermes! in jsengine.rb reads the legacy .hermesversion file (resolving to hermes-v0.14.0) instead of .hermesv1version (resolving to hermes-v250829098.0.4), and set_gcc_preprocessor_definition_for_React_hermes in utils.rb never adds the HERMES_V1_ENABLED=1 preprocessor definition. As a result, the iOS build always links the legacy Hermes v0.14.0 engine.

What changes do you think we should make in order to solve the problem?

We should set ENV['RCT_HERMES_V1_ENABLED'] in ios/Podfile before the use_react_native! call so that CocoaPods resolves the Hermes V1 engine and compiler for iOS builds:

# ios/Podfile — add this line before use_react_native! (before line 91)
ENV['RCT_HERMES_V1_ENABLED'] = '1'

# ENV Variable enables/disables TurboModules
ENV['RCT_NEW_ARCH_ENABLED'] = '1';

use_react_native!(
  :path => config[:reactNativePath],
  :app_path => "#{Pod::Config.instance.installation_root}/.."
)

This single environment variable change triggers the full Hermes V1 chain on iOS: jsengine.rb will read .hermesv1version to pull the V1 engine pod, the podspec will resolve the matching hermes-compiler V1 binary for hermesc, and utils.rb will add HERMES_V1_ENABLED=1 to the preprocessor definitions for debug builds. After making this change, we should run npx pod-install to regenerate the Pods with the V1 engine and verify the app builds and starts correctly on a device.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656