[mziolkowskii]

Summary

Gets the v6 CI builds green again. Three separate breakages, each hidden behind the previous one: the dependency install fails on Node 20, the iOS jobs ask for a simulator the current macOS image no longer has, and React Native 0.78's fmt does not compile with Xcode 26.

Motivation

Node. On support/6.x.x, the Android example build fails at the first yarn install, before anything is built:

yarn install v1.22.22
info No lockfile found.
...
error react-native@0.87.1: The engine "node" is incompatible with this module. Expected version "^22.13.0 || ^24.3.0 || >= 26.0.0". Got "20.20.2"

• yarn.lock is in .gitignore, so every CI install resolves dependencies from scratch.
• @types/react-native-web declares react-native: "*" as a regular dependency (all 0.19.x versions), so yarn installs the latest react-native next to the project's 0.78.
• react-native 0.87.0 (released 2026-08-11) raised its Node requirement to ^22.13.0 || ^24.3.0 || >= 26.0.0; 0.86 still accepted ^20.19.4.
• The shared .github/actions/setup-node action pins Node 20.x.

The last green Android example build on this branch was on 2026-08-05. It is what fails on #5099 and #5100. build-ios and check-js use the same install step.

iOS simulator. With the install fixed, all three iOS jobs failed at xcodebuild, which asked for -destination 'platform=iOS Simulator,name=iPhone 16'. The macos-latest image now ships Xcode 26 with iPhone 17 / 16e / Air simulators only:

xcodebuild: error: Unable to find a device matching the provided destination specifier:
        { platform:iOS Simulator, OS:latest, name:iPhone 16 }

fmt on Xcode 26. With a destination it can use, the iOS build failed compiling fmt's format.cc. React Native 0.78 bundles fmt 11.0.2, and Xcode 26's Apple Clang 21 rejects its FMT_STRING usages. xcpretty hides the compiler output in CI; compiling fmt 11.0.2's format.cc for the simulator with Xcode 26.6 locally gives 5 of these errors in C++20 and none in C++17:

fmt-11.0.2/include/fmt/format-inl.h:59:24: error: call to consteval function 'fmt::basic_format_string<...>::basic_format_string<FMT_COMPILE_STRING, 0>' is not a constant expression

This is the problem #5080 fixed for the v7 example on master.

Changes

• .github/actions/setup-node/action.yml: Node 20.x → 22.x (LTS until April 2027).
• .nvmrc: v18 → v22, matching CI.
• build-ios.yml: the three jobs build for generic/platform=iOS Simulator. They only build and never run the app, so they do not need a specific device, and this no longer breaks when the runner image changes its simulators.
• examples/bare/ios/Podfile: builds only the fmt pod as C++17 (consteval does not exist before C++20), through use_test_app!'s :post_install; the same workaround as example/ios/Podfile on master. Podfile.lock is left alone: it was already out of date (React 0.78.2, different Podfile checksum) and CI resolves pods on every run.
• build-android, build-ios and check-js also trigger on changes to .github/actions/setup-node/**. Without this, none of them ran for a change to the action they all use, so this PR could not have tested itself.

Not changed, for the maintainers to decide: committing yarn.lock, or pinning the nested react-native with resolutions. Either would stop unrelated releases from breaking CI in the same way again; this PR only fixes the current break. Also note that --immutable in the install step is a Yarn Berry flag, and CI runs Yarn 1, so the install is not actually immutable.

Test plan

All checks on this PR pass:

Workflow	Result
Build Android Example App / With Ads	pass
Build iOS Example App / With Ads / With Caching	pass (16, 14 and 19 min)
Check TS, Lint JS	pass

• Before this PR, the Android build failed at yarn install (log above, from feat(android): support Media3 1.9 in the load control and re-enable bufferingStrategy #5099). After the Node change, both Android builds and the JS checks passed; the iOS jobs got past install and pod install and failed on the destination, then on fmt, and pass with all three commits.
• The iOS jobs took 9–11 min in the last green runs (May 2026) and 14–19 min here. This run had no warm caches for the new keys, runs Xcode 26, and the generic simulator destination builds both arm64 and x86_64, so the numbers are not directly comparable. If the time stays up, limiting the build to arm64 is a possible follow-up.