[0.88] Hermes: JSI implementation batch backported to 260318099.0.0-stable (landed)

[fabriziocucci]

Target Branch

0.88

Link to commit or PR to be picked

• Backport new JSI improvements  facebook/hermes#1988 (the source backport, 10 of its commits)

Description

Bookkeeping record. All 10 commits have already landed on 260318099.0.0-stable, so there is nothing to action here. Filing it so the 0.88 pick list reflects the work, and so the remaining release-side blocker is written down somewhere.

The gap

RN 0.88 moved to Hermes 260318099, whose stable branch was cut from static_h around 2026-03-18. facebook/hermes#1988 ("Backport new JSI improvements", 21 commits from static_h) landed on the 250829098 branch (used by RN 0.87) on 2026-04-15, after that cut.

The 260318099 branch received only half of it. The JSI declarations ("Add X API") crossed over, the Hermes implementations ("Implement X") and their SynthTrace support did not. The JSI surface in API/jsi/jsi/jsi.h was byte-identical between the two branches, so nothing failed to compile and nothing raised an error. Every affected API silently fell through to the jsi base implementation.

This was found through tryGetMutableBuffer, where expo-modules-core's Android instrumentation tests caught the zero-copy regression on 0.88.0-rc.0 (expo/expo#49910). The other five APIs had the same defect and were latent.

Where each commit landed

#	Source (250829098.0.0-stable)	API	Landed on 260318099.0.0-stable
1	d44b213d74f	Array.push impl	9841318e1
2	f5ce8f0e586	Array.push SynthTrace	2daaa8aa8
3	9a50bd0f364	tryGetMutableBuffer impl	ccb4fb5bd (via facebook/hermes#2179)
4	5d5c9334bec	getMutableBuffer SynthTrace	41ed32d43
5	93eee4c7e4c	ArrayBuffer.detached impl	fd3724fb1
6	1aea879f113	createUInt8Array impl	7b15bccd7
7	9d28826712c	createUInt8Array, TypedArray::buffer SynthTrace	c926dd7a1
8	5b31237bf83	Error creation impl	5d1e7237d
9	e6268f9dee7	Error creation SynthTrace	1b374ae69
10	5a7f83aa3a1	String::length impl	7e5dfcd59

Nine landed as Graft "[SH] ..." to shermes/stable. Number 3 landed through facebook/hermes#2179.

Verified by content rather than by commit subject. Every HermesRuntimeImpl method (push, tryGetMutableBuffer, detached, createUint8Array, isTypedArray, createError, createRangeError, createSyntaxError, length) is now present in API/hermes/hermes.cpp on the 0.88 branch, and API/hermes/TracingRuntime.cpp matches the 0.87 branch exactly (4 / 1 / 2 occurrences of createUint8Array / tryGetMutableBuffer / createError, against 0 / 0 / 0 before).

Still outstanding, and this is the part that affects the release

There is no 260318099.0.3 tag. Tags stop at hermes-v260318099.0.2, and RN 0.88-stable pins 260318099.0.2 in packages/react-native/sdks/hermes-engine/version.properties and packages/react-native/package.json. None of the work above reaches the release until a new tag is cut and RN is bumped to it.

Three separate things are waiting on that tag:

1. This batch of 10 commits.
2. The back-out of the VariableScope rescan pick ([260318099.0.0-stable] pick: Avoid unnecessary rescans of VariableScopes facebook/hermes#2149). hermes-v260318099.0.2 was tagged at 2026-09-08 03:05 PDT and the back-out landed at 11:18 PDT the same day, so .0.2 still carries the change that was reverted for causing SIGSEGV crashes in Messenger Android (D118959426).
3. xplat/static_h still carries that same change (maybeDeadVariableScopes_ is still present in lib/IR/IR.cpp on static_h). The back-out called this out as a follow-up that was not included, since static_h is the source the next stable sync pulls from.

Closing as landed.

[github-actions]

Thank you for opening a new React Native Pick Request.

These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).

If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.

✅ Which Pick Requests we accept

1. ✅ Fixes for regressions to core APIs. Examples:
   • A core component is behaving differently between versions 0.X and 0.X-1
   • The TurboModule.getEnforcing function is throwing an unexpected assertion error.
2. ✅ Fixes to bugs in core React Native. Examples:
   • Breakpoints in React Native DevTools not working correctly in the debugger
   • Fast Refresh not working as expected
   • Metro bundler not starting properly or ignoring the configuration file
   • Buttons that are not clickable
3. ✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
   • An API used by react-native-macos is not behaving as expected or is regressing
4. ✅ Bump of patch version of dependencies. Example:
   • Bump Gradle from 8.11.0 to 8.11.1
5. ✅ Fixes for low/high severity security vulnerabilities. Example:
   • Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and no 8.11.x version contains the same fix.
6. ✅ Fixes and reverts of accidental breaking changes. Example:
   • Reverting or fix-forwarding a Kotlin migration of a file (e.g. ReactRootView.java) if it is causing a breaking change for the React Native ecosystem.
7. ✅ Performance improvements. Examples:
   • Fixing unnecessary re-renders in FlatList.
8. ✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)

❌ Which Pick Requests we don't accept

9. ❌ Any Pick Request that introduces a breaking change after RC1. Example:
   • A bugfix that contains a refactoring, resulting in changes to the public API of a class
10. ❌ Any Pick Request that introduces a new feature after RC1. Example:
    • A commit that introduces a new API or a specific feature for a component.
11. ❌ Bump of major or minor version of dependencies. Examples:
    • Bump Gradle from 8.11.0 to 8.12.0
    • Bump Gradle from 8.11.0 to 9.0.0
12. ❌ Bump of a dependency to a pre-release version. Example:
    • Bump Gradle from 8.11.0 to 8.11.1-beta.1
13. ❌ Any Pick Request that introduces changes to the React Native testing infrastructure after RC1. Examples:
    • Changes to GitHub Actions workflows to optimize them, even if they are on main.
    • Changes to the logic used to publish packages to NPM or Maven Central
14. ❌ Pick Request composed of multiple commits that have several merge conflicts.
    • If your Pick Request is too complex to apply to the release branch, it will be rejected.
15. ❌ Any non-critical improvement that landed on main.
    • These will generally ship in the following version unless they fit one of the criteria above.
16. ❌ Any Pick Request considered a "nice to have".
    • Even one-line changes carry a risk of destabilizing and further delaying the release.

ℹ️ What makes for a good Pick Request

In order for your Pick Request to be considered, please do the following:

• ℹ️ Limit your Pick Request to one commit from main, or one PR against the release branch.
• ℹ️ Include a clear explanation of why your Pick Request should be considered, ideally referencing one of the criteria above.
• ℹ️ Target only one minor version of React Native (e.g. [0.76]). To have your Pick Request applied to more versions, please open separate Pick Requests.