I mean, when I’m developing in a compiled language with the workflow edit code -> compile -> run (with forced stapling), changing it to edit code -> compile -> staple -> run doesn’t make it any less slow...
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.
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?
