[edusperoni]

Uses NativeScript/v8-buildscripts#10 (merged), released as v8-14.9.207.39-9; V8_RELEASE is bumped to it. Its Catalyst archives carry the full compiler (libv8_compiler.a ~27 MB, Maglev present); iOS archives are still lite.

What

• Runtime (Catalyst only): before V8::Initialize, the runtime tries one small mmap(MAP_JIT) allocation. If it fails, the runtime passes --jitless. "ios": { "jit": false } in the app's package.json forces the interpreter. iOS is unchanged: its V8 is lite mode, which implies --jitless.
• Catalyst test lane: TestRunner and its dependencies build for Mac Catalyst (arm64), ad-hoc signed with hardened runtime and allow-jit, like a shipped app. ./run_tests.sh --catalyst runs the suite on the host Mac, and a new test-catalyst CI job does the same on macos-15. CatalystJitTests asserts that V8 holds executable memory, which it only maps with the JIT on.
• Fixed along the way:
  • The arm64 Catalyst slice was linking Apple's /usr/lib/libffi.dylib. build_libffi.sh had no arm64-maccatalyst slice, so -lffi fell back to the SDK's libffi.tbd, while the runtime compiled against our fork's headers; the published 9.1.0 framework shows this with otool -L. The slice is now built and committed.
  • The metadata generator produced 0-byte metadata in Catalyst builds without failing them. Xcode doesn't export IPHONEOS_DEPLOYMENT_TARGET to Catalyst script phases, so the fix(metadata-generator): emit UIKit metadata for Mac Catalyst #433 fallback raised KeyError. It now falls back to LLVM_TARGET_TRIPLE_OS_VERSION. User Catalyst apps run the same script.

Why the runtime check is needed

V8 doesn't fall back to the interpreter on its own. In a hardened-runtime process without allow-jit (or allow-unsigned-executable-memory), the JIT build dies at its first code allocation; I saw a SIGTRAP at startup in a probe. With the entitlement, or without hardened runtime, the JIT runs.

The app template now grants allow-jit instead of allow-unsigned-executable-memory. Only V8's JIT needs an exception, and libffi closures come from signed trampoline pages: a Catalyst probe calling a closure works under the hardened runtime with no entitlement. Existing apps keep the old entitlement, which also allows MAP_JIT, so they start using the JIT once they pick up this runtime.

Verification

• Patched V8 Catalyst build (local), in a macabi probe: hot JS runs in 11 ms with JIT vs 385 ms with --jitless, and --trace-opt reports optimizations under ad-hoc, hardened + allow-jit, and hardened + allow-unsigned-executable-memory.
• iOS simulator suite (./run_tests.sh --temp-sim): 1835 specs, 0 failures, 11 skipped.
• Catalyst suite (./run_tests.sh --catalyst, local, with the patched JIT V8): 1836 specs, 0 failures, 11 skipped, 73 s. CatalystJitTests passes, so V8 holds JIT memory. Getting there took two fixes: the UI-test runner needs network.server to receive the app's report, and three specs assumed the flat iOS bundle layout (bundlePath + "/app"; now resourcePath). A shared spec assumed a case-sensitive file system; fixed upstream in common-runtime-tests-app 234f5f3, and the submodule is bumped. The macOS UI-test runner needs Automation Mode without authentication (sudo automationmodetool enable-automationmode-without-authentication); GitHub's macOS images ship with it enabled.
• CI: the test-catalyst job now runs against the -9 JIT release, so CatalystJitTests should pass there too.

Notes

• TestRunner's Catalyst entitlements include disable-library-validation. Ad-hoc signatures carry no Team ID, so hardened-runtime library validation would refuse the embedded frameworks. This is test-only.
• --catalyst runs are serialized per Mac with a lock, because XCUIApplication kills any running app with the same bundle ID.
• The ios.jit key isn't in the @nativescript/core config typings yet.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn