feat(catalyst): run and build Mac Catalyst apps with ns run catalyst

[farfromrefug]

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/nativescript-cli/blob/master/CONTRIBUTING.md#contribute-to-the-code-base
• Tests for the changes are included.

What is the current behavior?

There is no way to run a NativeScript app on macOS. #5 added a --catalyst flag to ns build ios, which produces a Mac Catalyst binary but has no run, deploy or LiveSync story.

What is the new behavior?

catalyst becomes a supported platform: ns build catalyst and ns run catalyst, the latter with full LiveSync.

On the name. This is deliberately not called macos. A separate upstream effort adds ns run macos for a native macOS app built against a macOS runtime — a different product. Mac Catalyst is the iOS app rebuilt against the macOS SDK, so it takes the name that says what it is.

A Catalyst app keeps every iOS convention — App_Resources/iOS, the iOS runtime package, each plugin's platforms/ios folder, the iOS Podfile, the iOS bundle — and diverges only in the directory it prepares into (platforms/catalyst) and the SDK it builds against.

• Platform resolution. iOSProjectService reports iOS as the platform name so every iOS convention falls out for free, and projectRoot becomes the single place Catalyst differs. Two call sites rebuilt the platform directory from the platform name instead of reading projectRoot; both now use projectRoot, which already resolves hostProjectPath identically. Left as-is, a Catalyst build would have probed and deleted platforms/ios.
• The Mac as a device. Build, deploy and LiveSync drive it through the existing pipeline. Everything is local: the .app is a directory on this machine, so the file system is a plain copy, install only records the built bundle, launch is open -n, and the log stream is log stream narrowed to the app and the runtime.
• Watch-mode platform matching. Prepare events are now stamped with the platform the caller asked for rather than the platform data's name. run-controller pairs an event with a device by comparing the two, so for Catalyst — iOS platform data, Catalyst device — a file change recompiled but reached no device. The non-watch path already reported the requested platform; watchers and bundler processes are keyed by it too, since stopWatchers and stopBundlerCompiler are called with it. Nothing changes for ios/android/visionos, where both strings are identical.
• Removes --catalyst, which this supersedes: the Catalyst build path is now selected by the platform rather than a flag on build ios.

Relationship to the upstream PR

The same work is proposed upstream as NativeScript#6125, and the Catalyst code here is byte-identical to it — verified line by line, including the four new files. That is deliberate: when NativeScript#6125 lands and this fork merges upstream/main, git sees the same additions on both sides and resolves them automatically.

A trial merge of the two confirms it. The only conflict my work adds is in getInstalledRuntimePackage, where the upstream patch inserts the Catalyst→iOS mapping directly above a block this fork already carries; resolution is to keep both sides. (That block — let packageName: string[] — is dead code: the .find() callback below declares its own local packageName, so nothing reads it. Worth removing separately.) The other conflicts in that trial — lib/config.ts and package-lock.json — appear identically when merging upstream/main into fork main with none of this work applied.

Testing

Verified end to end with OSS Weather on Apple Silicon, on this branch after the rename: ns build catalyst runs pod install, generates metadata for arm64-apple-ios<version>-macabi and links and signs the .app; ns run catalyst launches it, streams its logs, and syncs a file change into the running app — an added console.log came back through the CLI after the automatic restart.

No unit tests are included: the change is platform plumbing plus a device implementation that shells out to open, pkill and log, none of which the existing suite has a harness for.

vitest run reports 189 failures out of 1648 on this branch — and the identical 189 on main. Verified by running the suite on both and diffing the failing test names: zero new, zero fixed. The suite is already red on main; this PR does not change it.

Note for reviewers

Two runtime-side fixes are needed before a clean checkout can build a working Catalyst app, both unmerged:

• the metadata generator needs the iOSSupport framework search paths, or the app launches into ReferenceError: UIDevice is not defined;
• build_npm_ios.sh needs cp -R so the Catalyst xcframeworks keep their versioned-bundle symlinks, or codesign rejects the app.

iOS never hits either, because it uses shallow framework bundles and its own SDK paths.