An update: flat out denying network access to syspolicyd using Little Snitch could cut down on the delay. (Yes, syspolicyd does send a network request to apple-cloudkit.com for every single new executable. Denying its access to apple-cloudkit.com only isn't sufficient either since it falls back to IP address directly.) Note that this might not be a great idea, and it still has nonzero cost — a network request has to be made and denied by Little Snitch.

Here's my benchmarking script:

  #!/bin/zsh
  tmpfile=$(mktemp)
  cat >$tmpfile <<EOF
  #!/bin/sh
  echo $RANDOM  # Use a different script each time in case it makes a difference.
  EOF
  chmod +x $tmpfile
  setopt xtrace
  time ( $tmpfile )
  time ( $tmpfile )
  unsetopt xtrace
  rm -f $tmpfile

If your local terminal emulator is immune with "Developer Tools" access (interestingly, toggling it off doesn't bring back the delay for some reason), you should be able to reproduce the delay over ssh.

I can repro this locally as well. Interesting if it's inconsistent with Apple docs and when Gatekeeper should be firing, as running stuff locally without distributing/downloading is somewhat out of scope for notarization.

Reached out about this to Apple dev support, hope to get more insight.

> interestingly, toggling it off doesn't bring back the delay for some reason

Noticed the same; it should come back if you disable it and reboot.

Notarization/stapling/etc. is for distribution only, not generally part of your dev workflow.

But TFA and my personal experience do point to a noticeable delay after each recompile in dev workflows, and TFA claims this is due to notarization checks... So I guess I’m confused and you’re talking about something else?

How does mac identify a dev workflow and normal workflow?

When you use XCode you have different compilation options.