[0.88] Revert RCTArrayBuffer ObjC TurboModule type change (breaking in a non-breaking release)

[fabriziocucci]

Target Branch

0.88

Link to commit or PR to be picked

Reverts, both on 0.88-stable:

• RCTArrayBuffer zero-copy class for ObjC TM react/react-native#57879 (11f9a7f4491) — RCTArrayBuffer zero-copy class for ObjC TM
• Use NSData for the JS->ObjC ArrayBuffer argument path react/react-native#57596 (5e86c323cef) — Use NSData for the JS->ObjC ArrayBuffer argument path

Description

0.88 is a non-breaking release. #57879 is a confirmed breaking change to the ObjC TurboModule surface and must not ship in it.

The breaking change

Codegen emits a different ObjC type for TurboModule methods taking or returning an ArrayBuffer. Modules that adopted ObjC ArrayBuffer support in 0.87 stop compiling until they update. It is already documented in the 0.88.0-rc.0 changelog under Breaking.

Why two reverts and not one

The type moved twice inside 0.88, so reverting #57879 alone does not restore 0.87:

Point	Argument type	Return type
0.87-stable	NSMutableData *	NSMutableData *
after #57596 (0.88 only)	NSMutableData *	NSData *
after #57879 (0.88 only)	RCTArrayBuffer *	RCTArrayBuffer *

NSMutableData is a subclass of NSData, so returning NSData where 0.87 returned NSMutableData still breaks any caller that mutates the result. Reverting only #57879 would leave a second, quieter breaking change in place.

Scope, and how it was determined

Enumerated every 0.88-only commit touching the ObjC TurboModule surface (codegen GenerateModuleObjCpp, RCTArrayBuffer.*, the iOS ReactCommon module dir, iostests, and the Apple cxx-api snapshots), then filtered to those whose added or removed lines mention ArrayBuffer, NSData or NSMutableData. Five matched:

• 11f9a7f4491 #57879 — revert
• 5e86c323cef #57596 — revert
• d84c13d5111 #57982, 5bb96395949 #57897 — Java only, Android snapshots, zero ObjC codegen type changes
• 5fb3ebce1ac — Java ArrayBuffer support. Touches the ObjC codegen, but only to add the throwIfUnsupportedPromiseArrayBuffer validation guard. No type mapping, so out of scope.

All four RCTArrayBuffer entries in the public Apple API snapshot blame to 11f9a7f4491 alone.

Kept, not reverted

• Attach TurboModule identity to exceptions rethrown from async and void calls (#58264) react/react-native#58264 (253a84c8d1c) — TurboModule identity on rethrown exceptions
• Pass a top-level JS null TurboModule arg to ObjC as nil, not NSNull (#58190) react/react-native#58190 (ea291d7422e) — top-level JS null to ObjC as nil

Both conflict with the revert, but each references RCTArrayBuffer only in context lines, never in an added or removed line. The conflicts are textual adjacency, not a dependency, so both were preserved through hand-resolution.

• Fix RNTesterUnitTests build by importing react/bridging/ArrayBuffer.h react/react-native#57518 (e7bb11ae162) — also kept. It adds one #import <react/bridging/ArrayBuffer.h> line. After the reverts, RCTTurboModuleArrayBufferTests.mm is byte-identical to 0.87 apart from that import, and the header exists on 0.87.

Verification

• Resolved codegen serializeMethod.js ArrayBuffer lines are identical to 0.87-stable.
• Regenerated GenerateModuleHObjCpp snapshot matches 0.87 except for promiseArrayBuffer, which the throwIfUnsupportedPromiseArrayBuffer guard now rejects. That guard is a separate 0.88 change, deliberately retained.
• No RCTArrayBuffer or mustCopyBytes references remain anywhere under ReactCommon/react/nativemodule/.
• convertJSIValueToObjCObject is back to its 4-parameter form with BOOL useNSNull = NO defaulted in the header, so the restored 3-argument call sites compile.
• The three #58190 tests and the #58264 test are all still present.
• yarn jest packages/react-native-codegen passes: 64 suites, 3129 tests, 1279 snapshots.

Net: 16 files, 132 insertions, 607 deletions.

The iOS build and the ObjC unit tests are covered by branch CI rather than locally.

[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.

[fabriziocucci]

Merged manually into 0.88-stable:

• 639cdedb506 Revert "RCTArrayBuffer zero-copy class for ObjC TM (#57879)"
• 19a31849817 Revert "Use NSData for the JS->ObjC ArrayBuffer argument path (#57596)"

Verified on the remote after pushing: no RCTArrayBuffer entries remain in the public Apple API snapshot, and the codegen emits NSMutableData * for both the argument and return paths, matching 0.87-stable.

#58264, #58190 and #57518 were preserved through the hand-resolution as described above.