Skip to content
sdlc

B-QZ3T-pumice-macos-private-api-unifies-across-the-root-cargo-workspace

apps/pumice/src-tauri/Cargo.toml declares tauri = { version = "2", features = ["tray-icon", "macos-private-api"] }, and apps/pumice/src-tauri/tauri.conf.json sets "macOSPrivateApi": true. Both apps/pumice/src-tauri and solutions/determined/products/*/src-tauri are members of the single root Cargo workspace, and they resolve the same tauri package.

Cargo unifies features across the packages in one build invocation, so the scope of the private-API code depends on how cargo is called:

  • cargo tree -p product-fitness -e features — no macos-private-api.
  • cargo tree --workspace -e features — one tauri v2.11.5 node with macos-private-api in its feature set.

So a scoped build (cargo build -p product-fitness, and the Tauri CLI’s own per-crate build) links a tauri without the feature, while any workspace-wide cargo build / check / clippy / test links one with it. Determined’s products and solutions/ontological’s products are in the same position.

Two things to work out:

  • Whether any shipped artifact is produced by a workspace-wide invocation. If every release path is scoped per crate, the exposure is a local-build artifact only.
  • Whether the feature being compiled in is enough to matter when the app’s own macOSPrivateApi config is false. The feature gates the code, and the config gates the call — but App Store review reads binaries, not configs, so a linked-but-unreached private-API path may still be a finding.

This is independent of D-0040. That decision says fitness will not opt into macOSPrivateApi; this item asks whether fitness already carries it without opting in.

If the answer is that it does and that it matters, the fix is to stop pumice’s feature from unifying — a separate workspace for pumice, or moving the private-API surface behind a crate pumice alone depends on.

← Back to Backlog