fix(v2): select Safari WebKit by macOS deployment target

[complyue]

Context

On macOS Monterey 12.7.6, the system WKWebView/JavaScriptCore can be older than the WebKit that Safari has staged in:

/Library/Apple/System/Library/StagedFrameworks/Safari

Reasonix currently reaches JavaScript and RegExp features in markdownRemarkPlugins that Monterey's system engine cannot parse. The observed failure is:

Invalid regular expression: invalid group specifier name

It happens while the bundle is being parsed, before React mounts, so the user sees a black/error window. This is a native WebKit version skew, not a Reasonix application-logic bug. Adding more JavaScript shims or repeatedly rewriting individual expressions only moves the compatibility burden to every application.

What this PR changes

Wails now owns this macOS framework selection policy during the normal build:

• Read the standard MACOSX_DEPLOYMENT_TARGET value.
• For 12.3 <= target < 13, validate Safari's staged WebKit frameworks and link with their framework search path.
• Add versioned DYLD framework/library paths so the staged WebKit is selected at runtime, not only at link time.
• Propagate the same deployment target through CGO and the external linker.
• Keep the existing system-WebKit path for targets below 12.3 and for macOS 13+.
• Reject malformed deployment-target values with a build error.

The 12.3 boundary is intentional: the Safari staged framework set validated on Monterey declares macOS 12.3 as its minimum. Selecting it for 12.0–12.2 would produce an invalid deployment target rather than a supported binary.

The optional WAILS_MACOS_STAGED_FRAMEWORKS environment variable is available for controlled build/test environments; the default is Apple's standard staged-framework location.

Why this belongs in Wails

The policy is about how a Wails application is linked and launched, not about Reasonix's frontend. Keeping it here gives every Wails v2 application the same opt-in behavior through:

MACOSX_DEPLOYMENT_TARGET=12.3 wails build -platform darwin/amd64

It also covers manual builds and CI builds without requiring each consumer to duplicate framework validation, -F flags, DYLD_VERSIONED_* flags, and CGO linker plumbing.

Compatibility evidence

This problem has repeatedly been addressed at the application layer:

• Reasonix issue #7624: Monterey 12.7.6 fails in markdownRemarkPlugins with the invalid group-specifier error.
• Reasonix PR #1215: removes RegExp lookbehind from the bundle and adds a narrowly-scoped build transform.
• Reasonix PR #2886: pins mdast-util-gfm-autolink-literal to an older version for Safari.
• Reasonix PR #2883: strips crossorigin from Wails-served assets for macOS 12's custom-scheme loading behavior.
• Reasonix PR #6678: installs an Object.hasOwn polyfill for legacy WebKit.
• Reasonix PR #7615: includes another old-WebKit-compatible local-path matcher.
• Wails PR #3333: reverts JavaScript class fields from the v3 runtime for older Safari.
• Wails issue #2396: Catalina reports a JavaScript parse error in a built Wails application.
• Wails issues #694 and #613: built applications render blank or report opaque Script error failures even when development mode works.

Not every historical report has the same immediate trigger: for example, crossorigin failures are custom-scheme/CORS behavior, not JavaScript syntax. The common maintenance problem is that applications have to discover and encode WebKit-version quirks independently.

Maintenance impact

The paired Reasonix change is only five lines: it sets a 12.3 deployment-target default in its existing desktop build script and leaves all WebKit/linker policy to Wails. No Safari path, native linker flags, or Wails-specific compatibility test is added to the application.

Once this behavior is available in a released Wails version, the following Reasonix cleanup becomes possible as a separate, verifiable follow-up:

• remove the Object.hasOwn startup shim and its contract test;
• remove the mdast-util-gfm-autolink-literal Safari pin;
• remove the lookbehind-avoidance transforms and matchers that only exist for the old system engine;
• retain the crossorigin workaround unless a separate Wails custom-scheme fix makes it redundant, because that issue is transport behavior rather than JavaScript engine age.

This separates permanent product behavior from compatibility debt and makes future WebKit policy fixes reusable across Wails applications.

Validation

• go test ./pkg/commands/build passes.
• bash -n scripts/desktop-build.sh and git diff --check pass in the paired Reasonix checkout.
• On macOS 12.7.6 Intel, the paired Reasonix build was run through its standard desktop-build.sh path with the local Wails CLI.
• The resulting binary advertises a 12.3 minimum, contains DYLD_VERSIONED_FRAMEWORK_PATH and DYLD_VERSIONED_LIBRARY_PATH for Safari's staged directory, loads WebKit, WebKitLegacy, JavaScriptCore, and WebCore from that directory, and passes deep strict code-signature verification.
• Targets 13.0 and later continue through the normal system-WebKit path.

Paired PR

Reasonix consumer PR: esengine/DeepSeek-Reasonix#7628

These two PRs should be reviewed and merged as a pair. The Reasonix PR deliberately contains only the deployment-target handoff; this PR contains the native WebKit policy.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 85076e91-f033-42c9-ab1e-ebb7bff105c9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

_{Comment @coderabbitai help to get the list of available commands.}