Tracking the `Test app (macOS)` failure on #372 ("Adopt Hermes' first-party Node-API (static_h)"), and the conditions under which the macOS job can be re-enabled. ## Status The `MacOS 💻` label has been removed from #372, so `Test app (macOS)` no longer runs there. macOS is knowingly deferred — everything else in that PR (iOS, Android, the Node.js tooling) is unaffected. ## Why it fails #372 vendors Hermes from `facebook/hermes` `static_h` (pinned SHA) and lets React Native build it from source via `REACT_NATIVE_OVERRIDE_HERMES_DIR`. On iOS that's RN `0.88.0-nightly`, whose Hermes build scripts match. On macOS the app is scaffolded by `scripts/init-macos-test-app.ts` against `react-native-macos@0.81.8` / `react-native@0.81.6`, and RN 0.81's Hermes build scripts predate the `static_h` changes we depend on: 1. **`[RN] [1] Build Hermesc` fails immediately.** RN 0.81's `sdks/hermes-engine/utils/build-hermesc-xcode.sh` invokes `cmake -S … -B … -DJSI_DIR=…` with no `-DCMAKE_BUILD_TYPE`, and wraps it in `env -i`, so nothing can be injected from the outside. The pinned Hermes hard-errors in its root `CMakeLists.txt`: ``` CMake Error at CMakeLists.txt:46 (message): Please set CMAKE_BUILD_TYPE ``` Reproduced locally against the pinned SHA with `react-native-macos@0.81.8`'s `ReactCommon/jsi`: configure fails as above, and succeeds once `-DCMAKE_BUILD_TYPE=Release` is added. Upstream RN added that flag in **0.82.0**. 2. **`[RN] [2] Build Hermes` would fail next.** RN 0.81's `build-hermes-xcode.sh` builds `--target libhermes` and copies `API/hermes/hermes.framework`. In the pinned Hermes the target is `hermesvm` and the bundle is `lib/hermesvm.framework` (same rename we handled for Android in #372). RN `main` was updated for this; 0.81 was not. 3. **Likely next: JSI header skew.** #372 drops the step that copied Hermes' JSI headers into RN's `ReactCommon/jsi`, on the grounds that the pinned Hermes and RN 0.87+ agree. RN 0.81 does not, so the host module's use of `IHermes` / `getVMRuntimeUnsafe()` may not compile even once (1) and (2) are past. Note: the second failed phase in CI (`[CP] Copy XCFrameworks` for `weak-node-api`) is most likely collateral — an earlier run with the same Hermesc error reported that phase as passing. Confirm rather than assume once the build gets further. ## What gates re-enabling macOS **`react-native-macos` must ship a release based on React Native ≥ 0.82** (that release carries both the `CMAKE_BUILD_TYPE` fix and the `hermesvm` rename). Today `latest` is `0.81.9`, `next` is `0.81.0`, `nightly` is `0.78.4` — there is no 0.82+ line at all, so bumping the pin within 0.81.x buys nothing. When that lands: 1. Bump `REACT_NATIVE_MACOS_VERSION` / `REACT_NATIVE_VERSION` in `scripts/init-macos-test-app.ts` (they are peer-locked; keep them in lockstep). 2. Re-add the `MacOS 💻` label to the relevant PR — the job in `.github/workflows/check.yml` is already label-gated, so no workflow change is needed. 3. Expect to work through (3) above: JSI/`IHermes` compatibility against the newer react-native-macos. A local workaround is possible in the meantime (patch react-native-macos's two Hermes scripts from `vendor-hermes`), but it papers over a gap that keeps widening with every further `static_h` change, and does nothing about (3). Preferred order is: wait for upstream, then bump. Related: #372, #391 (captures the raw `xcodebuild` log so a script phase failure is diagnosable at all).