[bug] tauri-macos-sign: imported signing identity not resolved by xcodebuild on clean CI runners (Xcode 26)

[johncarmack1984]

Describe the bug

On a clean macOS CI runner, tauri ios build --export-method app-store-connect with IOS_CERTIFICATE, IOS_CERTIFICATE_PASSWORD and IOS_MOBILE_PROVISION fails at signing: xcodebuild cannot resolve the imported identity. It works on dev machines whenever the same certificate also sits in the login keychain, which hides the bug.

Correction (2026-07-28): this report originally claimed Keychain::with_certificate never runs security list-keychains -s. That's wrong. with_certificate_file captures the user search list before creating the keychain (keychain.rs L73–L79) and re-sets it with the new keychain appended after import (L160–L181), and the call is status-checked, so a failure would abort the build before xcodebuild runs. Same code at the 2.11.4 tag. The symptom stands; the root cause is open.

Note for anyone investigating: Keychain's Drop deletes the ephemeral keychain when the CLI exits, so post-mortem diagnostics in a later workflow step show a clean search list. You have to inspect while the build is alive.

Reproduction

On a clean macOS runner (no cert in the login keychain), set IOS_CERTIFICATE, IOS_CERTIFICATE_PASSWORD and IOS_MOBILE_PROVISION and run tauri ios build --export-method app-store-connect.

Expected behavior

The imported identity is visible to xcodebuild and manual signing succeeds.

Platform and versions

tauri-cli 2.11.4 (same code on dev at time of filing), macos-latest runners, Xcode 26.

[mitre88]

I can investigate this with a clean macOS signing setup. The narrow fix appears to be adding the ephemeral keychain to the user search list after import while preserving the existing entries, plus regression coverage around the generated signing environment. Before I start, is that the intended ownership boundary for tauri-macos-sign?

[johncarmack1984]

Heads up before you sink time in: the fix as scoped already exists, and this issue needs a correction from me.

with_certificate_file captures the user search list before creating the keychain (keychain.rs L73–L79) and re-sets it with the new keychain appended after import (L160–L181). The call is status-checked, so a failure there would abort the build before xcodebuild runs. Same code at the 2.11.4 tag. So "never runs security list-keychains -s" is wrong: I had the symptom right and the mechanism wrong. I'll update the issue body.

What stands: clean runner, Xcode 26, --export-method app-store-connect, cert only in the ephemeral keychain, and xcodebuild can't resolve the identity. Root cause still open.

One trap for anyone investigating: Keychain's Drop deletes the ephemeral keychain when the CLI exits, so post-mortem diagnostics in a later workflow step show a clean search list. You have to inspect while the build is alive.

As for the ownership boundary: not mine to draw. I'm the reporter, not a maintainer.