On an Apple Silicon Mac, a freshly compiled arm64 binary dies immediately with "Killed: 9" while the same source runs fine on an Intel Mac. What is happening?

## Two different signature checks, easily confused macOS applies code-signature checks at two very different altitudes, and mixing them up is the reason this failure baffles people. 1. **Gatekeeper** evaluates *quarantined* downloads on first launch and asks about provenance: a Developer ID, a notarization ticket. It produces a user-facing dialog, and it can be bypassed by clearing the quarantine attribute. 2. **Kernel signature enforcement on Apple Silicon** asks only "does this arm64 image carry a valid signature at all?" It applies to every execution, quarantined or not, downloaded or locally built. It produces no dialog, no prompt, and no bypass — the process is sent SIGKILL during `exec`. The second check is what kills a locally compiled binary. Because it fires before your code runs, none of your instrumentation helps: no `main`, no atexit handler, no log line. The shell reports `Killed: 9` and you are left with nothing. ## Why the seal breaks in real build pipelines Apple's toolchain applies an ad-hoc signature automatically when linking arm64 code, so "never signed" is actually the less common cause on a Mac. The frequent cause is **post-signing modification**. A code signature covers the bytes of the Mach-O image, so anything that rewrites it invalidates the seal: - `strip` removing symbols - `install_name_tool` rewriting an install name or an rpath — the classic step in relocatable-bundle scripts - Post-processing that patches a version string, appends data, or concatenates a payload - Copying a bundle in a way that drops extended attributes, or unarchiving with a tool that does not preserve them Everything works on the build machine right up to the point where the last packaging step runs, and only then does the artifact start dying — which is why the failure often shows up in CI rather than locally. ```sh $ ./mytool zsh: killed ./mytool $ codesign --verify --verbose=2 ./mytool ./mytool: invalid signature (code or signature have been modified) $ codesign --force --sign - ./mytool # ad-hoc re-sign $ ./mytool hello ``` `codesign -s -` is the ad-hoc identity: it computes and attaches the hashes with no certificate and no identity attached. The kernel requirement is satisfied because a valid signature exists; nothing is claimed about who produced it. That is the right fix for local development and internal tools, and explicitly *not* a substitute for Developer ID signing plus notarization on anything you distribute. ## The correct ordering The rule that falls out of this is simple and worth stating in an interview: **signing is the last step**. Any tool that touches the binary must run before it, and the signature must be re-applied after any change. In a bundle, sign inside-out — nested frameworks and helper tools first, then the outer bundle, since the outer signature seals its contents. ## Adjacent symptoms that look the same A process that dies at startup with SIGKILL and no output is also produced by a couple of neighbouring conditions, and a good answer distinguishes them: - A **library** with a broken or mismatched signature can fail to load into a process running with library validation, which produces a linker-level failure naming the library rather than a bare kill of your executable. - A **quarantined** binary with a bad signature produces a Gatekeeper dialog, not a silent kill — the presence or absence of a dialog is a useful discriminator. - The system log subsystem records signature-validation failures with the offending path, which is the fastest way to confirm rather than guess when the shell output is empty. ## Why interviewers ask it This is a question you can only answer well if you have shipped or built something on Apple Silicon. The wrong answers are recognisable: blaming the compiler, blaming architecture mismatch (which produces a clear "bad CPU type" error, not a kill), or reaching for SIP. The right answer identifies a *platform invariant* — arm64 code must be signed — and traces the failure to the build step that broke the seal.