Host distribution

Thin npm/npx launcher for the prebuilt macOS Rust host. Publish signed darwin-arm64 and darwin-x64 prebuilds with scripts/publish-host-npm.sh. Everyday development builds must not notarize or npm publish. Follow code organization and the host specification.

macOS Release Symbol Handling

1. Strip only unnecessary debug symbols

The macOS binary delivered to users does not need a symbol table or complete debug information. scripts/publish-host-npm.sh generates a dSYM, then strips the distributed executable before signing so nm does not publish Rust names. This reduces obvious inspection; it is not an anti-reverse-engineering guarantee.

Preserve every symbol required for execution, dynamic linking, ABI compatibility, plugins, or the runtime. Do not strip the file after it is signed.

2. Generate and retain dSYM files

Every official release must generate a dSYM that corresponds exactly to that build. The recommended Release debug information format is DWARF with dSYM File. Generate the dSYM before discarding the debugging information needed to produce it.

The dSYM need not be included in the normal user installation package, but it must be retained long-term as an internal Release Artifact. Stripping the distributed binary is not a reason to delete its dSYM.

3. Verify binary and dSYM correspondence

For every official release, verify that the distributed binary and retained dSYM belong to the same build by comparing their Mach-O and dSYM UUIDs:

dwarfdump --uuid <binary>
dwarfdump --uuid <path-to-dSYM>

The UUID must match for each architecture in the release binary. Retain the matching results with the internal Release Artifacts; version names alone are not sufficient to establish correspondence. A missing dSYM or UUID mismatch must block release until the correct matching artifacts are available.

Notarization timing

Notarization is an explicit near-release step, after the release artifact, symbols and signatures are finalized. Daily development builds, local tests and ordinary CI checks must not automatically submit artifacts to Apple.

Avoid repeated submissions: retain the artifact hash and submission ID, then query that submission's status and logs. A local wait timeout does not mean the upload failed. Reuse an accepted result for the unchanged artifact; submit a changed artifact only when it is again ready for release.

For an already accepted artifact, complete ticket stapling where supported and Gatekeeper verification without uploading it again. Acceptance is an automated distribution-security check, not App Store publication or functional acceptance. Credential-profile and artifact-verification rules live in the signing contract. Historical acceptance does not establish the status of a newly built artifact.